This is a response to a response to a response. Bear with me…
Recently, Robert C. Martin (a.k.a. “Uncle Bob”) wrote an article called Where Is The Foreman. I’d encourage you to read this (and the other links here).
The gist of the article is that a construction site needs a foreman to ensure things are running smoothly, and likewise a software team needs a foreman for the same reason.
Bob responded to this with what he felt were some clarifications. He shifted the analogy to that of a coach. To sum up his response, he went through this line of reasoning:
- a coach is not a peer
- here’s a scenario without a coach: everything falls apart
- here’s a scenario with a coach: everything is ok
- we need coaches: a coach has commit rights and can revoke commit rights
Here is my response to his response.
A coach is not a peer
I would argue that because everybody has different strengths, every team member is a coach in the context of their strength. The JVM tuning expert can coach team mates on matters of JVM tuning. The design patterns expert can coach team mates on matters of design patterns. And so on… Not everybody is a peer in the same area, but everybody on a team is a peer on the team with the same rights and responsibilities.
Granted, a team is expected to have a spectrum of experience levels. Hopefully senior engineers will have more areas of expertise and do more coaching than junior engineers, but my point is that responsibility of instructing and helping lies with the team, not with a single individual.
Scenario without a coach
Bob (describing this scenario): “Nobody sees the stream of commits that is reducing the code coverage…” I would argue that Bob is setting up a Straw Man argument. He is describing a team that doesn’t have a foreman and proposing that the lack of a foreman is the problem. But if the foreman is the only person doing code reviews, then of course lack of a foreman is a problem… because lack of code review is a problem!
Scenario with a coach
Next Bob describes a scenario where there is a coach/foreman who recognizes problems and can intervene. I counter that this happy path is what would happen anyway if 1) all code was code reviewed by team members as part of the definition-of-done, and 2) team members raised concerns with each other first and escalated concerns to management as needed. Hopefully management is paying attention anyway! If there needed to be a larger conversation with an offending coder about declining performance, management is better equipped to have a conversation like that.
If you were the foreman for a dozen developers, and it was your responsibility to review every commit, it would literally be your full time job to do nothing but read code all day. That approach does not scale, and it is not sustainable. Maintaining the quality of the code, performing code reviews, and raising issues with team members and escalating to management as necessary is everybody’s responsibility.
Again, we grant that a team is expected to have a spectrum of experience levels. Junior engineers reviewing each other would likely result in missed bugs. But junior and senior engineers reviewing each other allows junior engineers to learn and senior engineers to catch quality issues. And at the top of the skill chain, there should be peers at the same skill level and qualifications able to review each others’ code.
Coach can revoke commit rights
Bob: “The foreman can revoke commit privileges.” We already have someone with this power. This person is called “the manager.”
Software engineering is a team effort, but it is not a sports team and it is not a construction crew. Maintaining code quality is the responsibility of the team and of every individual on the team. I propose that everything Bob describes about a foreman is something we should already be doing but maybe shaped a little differently: distributing responsibilities across the team (including development and management) as opposed to concentrating them in one or few individuals.