thedwick

Jason Cohen has obviously spent a lot of time thinking about code review and his book, Best Kept Secrets of Peer Code Review, shows it. Partly marketing brochure, partly master’s thesis, and partly just a normal software book, the text does a better job than some other software books citing references and backing up opinions with facts and figures.

My interest in it ebbed and flowed; the beginning spends a lot of time talking about why Cohen thinks code review is a good thing but wasn’t terribly interesting. The middle of the book, though, was the meat I was looking for. It goes over different styles of code review and in particular compares and contrasts a more formal, meeting-intensive and laborious style with more lightweight, distributed and online style. Turns out, lightweight can be almost as good as heavyweight at finding defects; and when you factor in the cost of finding those defects then lightweight wins hands down.

The last part of the book is skim material that mostly talks about the code review software that Cohen’s company sells.

Some good tidbits I took away:
1) After about 60 minutes of looking at a pile of code, your performance finding defects in it trails off. This effect is the same no matter if the code is 20 lines or 20,000.
2) The optimum review rate is 250 – 400 lines of code per hour
3) #1 and #2 imply that the average code review should be around 400 lines of code.
4) Most defects are found when a single person sits down alone to look at code in concentration. Contrary to popular belief, the fewest are found by a group of people looking at code together and talking to each other while they’re doing it.
5) Even if all you ever do is make yourself review your own code after you’ve written it, you will find a decent number of defects.

One of the developers on my team recommended this book after we created a “stewardship” role on the team. Basically, the application had become too big for me to review all changes myself, so instead I gave the more senior guys on the team a particular area to be stewards for and they review code changed there. This kind of arrangement, incidentally, seems to have worked out well if you want to try it.

The head business analyst on my team read Why Software Sucks by David Platt and liked it so much he went out and bought five copies for the team. So I went into the book with high hopes.

They didn’t stay high for long, though. Platt did a good job keeping the discussion just technical enough to make sense, but not so technical that a non-programmer couldn’t follow along. But I thought that’s about all he did well. The rest of the book is inflammatory and curmudgeonly; he flings around labels like “idoit (sic)” and “marketingbozo” with abandon. He chooses arbitrary examples, and then evaluates them with all the depth of a reflecting pool.

Take an example he comes back to again and again. He likes the fact that when you go to google.com, it automagically knows what country you’re in based on your IP address and sets your locale accordingly and he blasts UPS.com for not doing the same thing and instead making the user pick a locale in its first step. He then goes on to call the programmers at UPS.com idiots and lazy. Well, I like google.com and dislike ups.com for the same reason, but they were created that way probably for far more complicated reasons than he’s admitting to. In particular, what he’s missing is the economic reality of software development, and in particular:

1) Not every company has world-class developers. By definition, the average company must have…average developers. Average developers often don’t know about things like IP address databases based on locales and have no idea how to get to them.
2) If a feature takes 1 day to implement “good enough” and only 1.25 days to implement “great” he would say it’s a crime not to spend the extra 2 hours to get to great. But he’s missing that if you spend that extra 25% on every task then…ding, ding, ding, your project is going to overrun by 25% (if your original estimates were even accurate in the first place. More likely you’ll be 125% late). On an 8-week project that’s an overrun of 2 weeks which is usually not acceptable.
3) Often times, developers want to spend that extra 2 hours to make a feature great, but they are told not to for various business reasons like not wanting to be 25% late.

So, I was disappointed in the book. I was hoping for a good, colloquial discussion of the challenges of developing good software. I was hoping for a book that would give me some good analogies and examples to use on my Mom. But I didn’t.

Software Estimation: Demystifying the Black Art is one of those books that came to me just in the nick of time. No sooner had I finished reading it than I had to do a bunch of estimation for a project I’m on. I managed to apply maybe 15% of what I learned in the book and found a nearly 100% improvement in the result.

Steve McConnell is also the author of Code Complete and Rapid Development, so it’s not like he has much to prove. That’s probably part of what allowed him to feel free to take decades of software research (which he thoroughly sited and gave very useful bibliographies to at the end of each chapter) and distill it to easy to understand snippets without any apparent loss of nuance.

Here are some of the gems I took away from the book:

• You really should get in the habit of differentiating among: estimates (how long it’s likely to take), targets (dates the business would really like to hit), and commitments (dates you commit to delivering, which sometimes don’t exactly jive with your estimates).
• Schedule in Months = 3.0 times the cube root of the Effort in Person Months—-this is apparently one of the “most replicated results in software engineering” research.
• Underestimation when you start a project has actually been proven to lead to increased effort for a whole variety of reasons, some of them obvious and some not.
• 40% of software errors are caused by stress, especially schedule stress.
• Projects experiencing schedule stress produce four times as many defects as those that aren’t
• estimates vs actuals can vary by surprising amounts depending on where they are in the Cone of Uncertainty
• There are many known multipliers to software estimation, and at the very top of the list are: the ability of your business analysts (2x), multi-site development (1.56x), required reliability of the software (1.54), and the list goes on.
• and my favorite one of all, one I managed to put to good use on my project: expected case estimate = (best case x (3 x most likely case) x (2 x worst case)) / 6