We Need More Foremen

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.

I think the benefits of a foreman are subtle and, yes, there are good arguments against having them too.

I have seen code written by less-experienced developers reviewed and accepted by other less-experienced developers. This code can have any one of a number of subtle problems that only true experience might recognize. On a previous project I have informally reviewed every commit and often managed to stop some problematic code getting into the codebase.

Maybe an informal approach is better and less oppressive. As developers though, we often want “rules” that we “apply each time”, our approach being that if something is worth doing then it is worth doing every time and I think this is where Bob’s extreme view is coming from.

Bob Martin started a bit of a war with his foreman post but I try not to take too much of what people say literally and instead try to work out what I can take from this, if anything. A lot of the “agile coaches” on social media talk about concepts such as “mutual trust” and caring and sharing. In reality, software development for me is about delivering software to fit the customer’s needs – we can grow as people too but a software team should be based on delivery and not be some kind of “support group” lol.

Sometimes. software development feels like a very young, immature discipline that has not really worked itself out, but at least we are all trying to, and we care about it.

I think that these “soft” agile practices works very well when the team has either experienced developers, or both experienced and less experienced developers. If this the case, the experienced developers can take the role of mentors and help the less experienced developers to grow and write good code.

On the other hand, if the team has only less experienced developers, you are probably in trouble. Every developer on that team has good intentions but as we know, the road to hell is paved with good intentions. In this case, the team needs a mentor who can help them to write better code. The actions of this person determines if he is a “bad foreman”.

If he specifies rules which must be followed by team without explaining why they are important, he definitely is a “bad foreman”. On the other hand, if he explains the pros and cons of these rules, everyone can learn something (even the mentor). I think that in this case the mentor would be seen as a team member and not as a “bad foreman”.

By the way, I agree that software development is an immature disicpline but if we keep trying, maybe we can change that in the future.

Unfortunately some of us are still stuck with Subversion, so having a foreman isn’t an option. What we do have is builds that fail when Cobertura/Checkstyle/Findbugs rules are broken, and no checking in of failing builds. We also have codereviews of all checked in code.

I would prefer us moving to Git though, but that is seen as too much of a risk right now. I would much rather have code reviewed before commiting to the branch.

you have a point. Like you said, there should be a person who helps the team members to be act as a foreman. This person could be a “coach” who steps in if a team member abuses his/her foreman privileges.

Also, I think that person shouldn’t be member of the team in question. This rule ensures that the “coach” won’t abuse his/her privileges. What do you think about this?