Lord of the Repository

The man on horseback

In Robert “Uncle Bob” Martin’s “Where is the Foreman”, he advocated for a “foreman” with exclusive commit rights who would review each and every potential commit before it made its way into the repository in the interest of ensuring quality. While I am in sympathy with some of his points, ultimately the idea breaks down for a number of reasons, most particularly in terms of introducing a bottleneck. A single person will only be able to keep up with so many team members and if a sudden bout of the flu can bring your operation to a standstill, there’s a huge problem.

Unlike Jason Gorman, I believe that egalitarian development teams are not the answer. When everyone is responsible for something, it is cliche that nobody takes responsibility for it (they’ve even given the phenomena its own name). However, being responsible for something does not mean dictating. Dictators eventually tend to fall prey to tunnel vision.

Jason Gorman pointed out in a follow-up post, “Why Code Inspections Need To Be Egalitarian”, “You can’t force people, con people, bribe people or blackmail them into caring.” You can, however, help people to understand the reasons behind decisions and participate in the making of those decisions. Understanding and participation are more conducive to ownership and adoption than coercion. Promoting ownership and adoption of values vital to the mission is the essence of leadership.

A recent Tweet from Thomas Cagley illustrates the need for reflective, purposeful leadership:

In my experience, the best leaders exercise their power lightly. It’s less a question of what they can decide and more a question of should they decide out of hand. When your philosophy is “I make the decisions”, you make yourself a hostage to presence. Anywhere you’re not, no decision will be made, regardless of how disastrous that lack of action may be. I learned from an old mentor that the mark of a true leader is that they can sleep when they go on vacation. They’re still responsible for what happens, but they’ve equipped their team to respond reasonably to issues rather than to mill about helplessly.

In his follow-up post, “Oh Foreman, Where art Thou?”, Uncle Bob moderated his position a bit, introducing the idea of assistants to help in the reviews and extension of commit rights to those team members who had proved trustworthy. It’s a better position than the first post, but still a bit too controlling and self-certain. The goal should not be to grow a pack of followers who mimic the alpha wolf, but to grow the predators who snap at your heals. This keeps them and just as important, you, on the path of learning and growth.

10 thoughts on “Lord of the Repository

  1. Pingback: Shut up, salute & soldier on? | Form Follows Function

  2. Responding here because it’s just impossible to hammer a complete thought into Twitter.

    ““You can’t force people, con people, bribe people or blackmail them into caring.” You can, however, help people to understand the reasons behind decisions and participate in the making of those decisions. Understanding and participation are more conducive to ownership and adoption than coercion. Promoting ownership and adoption of values vital to the mission is the essence of leadership.”

    Yes, but I’d change one thing. Code inspections, and indeed software development in general, needs to be a meritocracy. You don’t get to do it until you’ve shown that you either can do it or can safely learn to do it. The junior member of the team doesn’t hold code reviews. Or touch a prod environment. Not until they’ve shown that they can do it safely and well. But this only works if the group is committed to helping every member reach a higher level of excellence. The best dev teams I’ve ever been a part of did just that. Those who can, do. And teach the ones who can’t. At least, can’t yet.

    To tie things back around, this is the major failing of the dictatorial approach. *To me* it isn’t that it doesn’t scale. The problem is that it actively prevents people from getting better at what we do. More, it disincentivizes them from trying anyway. The worst dev teams I’ve had to deal with operated like this.

    Like

      • Like all cultural aspects, it flows down from the top. If you find dev teams that take a dictatorial approach then you can often find a Director or higher that’s a control freak. If you find dev teams that refuse to work cross-concern, even when it’s to everyone’s benefit (dare I use the word “synergy”?) then you can find leadership that is very siloed from each other and who believe that territory is more important than the overall needs of the enterprise.

        Liked by 1 person

      • Absolutely. That’s one of the drivers behind my recent posts about fractal systems (software & social). Focusing too intently on one part of a system of systems risks creating the perfect square peg for an ecosystem of round holes.

        Like

  3. “square peg for an ecosystem of round holes.”

    Interesting that you put it that was. I’m just out of an environment where certain basic pieces of functionality were implemented four times. Once for each dev group that needed it. The first time I dared suggest that one group use a service another had provided, there was stunned shock. Followed by a flat refusal. I gave up when yet another implementation was needed and I was told that the correct solution was a web service that consumed the existing web services and collate the results.

    This isn’t just complaining about a dreadfully common WTF (Worse Than Failure). The point is, that was the culture at the CxO and VP level. Jealously guarded fiefdoms and a refusal to work together cross-functionally. Companies purchased for products that another group refused to use because they weren’t consulted. Another group commissioning software from contractors because the group was theirs and they shouldn’t have to go through IT.

    As is above, so is below.

    Liked by 1 person

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.