Reviews
Why don't we do enough?
I recently read chapter 5 of Applied Software Project Management and it was all about reviews. Inspections, desk checks, walkthroughs and code reviews were all mentioned along with the compelling argument that reviews have a very high return on investment because catching a defect early is much much cheaper than catching it later. Think about it, a couple of hours spent reviewing your key use cases is much cheaper than getting somebody to rewrite and retest a software component that works but does the wrong thing.
I'll be honest, I'm as guilty as the next person in not doing enough reviews, but why do we let this happen and how can we readdress the balance? The first part of the question is easy to answer and I'd like to offer up the following suggestions.
- Time : there are always better things to be doing.
- Context switching : it takes a while to switch from what you're doing and focus on something else that you might not necessarily be familiar with.
- Learning curve : As an architect, you're not going to know the entire system inside-out, so there's the learning curve to consider when you review something you've not seen before.
- Tools : if you've installed code checking tools (e.g. PMD, Checkstyle, etc) then there's a tendency to "leave it to the tools".
So, how do we address this? Well, for code reviews, an easy answer is to adopt extreme programming's pair programming, but of course this isn't always possible and/or desirable. Something that I recommend other architects do is delegate some of the reviewing to others on the team, perhaps sitting with them for the first few reviews to help them see what you want. This is good because not only does it free you up a little, but it helps develop their skillset and spreads knowledge of the project across more of the team.
Ultimately though, you just need to make time for reviews. Ensure that they are included in any estimates and, if you're an architect, ensure that you set some time aside for reviews. As an architect you're probably responsible for the technical quality and you can't assure it if you don't review it.
Simon is a hands-on software architect and a senior consultant at 

