I just had to laugh at this one, after we were pointed to it by some consultants. They were explaining that SDO is the great new way to do object to relational mapping, a “best practice”, as they put it. Turns out in the only available book, a redbook, on the subject IBM points out how great they are because:

SDO is a powerful architecture that brings access to data closer to the Web application designer. SDO can be integrated with JSF pages and data access is generated into the page code Java classes. SDO can also be integrated with regular JSPs and access is performed through the tag library provided by SDO.

In other words you can essentially embed your data into your presentation layer. This is a great best practice commonly seen in frameworks like Coldfusion. IBM is quite the innovator. Maybe they meant this is a “best practice” for slick, quick demos to managers who haven’t coded in years.

My personal thoughts on referral bonuses is that I prefer to avoid them. I’ve referred in probably four or five people on my own. Some of those companies paid referral bonuses, but I either split them with the candidate or just turned the whole thing over to them. Personally I only referred in someone if I had faith they were a good fit and the company was a good place to work. Considering I worked for at least one dotbomb I may have misestimated on that one, but I was up front about the risks.

As a manager now with an option to offer a referral bonus, I’ve turned avoided them. My theory is that if someone’s isn’t willing to recommend an acquaintance unless there’s a referral bonus, then they probably won’t make that great of an employee. Much of my bias against them stems from a past company where I saw referrals badly abused so that a few employees could make $10,000 or more referring in some dubious hires.

Given the number of resumes and interviews I had to go through for our last developer hire, I’m considering rethinking my approach to this. Since I’m going to be pretty thoroughly vetting everyone, maybe it’s worth seeing if adding a $3000-$5000 referral bonus. If we end up hiring without a referral again nothing’s really lost in the experiment. And if it ends up being a referral I make, I’ll try to convince HR to nix it since that’s just a bit unethical.

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.