A Strategy for Code Reviews

I was coaching an organization the other day where they are trying to increase code quality. They believe they can accomplish this by increasing the frequency of code reviews. Currently, their solution is to get everyone into a room on a weekly basis, with junior developers demonstrating what they did and senior developers offering constructive feedback. If you've been reading my blog for a while now, you'll know that I usually find structured lengthy meetings as a wasteful activity. I'm not saying there isn't value in them. I'm just saying their cost is too much, relative to the value.

Weekly Code Review

Because the teams are trying to increase their delivery velocity, they are being forced to review their code delivery policies and rules. The weekly code reviews are creating too much of a delay. If a developer finished his or her feature on day one, they have a whole week to wait for the code review. If any changes are recommended, they lose an entire week because they still have to make the updates and get another review. The quality may be high but the velocity is low.


My recommendation was the teams should begin pairing.  Upon review of their defined policies, it did not say they had to have a formal weekly code review meeting.  What it did say was no code would be merged into the trunk until another set of eyes had reviewed it.  By having a "code review" developer sit with the active developer, as he or she wrote code, it could be reviewed in real time and satisfy the policy.  The one week feedback loop would be shortened to an immediate feedback loop.

The Compromise

Paired programming can be a hard sell.  Management can find it hard to understand having two perfectly capable developers working on one piece of code.  But, if you look at the cost of waiting an entire week to get feedback and also having a group of developers stop work to attend a code review meeting, you can see there is a lot of wasted time and effort.  When I asked about this, I was told that the meeting was also an opportunity for developers to learn about other areas of the system.  My counterpoint was to rotate the pairs, to also offer a learning opportunity.

Because the teams would not agree to do formal pairing, but they certainly see the value in it, they decided to have a different (floating) code reviewer every day.  He or she will make themselves available the entire day to review code as needed.  I don't completely agree with this approach but it's certainly better then a weekly code review meeting.  They will be exposed to new areas of the system and the feedback loop will be shortened.  My hope is, in time, they will realize that having that second set of eyes sitting there full time will be the most efficient appraoch.

Image Quality by Pictofigo

Technical Debt

Technical debt and design debt are synonymous  metaphors referring to the eventual consequences of sloppy software architecture and rushed software development. Code debt refers to technical debt within a codebase. Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future.  A team should take opportunities, on a regular basis, to pay back (or pay off) this debt.  Either reserve a percentage of your development cycle or dedicate an entire cycle to complete this work.  If you don't, it will come back to haunt you.  If your kludge of a solution doesn't come back to bite the development team, it will probably haunt the help desk, support team, or someone else downstream.

Just like regular debt, you're going to have to pay it back sooner or later.  As a former Manager of Software Engineering and now as an advisor to a customer, I've seen (and see) what technical debt can do to the velocity of a team.  It robs them of precious time, after the fact. The development team buys into the idea that doing things the wrong way, to save some time in the interim, is worth the risks and the overall cost.  This is a really short-sided thought process.  Technical debt is like getting a loan from loan shark who roles dice to decide what your interest rate is.  So, if you don't need to take the risk, don't do it.

Be honest with your customer, your team, and yourself.  Estimate your work and stand by your estimate.  Don't let someone else tell you how long it will take to deliver quality work.  If you have to, you'll just have to deliver less work.  That is, don't take on the debt in the first place.

[HT]: Wikipedia

Like the image? Find it at Pictofigo

Expert Judgment and Passing the Sniff Test

Looking for two very informative posts on estimating?  Check out one by Josh Nankivel of pmStudent and Glen Alleman of Herding Cats.  Both are discussing estimating techniques that work for them. I wanted to take a moment to add my two cents. Though I certainly believe estimating should be more science than art, I look at estimates from a different perspective. As a disclosure, I'm not the one doing the estimating on this project, therefore I'm not going to say I agree or disagree with any one technique.  Depending on your situation, one estimating technique may provide more accurate results than the other.

What I would like to add, from my perspective, is the need for expert judgment. If you are an expert in a given estimating technique and it gives you the results you and your customer(s) need, does that not validate it as an acceptable estimating choice?

If the estimating technique does not produce the desired results, wouldn't it fail the metaphorical sniff test?

Recently, I questioned a vendor's estimate based on a different technique.  I used a parametric estimate to see if the vendor's estimate would pass or fail my sniff test.

What exactly is a parametric estimate?

An estimating technique that uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters, such as scope, cost, budget, and duration.  Source: PMBOK Page 439

So, why did the vendor's estimate not pass my sniff test?  As part of a standard estimating practice, software vendors should include time for fixing bugs. Upon review of a recent status report, I noticed the vendor reporting half as many bugs were discovered in a current build than had been estimated. When asked about this, the vendor was very excited to confirm that they indeed found half as many defects in the code they originally estimated and predicted a cost savings of several hundred thousand dollars to the project.  Going into the current build, I knew what the standard deviation was and considered the possible variance.  This fell way below that.

So, why were they discovering so few bugs?  At first glance, I would predict two possible reasons.  [1] Quality through development improved.  [2] Quality through testing worsened.  Either way, you get the same initial result of fewer defects identified.

We'll know the true answer once initial user acceptance testing begins.  If there were no baselines to compare the actuals to, I might not have given it a second thought.

Graphic source via Flickr: pump

Listen to your Customer on her Birthday

In celebration of my wife's birthday, I figured I would make her a homemade birthday cake.  I haven't done that since before we got married 5+ years ago.  This time, however, I actually asked her what she wanted.  That's right.  The first birthday cake that I made for her, I didn't even ask what she would like.  If you were the customer, wouldn't that kind of tick you off?  Thanks for the cake but... I don't like that kind. Getting input (and listening) to your customer goes a long way.

Sure, I could have ordered a cake from the local (and now famous) Charm City Cakes but she didn't ask for that.  She wanted a chocolate cake with butter cream frosting.  So, last night, our 4-year-old son and I made her a chocolate cake with butter cream frosting.  We even cleaned up the mess after!  But, it wasn't completely uneventful.  All I can say is I'm glad there were well documented instructions.

Me: Are we a pair of knuckleheads or what? My son:  I think we're a pair of clowns, Daddy.

Here is my Project Management Spin

  1. Find out what your customer wants.
  2. Deliver what your customer wants, not what you want.
  3. You'll spend more money if you want a chef to bake and decorate your cake.
  4. You'll save more time if you want a chef to bake and decorate your cake.
  5. Even a pair of clowns can bake and decorate a cake (if instructions are good).
  6. You should expect lower quality from a pair of clowns.

Product Delivery

  • Both cake and frosting passed unit testing. (Mmmmmm)
  • We did a little beta testing last night before the final build.
  • The final build was successful.
  • We delivered on time.
  • We delivered below budget.
  • The good news is, I'm pretty sure we'll pass user acceptance testing.

Happy Birthday to my beautiful and wonderful wife!

Process Improvement and Grilling Steak

What's a weekend without grilling steak?  I would say a weekend without a good blog post idea.  Some things in life are an art and some a science.  It doesn't matter if it's project management/leadership or grilling a steak. So, what is a geeky way to write about grilling the perfect steak?  I would say compare it to the Deming cycle, or PDCA (Plan-Do-Check-Act) cycle to illustrate the point.  PDCA is a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement.

  • Plan what you intend to do. In this step assess where you are, where you need to be, why it is important, and plan how to close the gap. Identify some potential solutions.
  • Do try out or test the solutions.
  • Check to see if the changes you tried had the effect you hoped for, and make sure that there are no negative consequences associated with them. Assess if you have accomplished your objective.
  • Act on what you have learned. If you have accomplished your objective, put controls into place so the issue never happens again. If you have not accomplished your objective, go through the cycle again, starting with the Plan step.

PDCA applies to entrepreneurial ideas, application development, and anything that happens to do with my grill.  Realistically, you can apply it to anything where unknowns exist.  There are just so many variables, you need to be prepared to act and pivot.  I have grilled countless steaks and have refined my process to the point that it finally meets my quality standards.  On occasion, I do check to see if my process holds true and all I do is mess up a good steak.  I won't go into specifics as to what my perfect grilled steak process is.  (Unless someone asks)  Rather, I'll say I documented it and saved it in Evernote.

Now if only I could do the same with a hamburger.