TDD - Tool Driven Development

In order to realize the greatest benefits in application development, it is recommended that you use good engineering practices.  Those practices include continuous integration, paired programming and TDD (Test Driven Development).  Unfortunately, when arriving at a new coaching engagement, it is common that a tool vendor has arrived on the scene before the Agile (engineering and process) coaches.  Just as many are sold on Agile being a silver bullet, I find people are equally sold on the idea that a tool can solve all of their problems. Are clients wrong to assume an enterprise “Agile” tool can transition them away from a “Waterfall” tool?  I'm sure that is what the tool vendor told them.  Though I would agree some of the leading providers do offer more lightweight solutions, the truth is some people (after the sale) get frustrated when they realize their tools need to be customized, to align with their business processes.  Unfortunately, I have seen that customization not happen.  Instead, customers struggle with the tools they have implemented.  They change their development and delivery process so they can use the tools.  They start to practice TDD (Tool Driven Development).

When I show customers they can accomplish what they need with index cards, painters tape, and Sharpies, the next question is how can they modify the tool to align with reality.

Always remember the first value of the Manifesto: Individuals and interactions over process and tools.  Fix your processes first.  Then, and only then, should you look to a tool for efficiencies.

Image Source: Pictofigo

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