By Roy Osherove
This article was excerpted from the book Elastic Leadership.
Robert Martin (Uncle Bob) has been a programmer since 1970. He is the Master Craftsman at 8th Light Inc, and the author of many books including The Clean Coder, Clean Code, Agile Software Development: Principles, Patterns, and Practices, and UML for Java Programmers. He is a prolific writer and has published hundreds of articles, papers, and blogs. He served as the Editor-in-Chief of the C++ Report, and as the first chairman of the Agile Alliance. Here is his advice for new software team leaders and my feedback on that.
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 so long as it does what it is supposed to do, regardless of how it is written.
Indeed, such team leaders often don’t bother to read the 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.
And, once you lose that control, the software will gradually degrade into an unmaintainable morass. Estimates will grow, defect rates will climb, morale will decline, and eventually everyone will be demanding 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 the programmers to improve the quality of that code.
A good team leader maintains a vision of code quality.
They will 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 of the other code in the system and rejecting the code that does not 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 that code.
The team leader must communicate and enforce a consistent vision of high quality and professional behavior.
ROY’S ANALYSIS
Speaking from the influence forces point of view, Uncle Bob advocates that we influence the team by creating environmental rewards and punishments for writing good code (the team leader says it has to be done, or else…) which can definitely affect a positive outcome.
Here’s an apparent paradox, though. You’d be hard-pressed to find any team leader that disagrees with any piece of this text, and at the same time it is extremely difficult to find team leaders who actually practice what they claim to preach.
This is only an appranet paradox, however. Once we look at things from the systems viewpoint, things begin to make more sense. A good way to look at the systems view is to think about the influence forces we just discussed to try to dissect why so many team leaders don’t practice what they preach.
To start, let’s choose one core behavior we’d like our team leader to practice:
— “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. So 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. (one could argue if they should be well respected then, 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 are under some serious time pressure.
You could say we are in survival mode, so should we really refactor that code?
On top of this, other team leaders seem to be doing just fine (they do bitch quite a bit about the quality of the products, but hey, don’t we all?) without this code quality looming over their heads.
So maybe the problem is more systematic? Let’s look at the last two factors.
- Environmental Ability: Can code reviews actually physically take place? Yes. The leader can see everyone’s code easily if they choose to.
- Environmental Motivation: Does the company reward not doing code reviews by the leader? Is there some “punishment” to taking the time to do so? In most companies, and let’s assume in this one as well, yes. There is time pressure to get code out the door, and quality takes a backseat. It’s not necessarily good for the company, but the customers don’t usually understand this, and in many places team leaders are too “weak” to stand up to 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, has the incentive to do the wrong thing, or be berated by the managers.
Without solving this issue, as well as the social issues, it will be very difficult to see many team leaders taking that extra step towards the things they really believe in.
SUMMARY
Uncle Bob is asking team leaders to influence the team in the right direction by changing environmental forces. But getting the team leaders to do this pushing might lead to environmental forces in the first place, which is one of the reasons why so many leaders today talk the talk, but don’t really walk the walk.
EXERCISE
What would you change in the place you work, at the system level, to enable team leaders to “do the right thing”?
What is the first step to making these changes happen? For example “I’ll set up a meeting with the CTO about this” or “I will do a presentation to X folks about this” might be a good step, but your situation may need different steps first.
 |
This article was excerpted from the book Elastic Leadership. For source code and other resources, go to |
