This week I read a blog post titled Where is the Foreman by Robert “Uncle Bob” Martin.
It made me think.
Uncle Bob suggests that a software development team should have a foreman who:
He’d make sure everything was done, done right, and done on time. He’d be the only one with commit rights. Everybody else would send him pull requests. He’d review each request in turn and reject those that didn’t have sufficient test coverage, or that had dirty code, or bad variable names, or functions that were too long. He’d reject those that, in his opinion, did not meet the level of quality he demands for the project.
I agree! Every software development team would benefit from these activities. But why there should be only one foreman?
Everyone Should Be a Foreman
I agree that each commit should be reviewed before it is committed to the version control system.
I agree that if the code has insufficient test coverage or it is shitty, it should be rejected.
I don’t agree that it is a good idea to assign a single person as a foreman because of these reasons:
- It doesn’t encourage learning. The best way to learn is to read code written by other developers. If there is only one foreman, the only person who reads the code written by other developers is the foreman. This means that the team members aren’t encouraged to learn from each other. Sure, it can still happen but the odds are that team members will only learn to write code which pleases the foreman. Is this a good thing? Of course not!
- The foreman is the only person who knows the whole application. Because the foreman is the only person who reads the code written by other developers, the other team members know only such parts of the application which were written by them. The rest of the application is unknown to them. This is very risky strategy because the bus factor of this kind of software projects is one.
- No one is expert in everything. Although developers can write frontend code, backend code, and take care of the database (maybe not), often each developer is specialized in something. This means that a single person is rarely the best authority in everything which is done in a software development project. That is why it is just plain stupid to assign a single person to control the quality of the application.
- It demotivates the team. Giving this kind of power in the hands of a single person gives an impression that the team members are just worthless grunts whose only task is to write code which pleases the foreman. To make matter worse, it implies that this kind of practice is required because the team isn’t capable of writing good code without supervision. This is insulting, and I am pretty sure that the members of this team are already looking for a new job.
- The foreman is the bottleneck. If the foreman is the only person who can commit code to the version control system, no progress is made until he has reviewed the code. This means that he foreman becomes a bottleneck. Of course you can dream that the team members are working on other tasks when they wait for the foreman to review their code. The reality is that they are so demotivated that they are probably picking their noses and reading Hacker News. They are doing nothing and you still have to pay to them.
There is a lot better way to do this. Every team member should be a foreman. We can do this by following these simple rules:
- All commits must be reviewed before they are committed to the version control system. There are no exceptions to this rule!
- All team members can review and reject commits.
- A person cannot review his/her own commit.
This approach has four big advantages:
- Everyone can make a difference. Because everyone can review any commit which is waiting for a review, everyone can leave their mark to the created software. Software developers want to be proud of their work, and this gives them the possibility to write code and say: “I wrote that”. Developers can never get this kind of a feeling if their code is always reviewed by the foreman because it is not their code. They just wrote it for the foreman.
- Team members can learn from each other. Because team members can read the code written by other team members, they can learn from each other. If they see something that they don’t understand, they can start a discussion with the developer who wrote that code and ask him to explain it to them. This a great way to spread knowledge to all team members. For example, backend specialists can learn from frontend developers and vice versa. Of course you can argue that they can read the code even if they have a single foreman. They can but they don’t.
- There is no bus factor. Because the team members will read code belonging to other parts of the application, they have confidence to make changes to other developers’ code. This means that if a team member gets another job, gets sick, or dies (this happens), it doesn’t paralyze the team. Sure, they are probably upset, but they get over it and can make changes to code written by that developer.
- The team has a common goal. The team no longer consists of individuals who are working to please a single person. It is a group of individuals which has a common goal. This builds an atmosphere which encourages sharing and team work. It is far better option than a poisonous atmosphere where each team member has selfish motives (this is what happens if the team has a single foreman).
This is sounds like a paradise. Unfortunately, sometimes the harsh reality slaps us in the face.
Do We Need a Reality Check?
If everything goes smoothly, the team members can solve their disagreements in a constructive way. This works pretty well most of the time but sometimes the team cannot do this.
If we don’t address this issue immediately, it can cause serious damage to the team sprit and split the team into several groups which are working against each other.
Do we need a referee?
NO (and yes). We shouldn’t have a referee who has unlimited authority over everything because this person would be a foreman. However, we should have a constructive way to solve these disagreements.
We could have a single lead developer who has the final say but the problem is that this person would be a foreman.
We could have several lead developers who have the final say on problems concerning different areas of the application (frontend, backend, and so on) but these persons would be foremen.
Although people act like responsive adults most of time, this doesn’t happen all the time. If the team members cannot solve their disagreement without damaging the team, we must solve that problem for them.
This is the only situation where a single person must make the final call. I agree that this not an optimal solution but I also think that sometimes in life we must make unpopular decisions.
Do you agree?
