Chapter 14. Review the code

by Robert C. Martin (Uncle Bob)

One of the biggest mistakes that new software team leaders make is to consider the code written by the programmers as the private property of the author, as opposed to an asset owned by the team. This causes the team leaders to judge code based on its behavior rather than its structure. Team leaders with this dysfunction will accept any code as long as it does what it’s supposed to do, regardless of how it’s written.

Indeed, such team leaders often don’t bother to read other programmers’ code at all. They satisfy themselves with the fact that the system works and divorce themselves from system structure. This is how you lose control over the quality of your system.

Once you lose control, the software will gradually degrade into an unmaintainable morass. Estimates will grow, defect rates will climb, morale will decline, and eventually everyone will demand that the system be redesigned.

A good team leader takes responsibility for the code structure as well as its behavior.

A good team leader acts as a quality inspector, looking at every line of code written by any of the programmers under their lead.

A good team leader rejects a fair bit of that code and asks programmers to improve the quality of that code.

A good team leader maintains a vision of code quality.

They’ll communicate that vision to the rest of the team by ensuring that the code they personally write conforms to the highest quality standards, and by reviewing all the other code in the system and rejecting the code that doesn’t meet those exacting standards.

As teams grow, good team leaders will recruit lieutenants to help them with this review and enforcement task. The lieutenants review all the code, and the team leader falls back on reviewing all the code written by the lieutenants and spot-checking the code written by everyone else.

Code is a team asset, not personal property. No programmer should ever be allowed to keep their code private. Any other programmer on the team should have the right to improve that code at any time. And the team leader must take responsibility for the overall quality of the code.

The team leader must communicate and enforce a consistent vision of high quality and professional behavior.

Roy’s analysis

Uncle Bob advocates that we influence the team by creating environmental rewards for writing good code and punishments for writing bad code, which can result in a positive outcome.

Here’s an apparent paradox, though: you’d be hard pressed to find any team leader who disagrees with any piece of Uncle Bob’s advice, and yet it’s extremely difficult to find a team leader who practices it.

This is only an apparent paradox. Once we look at things from the systems viewpoint, it begins to make more sense. A good way to look at the systems view is to think about the influence forces as applied to team leaders who don’t practice what they preach.

To start, let’s choose one core behavior we’d like our team leader to embrace:

A good team leader acts as a quality inspector, looking at every line of code written by any of the programmers under their lead.

Let’s look at each force, and try to imagine a scene from a real-life enterprise organization setting:

• Personal ability: Yes, that leader knows how to review code.
• Personal motivation: Yes, that leader would like to inspect everyone’s code. This is where many people get stuck. Obviously leaders want to do this, and they think it’s a good idea. What gives?
• Social ability: When the leader approaches a member of the team about the quality of the code, the member asks, “Should I refactor this instead of finishing this other urgent feature you told me to finish yesterday?”
• Social motivation: Other team leaders that are well respected by this leader, and have been working in the company for a long time, seem to pay no attention to code reviews. We could argue if they should be well respected, but that’s a different paragraph.

OK, socially, when working with peers and colleagues, things seem to be getting a bit murky, and that team member has a good point: We’re under some serious time pressure. You could say we’re in survival mode; should we refactor that code?

On top of this, other team leaders seem to be doing fine (they do bellyache quite a bit about the quality of the products, but hey, don’t we all?) without code quality looming over their heads.

Maybe the problem is more systemic. Let’s look at the last two factors:

• Environmental ability: Are code reviews physically possible? Yes. The leader can see everyone’s code easily if they choose to.
• Environmental motivation: Does the company reward the leader for not doing code reviews? Is there some punishment for taking the time to review code? In most companies, yes. There’s time pressure to get code out the door, and quality takes a backseat. It’s not necessarily good for the company, but customers don’t usually understand this, and sometimes team leaders aren’t committed to resisting this pressure.

These last two points complete our systems perspective. They point to a serious flaw: the team leader doesn’t have the incentive to do the right thing—or, worse, is incentivized to do the wrong thing or else be berated by the managers.

Without solving this issue, as well as the social issues, it’ll be difficult to see many team leaders taking that extra step toward the things they believe in.

Uncle Bob is asking team leaders to influence the team in the right direction by changing environmental forces, but team leadership might depend on other environmental forces already being in place, which is one of the reasons why many leaders today talk the talk but don’t walk the walk.

Exercises

• What would you change in your workplace, at the system level, to enable team leaders to take responsibility for the overall quality of the code?
• What’s the first step toward making this change happen? For example, “I’ll set up a meeting with the CTO about this,” or “I’ll do a presentation to X folks about this” might be a good step, but your situation may need different steps first.

ROBERT MARTIN (UNCLE BOB) has been a programmer since 1970. He’s a Master Craftsman at 8th Light Inc. and the author of many books, including The Clean Coder (Prentice Hall, 2011), Clean Code (Prentice Hall, 2008), Agile Software Development (Pearson, 2002), and UML for Java Programmers (Prentice Hall, 2003). He’s a prolific writer and has published hundreds of articles, papers, and blogs. He served as the editor-in-chief of C++ Report and as the first chairman of the Agile Alliance.