A couple of days ago, Uncle Bob Martin blogged about the foreman in software development. In it he makes some claims with regards to a role in software development that acts like a foreman on a traditional construction site. Uncle Bob claims that the foreman should be the master of having commit rights, and granting those to team members that prevailed long enough. While the idea reminded me by-and-large to the practice on some open source projects, I am not so sure whether we should start installing foremen (and forewomen) all over the place. Let’s see why.

Batch Size

Imagine the picture painted by Uncle Bob. There is a single person responsible to review all the commits to the main line. I assume an agile team limited to 3-9 people here. That person would become the single source of approval for all the stuff that makes it to the version control system.

In Lean thinking terms there would be delayed feedback for the features introduced. Depending on how often programmers send out pull requests to their foremen, the batch would be larger or smaller. The larger the batch size, the more potential problems could accrue. One can argue that this educates the novice programmer to commit smaller changes to the foreman, while the more advanced programmer could go with larger batch sizes, since there are hardly any changes necessary. Interesting idea.

Unfortunately that delayed feedback would lead also to more problems building on other problems in the change set that is sent to the foreman. With the delayed feedback from the foreman there would actually be fewer learning happening at the moment the problems are introduced. There would also be more learning piled together.

Unfortunately humans are terrible when it comes to learning in large batches – at least to my experience. I quickly feel overwhelmed with lots of feedback, close to being unable to respond at all. Of course, different people handle negative feedback differently, and certainly one can learn to deal with that kind of feedback.

However, what’s the outcome here? Why would a foreman be interested in the commits from any individual programmer? Ideally the programmers would have paired on most meaningful production code, anyways, wouldn’t they?

As Uncle Bob also points out, the foreman would be interested in the individual commits in order to help them solve problems of different nature. In his second blog entry he expands on this. The reasons he lists include personal coaching, and the team’s ability to provide that programmer some relief.

Reviewing all submissions is truly one way to become aware of personal problems, like your wife being diagnosed of cancer. I think there are more effective ways to become aware of these. Trustful 1-on-1 meetings are one way to deal with them.

Responsibility

Over the years I have experienced varying behavior from developers whenever there was a testing in place. Some programmers knew how to include them in their development efforts. Others, well, didn’t, and were rather fighting them. I even saw programmers that submitted their code without trying it on their own. In the end, there was a testing department taking a look, right?

The same could probably happen with a foreman having a look on each and every commit. But there is another social aspect in this dynamic. What I learned from the drama triangle, is that the foreman would eventually become an offender for the programmer that wants to improve, and get a higher salary. A programmer would have an easy time playing the role of the victim in this dynamic, rather than seeing the potential in the feedback from the more senior programmer to excel in his own skills. So, there is a high social cost attached to this, and I have heard about this same dynamic in many open source projects where the bad master committer won’t pull certain requests.

But also consider the workload for a large team on the foreman. Of course depending on the output of the programmers involved, I think the foreman could become overloaded by commits quite easily. This is speculation, since I never worked in such an environment. In my past, though, I took on the habit of working through the commits on our version control system to see which changes I could pull without risking to loose my test system. I gave that one up after a while since it was too much work working through all the commits of three different teams. I felt overloaded.

So, besides the workload, there is lack of responsibility for the individual work, and a weird dynamic from the drama triangle as social costs in play in that model.

Manager Teachers

Another thing I learned from the Toyota Production System is the idea of manager teachers. At Toyota, managers do not advice people on what to do. Rather they understand their managerial role as teaching others to become a better employer. These managers try to teach everything they know to their direct-reports. Thereby, a culture of growth is created to the extent that people need more time to advance in the career system, but that advance for good.

Instead of rejecting all the bad commits that come their desks, master programmers probably should work closely with apprentices to teach them the tools of their trade. If masters grow journeymen, and journeymen teach apprentices which tools work good, and how to working habits reflect the culture in the code, the overall code base does not have to start to rot.

Unlike foremen, people in programming should create a culture of learning from their peers. We should create a safe environment where everyone feels save to learn new stuff every day.

Situational Leadership

After all, I think the foreman model has a context where it makes sense. The Situational Leadership from Hersey and Blanchard reminded me of a possible context. When you learn something knew, you might need more direction. This holds true for apprentices in their first few days. This also holds true for cross-trained employees when they learn a new skill.

I think the foreman model makes sense in the telling quadrant of the situational leadership model where the employee needs more direction. Over time, though, the team member becomes more capable, and over time also more willing. The underlying leadership model should shift at this point to more and more degrees of delegation.

The situation that Uncle Bob describes in his second blog entry can be addressed by nurturing a culture of openness and more direct mentoring for example from the ScrumMaster or coach. The leadership in the code probably is better addressed by a “Go Gemba” attitude – go see the workplace. Unlike physical production, for software development “Go Gemba” probably still needs to take a look in the code. Whether you address that by creating a foreman bottleneck for changes to your main line, or by pair programming, and coaching on the job, should be a question better answered by the underlying situation for the individual team member. Some need more direction, others more delegation. Pick your battles.