Do we need one?

When I talked about difficult conversations at Agile Yorkshire last week, the subject of "Hero Programmers" (HPs) came up. What is a "hero programmer"? Lets give ourselves a working definition. A Hero Programmer is someone who:

• Is deferred to by all the other programmers
• Has deep technical knowledge of the product/system.
• Very busy, he works long hours, he pulls all-nighters for the good of the company – hey, he’s a HERO.
• Widely regarded as indispensable by other people in the company.
• Rarely takes holidays.

Sounds great. A hard-working, highly-skilled and very valuable member of the team. So what’s the problem? Well, there can be a few problems. Here are some other possible features of the Hero programmer.

• Makes big technical decisions without consultation (i.e. changing the implementation language for the entire project).
• Saves technically difficult work for himself rather than distributing it through the team.
• Decides what features get worked on next
• Regards himself as the architectural (or even moral, aesthetic) guardian of this system. And regards these ideas as higher than any mere “business” goals.
• Refuses to pair program (often suggests code reviews as an alternative, though they rarely actually happen).
• Rejects as a "waste of time" or a "fad" any of the basic technical improvement practices suggested by Agile: continuous integration, refactoring, Test Driven Development and even sometimes source code control.
• Is DEEPLY suspicious of consultants.

Do any of these sound familiar? Is this you?

When I talked at Agile Yorkshire the subject of "Hero Programmers" (HPs) came up when I was talking about issues around identity. I talked about 5 identity dimensions which I got from this book - "Beyond Reason":

• Appreciation
• Autonomy
• Status
• Affiliation
• Role

And when you think of Hero Programmers in line with these identity dimensions you can see how difficult it is to budge an HP. Along each of these dimensions, our HP is strongly rewarded. They get lots of appreciation – bosses, project managers, customers are grateful when they finally get the functionality that they want. Because the HP is the only one that can do a lot of the trickier bits of development they have the autonomy to decide what gets done, in what order. In the company and sometimes also by customers the HP is regarded with high status.

Very often, the HP's affiliations are not to the team that he works with. He may also feel an affiliation to an international band of coding gurus whom he talks to daily online and sees at conferences. To him, what they think of what he does is far more important than his work colleagues. And this brings us to his role as he sees it – keeper of the pure flame of the architectural (or sometimes even artistic, ethical) integrity of the project.

He probably gets very sniffy whenever anybody talks about money.

So, along 5 different measures of positive identity, the position of HP buries the needle. No wonder HP’s don’t want to change. From the HP’s point of view, the only direction is down. If he changes the way he works, if he gets promoted, he moves away from things that he knows (software development) to things he doesn't know (business, team-leading, management).

Do you have a problem with an HP? Here are some things you might try that I know have worked elsewhere. Most of these suggested approaches involve increasing the HPs status and autonomy rather than attacking and restricting them, which is what the usual (and greatly feared) move into team-leading and project management threatens:

• Reduce the work load for the HP: Insist that he take his holiday. When he is at work, he shouldn’t be max-ed out, he should be given time to teach others what he knows and think strategically.
• Turn the HP into an internal consultant – whose job is to roam between projects and solve the really hard problems.
• Turn the HP into a "fellow" who's job is to think great thoughts and come up with new ideas.
• Get him to talk and teach, write books, to your staff and on the conference circuit. It will be worth the travel expenses.
• Turn the HP into an external consultant, hire out his specific, excellent skills to other companies.
• Turn the HP into an open source guru – put some aspect of your project out in the public domain and give your HP the task of leading it.
• Turn your Hero Programmer from a Code Geek into a Business Geek. A friend of mine used to write the software for the hedge fund that he part-owns, but now he involves himself far more in the minutiae of the tax laws and the mechanics of limited liability partnerships.

One thing that occurs to me is that if you keep seeing the same situation again and again, it must be a "stable" situation – what John Nash would call an "equilibrium". There are powerful the drivers are to keep somebody in this role (run through the identity list and think about the role of project manager – why would anybody want to be one?). The trouble is that it's a local equilibrium that prevents any kind of positive change. If a team that has formed around a "hero" programmer, out of frustration with this stability and stuck-ed-ness, very bad things can happen.

Yeah, yeah, he's a life-saver, but you don't have to work with him

If the HP is a founder they can be ousted in a coup by other board members. Or if the company finds finance, or is taken over, they are swiftly removed (VC’s have developed the sharpest skills for dealing with HPs through sheer necessity). Often the team or the company around the HP just evapourates, the juniors get less junior, read the writing on the wall and walk away. But these are actually good outcomes compared to the most likely outcomes in the short term.

Things carry on as they are.

Notes from a fry-up lunch

I had a fry up lunch on Wednesday with a friend of mine who's a developer and two of his fellow developers (he can own up in the comments if he wants to) a few things came up in conversation that I want to note down here - I might write longer pieces on them later.

• Quote: "The two projects that we made money on are the two projects where we said [admitted?] that we don't know". The standard case where the customer comes to you and says "How much for X" and you say Y pounds RARELY MAKES MONEY! But the model where the customer come to you and says "How much for X" and you say "Mmm, dunno. Do you want to pay me a little bit of money to have a look?" THAT MAKES MONEY! Maybe you can't get there straight away, maybe you have to do some fixed price stuff to get to that stage, but isn't good to know where you should be heading?


• A compelling reason for becoming involved in open source is that you get the respect of your peers. You also get coached by people who know what they're talking about. This is very different from the kind of feedback that you get from customers which is all about bugs or things not looking the way that they should. Perhaps pair programming could be a kind of mini, in-house open source in this way.


• Related to this - the loneliness of the self-taught programmer. Most programmers are autodidacts - they teach themselves. This means that some areas are very strong and some areas are very weak. When other people look at their code self-taught programmers can feel very foolish. If you're a self-taught programmer and you're trying to work within a framework which is supposedly helpful to development, such as test driven development, or pattern-based design, this can be very traumatic and cause you to really lose self-confidence. Maybe this is why some guru/surgeon programmers are so reluctant to pair program.

RSS - Rogue Surgeon Sydrome

The surgeon model as advocated by Fred Brooks is the second most efficient method of developing software. The analogy is with the surgeon who is the focus of the whole show during an operation - the one that all the other members of staff are there to support. In many small technology companies, essentially, you have one surgeon/founder/guru who writes all the code himself, or certainly writes all the difficult stuff himself. Quite often the surgeon was the one who came up with the idea for the software or the business in the first place, it's his drive, his creativity and willingness to do something different from the herd that is the reason that there is business at all. If the surgeon is good this can be a very effective way of getting software written. For a while.

There's a problem though. The surgeon model doesn't scale. At some point a successful piece of software is going to need a lot of boring, non-charismatic things done to it, like multiple language support and multiple platform support. At some point the organisation is going to grow and start to hire people who aren't doing it for love, but for money. Somewhere around 10-15 people organisations can no longer be run charismatically (because everybody just loves being in the founder's gang) and have to start being run bureaucratically (because people do the job they are paid to do). Accounts staff, sales staff and business development aren't the kind of people that the surgeon/founder - as someone I know delicately put it - wants to go to lunch and eat noodles with. To avoid these problems many new media and technology companies get stuck at around 10-15 employees, vaguely hoping that they'll be bought out by some Silicon Valley conglomerate. With no other growth/exit strategy they stagnate. It can be unpleasant to watch and even more unpleasant to experience.

This is a very tricky situation to be in and there aren't many good solutions. Quite often the "Surgeon" in this model is a founder of the company. The kind of person who founds a company isn't the kind of person who wants to follow rules. That's how they got where they are, by not following rules. Sometimes for other employees this can be very inspiring. Sometimes it can be very tedious. People who have had to work with Steve Jobs have called this the "Hero shit-head roller coaster". At one company that I used to work for, the "Surgeon"/founder would resort to chanting "Ooh! Aren't we grown up!" whenever the issue of pensions was raised at board meetings. This was infuriating for the other board members who had grown up, had wives and children and would really quite like to not have to survive on Pot Noodles for the last 20 years of their lives.

You can bring in "professional" developers and "professional" project managers - these are people who rely on process rather than charisma to get the job done. But very often they don't sit well with the people who are already there, gathered around the surgeon. When I suggested to one company that I talked to that they deal with this problem by hiring in outside project managers they said "Yeah, we tried that - he got eaten alive." You can bring in professional management and then fire the founder. Apple did this and that didn't work out so well either. What companies really need to do is restructure in a way that allows the company to scale and remain creative. The surgeon/founder should be given a role where he can carry on doing what he's good at - doing new things, breaking the rules, in business speak R&D.

Agile processes can help ease the passage through this difficult period. Pair programming allows the surgeon/founder/guru to spread his knowledge of the software around the development team. Test driven development and refactoring reduce the demands on the surgeon/founder and leave him free to do what he's best at - thinking good thoughts, breaking the rules and coming up with new product innovations. But Agile can't be the whole answer. You're probably not supposed to say this, when you work for an Agile training and consultancy company. Things will only really move forward when the founder and others on the mangement team admit to themselves and each other what they actually want from their careers and make sure that this is something that their position in the company can really provide. Maybe this is an Agile process because Agile is all about having those awkward conversations sooner rather than later.

This isn't just a problem in software development. I've been talking it over with Dave Dawes who works with social enterprises in the Health sector and he recognises it as a common problem. In many fields, amidst all the hullabaloo about the need to support entrepreneurship, the need to support successful organisations that are ready for the second wave sometimes gets lost.