I’ve been kicking around just how to go about implementing code reviews on my development teams for a month or two now. Despite my vast experience, OK only about 10 years or so, I never worked for an organization that practiced code reviews. I have done a few code walk-throughs myself to present some finished project to client development staff, but that’s about the extent of it.

So in collecting whatever information I could over the web and now having talked to several development managers who actually have some code review experience it appears that the consensus is you have to mandate them. I pretty much knew that since developer’s don’t naturally see the value in code reviews and they can often go wrong in so many ways:

• Nit picky tech leads who insist on minute changes.
• Harsh presentations where the developer is told over and over what they did wrong.
• Mind numbing code review meetings where everyone tries not to fall asleep.

So starting next week I’ll be mandating that all of my teams conduct code reviews. This goes against my basic personality of managing by consensus, but the benefits done right outweigh the discomfort of the situation. And if it goes horribly wrong we can always toss them out and try again later.

Quoting from Brian Marrick in a recent post:

Bob Martin said at Agile 2005 that industry seems to be converging on a standard Agile approach: Scrum with a subset of the XP practices.

I’d have to say that’s pretty much the path we’re headed down at my company. We tend to stumble more in the XP practices arena especially in the area of unit testing. Scrum by itself is fairly easy to adopt since it mainly specifies a few simple project management practices, though getting a true product owner to be involved has often proved fairly difficult. It would seem that soon we’ll just have an loosely defined ‘Agile’ methodology.

I came across an idea I’m kicking around adopting in Alistair Cockburn’s Crystal Clear. The idea is that to help move forward the professionalism of your group you hold a weekly meeting to discuss a chapter of an important software title such as Kent Beck’s Test Driven Development or Andy Hunt and Dave Thomas’s Pragmatic Programmer. The more I think about it, the more I like it. I’ll probably try out the idea on my team with Kent Beck’s Test Driven Development since that’s the area we’re lacking the most currently. I figure if I serve milk and cookies I can get over the Oprah’s book club fears.

I’m about halfway through Michael Feathers’s Working Effectively with Legacy Code, and I came across his attempt to handle nasty methods that take multiple parameters by merely passing in nulls and seeing if the test will still run. If the nulls are good enough then you can spend a lot less time digging through the legacy code for knotty dependencies. I’ve tried this before myself, but I never put much thought into it until I ran across it here. Pretty interesting read so far though I find the C++ code examples a little hard to follow sometimes.

I got blindsided by some consultants today explaining that we would be implementing SDO for our ORM layer. I’d barely heard of it and it has almost zilcho profile in the general J2EE community. Apparently I’m being overruled by said consultants.

So I did a little 10 minute research on service data objects versus Hibernate:

• Number of books on Hibernate on Amazon.com: 8
• Number of books on Service Data Objects on Amazon.com: 1 (An IBM Redbook)
• Number of jobs on Monster.com listing Hibernate: 373
• Number of jobs on Monster.com listing Service Data Objects: 1