February 24, 2014

...Learn TDD with Codemanship

Why Development Teams Need To Be Egalitarian

In a recent blog post, Robert C. Martin proposes that teams need a technical authority who guards the code against below-par commits.

Uncle Bob argues that you wouldn't fly on a plane without a captain, or live in a house built without a general contractor overseeing the work to make sure it's up to snuff.

I feel I'm a little closer to this problem, having specialised in these "technical authority" roles for most of my freelance career, and having been embedded with teams in the recent past.

The statistics teach us that once code's checked in, the ultimate cost of it to maintain could be 7 times higher than it cost to write in the first place. So Uncle Bob's right, of course; someone should be casting a helpfully critical eye over commits and protecting the code from work that is, for whatever reason, not good enough.

Where we differ is on who that someone should be.

Here's the thing; leading software developers is like herding cats (except that cat herders would probably count themselves lucky if they knew how difficult it is to lead developers, frankly.)

Even the most junior software developers tend to be highly educated, highly intelligent people. These are not bricklayers, or co-pilots. What we do is orders of magnitude more complex and intellectually demanding. Better, I think, to compare software developers to, say, scientists.

Who keeps scientists in check? While professional scientists no doubt have supervisors (e.g., in a laboratory, or the head of a faculty), these individuals are not the arbiters of "good science", or of what's true and what isn't.

The equivalent of a software commit might be submitting a paper to a peer-reviewed journal. There, the key word is "peer". The claims made by a scientist are subjected to exactly the kind of egalitarian scrutiny Bob rails against (no pun intended.)

My own experience, and what I've observed of other software development "leaders" is that when someone takes that responsibility, it can lead to one of two outcomes:

1. The team resents it (or, at least, some of them do), and much of your time is spent dealing with the politics of being the guy who says "no". Don't underestimate how much time this costs.

2. The team accepts it, and resigns responsibility. This is no longer their code, no longer their design. It's your code, your design, and they're "just following orders". Again, never underestimate how readily even the most educated and intelligent people will let themlseves become "institutionalised", losing the desire to take charge of their own work.

As others responding to Uncle Bob's blog post have already suggested, it can work better if the technical authority is the team.

As the team leader, my effort is better spent marshalling and organising the team as a democractic body. I assume - rightly or wrongly - that, collectively, the team knows more than I do. When questions need answering, and decisions need making, put it to the team. Have deliberate mechanisms in place for these kinds of decisions. Be clear what's a team decision and what's a decision for the individual. If it helps, agree a team contract right at the start that sets the "constitution" of the team.

If it all gets a bit "he said, she said", then the team can also collect evidence upon which to base decisions. In particular, they can collect data about the effects of the decisions they make as a team. In this respect, I encourage teams to treat everything they do - every decision they make - as an experiment from which they can potentially learn.

But all of this is highly distinct from being a coach to teams. I absolutely 100% reject the idea that software development coaches should be acting in the way Bob suggests, becxause I absolutely 100% reject the notion of the coach being part of the team.

Been there, done that. The moment the coach starts making decisions for a team, they become the "go-to guy" for those kinds of decisions. There's a world of difference between coaching a team on, say, automated builds, and being "the build guy" on the team. Because that's what happens to coaches. I've seen hundreds of times, literally. Coach or consultant comes in to help a team solve a problem, coach or consultant becomes the solution.

I likee to think of what I do as being a driving instructor (and, warning, here come's another broken metaphor):

When I was 17, my Dad paid for me to have driving lessons. My instructor was a nervous man, and just kept grabbing the wheel every time he saw me doing something even slightly wrong. I had 6 lessons with this guy, and barely learned a thing. Because you cannot learn to drive by being told or being shown how to drive. You must drive yourself. A few years later, when I reaklly needed my license for work, I found a local instructor who had a completely different style. I would drive, and we would chat. Occasionally, he would point out something I could improve on. Even after just one lesson, my confidence grew enormously. I passed my test first time.

That has always stuck with me. The instructor was there to grab the wheel if I did something really stupid or dangerous, but mostly he kept his hands off the wheel and let me drive.

I'm the same way with teams as a coach. I try not to grab the wheel on their projects, letting them drive as much as possible. This is their code, their responsibility.

And if commits aren't up to snuff, that is their problem.

Posted 3 years, 10 months ago on February 24, 2014