Last week, Robert C. Martin (“Uncle Bob”) wrote a blog post about how software teams need a foreman. A couple of days later, he responded to the first wave of criticism. He is wrong about this one.
First, I thought I’ll let better people than me respond to those blog posts. But after some interesting discussions on twitter, I decided to write a longer post. Because, reasoning why the foreman idea is wrong takes more than 140 characters - at least for me.
Note: None of the stories in this post did happen exactly as I tell them. Some are a mix of several experiences I had with several teams, and stories good friends told me. Some are entirely fictional. So, they are not true stories, but there is truth in them. Also, they are probably a bit exaggerated.
The foreman Uncle Bob describes here is the guy who makes sure all the tests are written. The guy who makes sure that all the exceptions are caught. The guy who makes sure all the errors are checked, and that references can’t be null, and that variables are thread-safe. The guy who makes sure that the programmers are pairing enough, talking enough, planning enough. He is the only one with commit rights. He will review everything the other team members produce, and reject those packages that are not sufficient in his eyes. Here ares some of the reasons why this is a terrible idea.
1. Having a foreman destroys trust, team spirit and motivation
When a team has a foreman, this is evidence that there is a severe lack of trust within the team. Obviously, most team members are not trusted to commit stuff - because they do not have commit rights. We already know that the most experienced programmer - the foreman - does not trust some others to do their job. So there is no reason for team members to trust each other.
There could be teams where the foreman trusts all team members, the team members trust each other and everybody trusts the foreman. But I doubt it will stay that way for very long. Maybe the team changes. New members will be distrusted by default. Or the foreman makes some bad calls. Trust in him will suffer. From there it will go down.
Team members will either work together against the foreman or work against each other to please the foreman. One person with commit rights is equal to individual performance assessment of team members! Everybody knows how often Fred, the foreman, has rejected commits from Sam, the system programmer. Team spirit: Gone. And with it: Motivation.
2. The foreman is not your peer
He is the one with the commit rights. He can reject everything you did, for any reason. Do I have to say more?
Actually, I have to. At some point, Fred noticed that several team members were making the same mistakes over and over again. They even would not agree with him that they made mistakes - They insisted their code was good! Fred decided to write a weekly newsletter with common mistakes, so all team members could learn something. This obviously led to a lot of finger pointing because it was easy to find out about which commit Fred was talking.
Also, Alice, the architect, a close friend of Fred, decided at some point to rewrite code so that it would please Fred. This would save Fred a lot of time. Don, the developer, would check something in, and hours later the code was completely changed. Don was not allowed to change it back, because only Fred had commit rights.
Even if the foreman was your peer when he startet, this will change. Because he will make calls you don’t agree with. And you have no power in the discussion.
3. The foreman will not give up his position
He has earned it. He is the most experienced developer. Of all the other developers who have been here long enough to be considered as foreman, he is clearly the best.
Sadly, this becomes a self fulfilling prophecy. Everybody has to agree with the foreman. He might listen to your arguments, but if he still disagrees, you have no way of winning this argument. Even if the whole team agrees with you. So you either do what the foreman says, or you leave.
In such a situation, the good developers leave first. The ones how stay are the ones who have to. Do you really want to work with a team where most members have no other option?
Fred (actually, one of the Freds I know) even told me once: “Our programmers do not want more responsibilities. We have hand-picked people who only want to program and do nothing else.”
4. The foreman is probably not "the best"
The real problem that arises when the foreman will not give up his position is that he is probably not the best. Not in every aspect of the project.
In any non-trivial project you need a lot of different skills. You need someone who is really good at TDD. A hibernate wizard. Somebody who can tune the DB statements. Someone experienced at object oriented design. Architecture. Performance tuning. User interfaces - Maybe even many differen UI technologies. EAI. External systems. The best person on your team in each of these areas is probably (or hopefully) not the same person.
Or, even if he is the best now, in every area of experience needed for the project, he might not stay forever. Fred (as always, one of them) was a good programmer. He really knew the technology stack. But his object oriented design was a bit old fashioned and simplistic - You know, “dog extends animal”, no SRP or OCP. But you could not argue with him about OOD because he was the foreman.
5. The foreman will have the sole responsibility for quality
I mean, hey, the foreman will tell me if I have enough tests. I’ll just commit.
The project has a bug? Why did the foreman not spot it?
How should I have known that performance in this part of the code is critical? We have a foreman for that!
This is not good. When quality is not the responsibility of the people who write the code, they will stop to care. And then, the code review will be there to spot low quality, not as a quick check if quality is still high. And then your process does not have quality built in. It has quality assurance afterwards. Your lead times will increase because you will find more and more issues during review that could have been prevented before. Your cycle time will decrease because you have more work in progress caused by more rework. Your progress will slow down. And quality will not be any higher - it will probably be lower too, because you can not find all the issues after the fact. You have to build quality in. This is a lose-lose-lose situation.
6. The foreman will have the sole responsibility for architecture and design
He will only commit code that fits his ideas of the architecture and design.
Alice (…one of them…) was the official architect on the team, and management trusted her decisions. If there was a longer discussion about architecture, management would always be on Alice’s side. Even when all others had a different opinion. At some point, most team members gave up arguing with Alice. They just did what she told them.
Her decisions were mostly good. Maybe not the best - we don’t know because we never tried something else - but good enough for the product to be a success. But sometimes she screwed up - like we all do from time to time. But since she was the only one who made architecture decisions, those situations did not end in a “we are all in this together” mood in the team. It led to schadenfreude and finger pointing.
At some point, the foreman might even decide that the reviews start to take really long, so he’ll just tell the developers how to do their tasks. This will speed up the whole process (Fred (you’ll never know which one) did). Since he already has an idea how to implement all the tasks, he also has the final call on estimates. I mean, he is the best and most experience developer! Of course, management trusts his estimates more than some people with poker cards!
7. The foreman is the bottleneck
All tasks have to be reviewed by him, and if he rejects them a lot, the project will be behind schedule. If he does not have enough time to review all the tasks, the project will be behind schedule. Or have an architecture or design he does not approve of Gasp. So he’ll have to tell the developers exactly what to do - then he does not have to reject tasks so often (see above).
8. The foreman will have the sole responsibility for schedule
Because he has the sole responsibility for quality and architecture and design, he will also have the sole responsibility for the schedule of the project. Uncle Bob even agrees:
He will be responsible for the schedule because he is the bottleneck. And he was responsible for the estimations that led to the schedule in the first place. So if the project misses a deadline, this can be traced directly back to him.
Since Fred was responsible for the estimates and for the schedule, estimates were heavily padded. Sometimes, team members would sit around for days and do nothing. Because they didn’t have to - There still was time.
9. The job can be done by the whole team
If one person can do the job, the whole team can:
Uncle bob answered
Ok. First, you do not call a software developer “noob”. Ever. Even if they came straight from university. They have been studying for several years and are highly trained academics. They still have much to learn, but they are not “noobs”.
Second, this does not matter. When management doubles the team with new people, there are still enough experienced developers to do pair reviews of other pairs with them.
So, the whole team can do code reviews. This means the whole team should do them. Then, everybody will be responsible for the quality of the product, the design and architecture of the system and the schedule of the project.
10. Maybe new developers should do the code reviews
Good object oriented code can look like severe over-engineering to an inexperienced developer. At least, it looked like this to me. Alice would re-write my code so that classes were really small and methods would only have 3-10 lines and call lots of private methods which called other private methods, all with a really long name. It was awful. Over-engineered. When I asked here why she did it, she just told me it was better this way. Also, Fred would approve of this code.
Now I know she was right. And now I know why she was right. But since discussions were fruitless anyway (see above), i just shut up and went on.
On the other hand, hopelessly over-engineered code might look OK for people who have been working with it long enough. Sam had no problems with a class hierarchy 12 layers deep.
Maybe new developers should have the right to reject code they don’t understand. Maybe they should have the right to reject code that looks over-engineered to them. The following discussions within the whole team will probably bring new insights for everybody, not only for the newcomer.
11. Young developers probably learn most from their peers
Maybe Alice even told me why her way was better than mine. I don’t remember anymore. It did not stick, because I just did not believe her at the time. And discussion was fruitless anyway, so we did not discuss this any further.
In the seven years of my career, I learned a lot. And I hope to learn much, much more in the coming seven years. I learned a lot because I was lucky to work with really good people. People much better than me. But I only learned from my peers. I learned from the discussions with them. I learned from arguing with them which way was better. Most of the time, they won this argument. Because they were right and they could convince me about it. But sometimes I could convince them that I was right…
I hope I’ll never stop listening to developers less experienced than me. I’m sure I can learn from them and I hope they’ll learn from me. And I hope I can always work with developers who are better than me. I will try to continue to learn from them.
No, we don't need a foreman
I know a lot of what I wrote sounds like very dysfunctional organizations. But dysfunctional organizations exist. Lots of them. They do not exists by pure chance. They became that way. They might be the lowest energy state for large companies. People are not perfect. Systems deteriorate.
We have to constantly fight to keep the company in a higher energy state. We don’t need a foreman. The presence of a foreman might even be a catalyst for the system to deteriorate. We need more trust, team spirit and more time to learn how to do the right thing - As a team. And we need more and better peer reviews.
You might be also interested in:
- Scrum, But...: Does the label "ScrumBut" for a Scrum-like process lead to meaningful discussions? Probably not...
- What is an estimate, anyway?:An introductory blog post about estimating development effort.
- Improve your Agile Practices: A FREE course that teaches you how you can improve as a software development team
