Get Rid Of Indispensable Programmer As Quickly As Possible

If a programmer is indispensable, get rid of him as quickly as possible. -- GeraldWeinberg in ThePsychologyOfComputerProgramming

In this context, "indispensable" means two things. First, it refers to the programmer who believes he is indispensable. Second, it refers to the programmer who obfuscates in order to fulfill his dream of indispensability. It does not mean any programmer of higher than usual talent. Talented people, all other things being equal, should be kept.

Getting rid of something indispensable is a paradoxical bit of advice, cleverly designed by Jerry to elicit conversation such as that found below on this page.

Impressive, isn't it?

Makes sense if you think that a programmer is not working well enough with other team mates so the knowledge is not spread in the team.

See ExtremeProgramming, CollectiveCodeOwnership, PairProgramming, HighMaintenanceEmployee

The corollary: If you yourself suspect you are becoming indispensable, use your awesome powers to immediately make yourself dispensable. Find and train understudies.

If they're indispensable, what will you do if they get hit by a truck? ...or quit?

It's a wake-up call: You have a problem, and you need to fix it.

A TruckNumber of one (1) is a wake-up call to far worse problems than the odds of an actual strike by a truck.

By the way, 'Get Rid Of' may just make the indispensable programmer to share his knowledge a way or another. So you get rid of the 'indispensable programmer', because he became a 'dispensable' programmer. Not necessarily fire him...

If there is no way to make it more dispensable, then more drastic action may be taken...

Sort of like MartinFowler's "ChangeYourOrganization" advice... -- JohnBrewer

For a case study of malicious intent to become indispensable, read JobSecurity. -- PCP

This has a bad side as it seeks to make a factory of factory workers...programmers that are interchangeable parts. I think this sort of a rule is bogus, if it fits with the team, great. It's awful to penalize someone for having more aptitude. It may not matter how much they attempt to share if their aptitude exceeds those of their current team mates. This page fills me with Ugh. This sort of practice of killing off individuals that aren't interchangeable can be a way to perform Teamicide.

I disagree with the previous paragraph: It is better to have heteregeneous members in a team. In this case individuals are not interchangeable parts. Indispensable, in this page, mean that an individual is completely indispensable. If that individual shares his knowledge, he may still be considered as the expert, but a more valuable one: he is able to share his expertise! (Expert, yes, but not indispensable anymore). -- JeanMarcHeneman

It is better to not to become indispensable: you can leave your job whenever you want without feeling guilty (and also more ethical) because you shared with the other team members. Business will also be happy in the long term, because they will feel that you left taking care of the company future (indirectly). It is better for everybody to be dispensable. -- JeanMarcHeneman

TruckNumber == 1 <-- very bad

TruckNumber > 1 <-- getting better

TruckNumber == Team Size <-- so what?

-- PCP

I'm very confused. Either I don't understand what a TruckNumber is or you have made a mistake. Seems to be a TruckNumber of 0 is optimal and a TruckNumber == team size is the worst case.

TN is the number of people whose sudden departure would sink a project (or a module, feature, system, etc.). TN == 0 means your project is already sunk! The numbers scale the other way. But I posit that TN == Team Size is only slightly better than TN == Team Size - 1 would be. Do not hunt down and pester the last coder who does not grok some feature just because they never worked on it before!

: If that is the case, the definition on "TruckNumber" is incorrect.

"The TruckNumber is the size of the smallest set of people in a project such that, if one of them got hit by a truck, the project would be in trouble." This definition obscures the fact that individual modules have TN, not generally a whole project, but, like my examples, as the number goes up the project gets safer.

I have a couple of indispensable engineers on my team and I have no intention of getting rid of them. They do a great job mentoring other team members and generally raising the bar on the whole project. If they left, I hope I could replace them with other indispensable engineers. This page stinks of manager speak. Oh no, what if some of the team members are so good that it would hurt us if they left!! That's the whole idea!! It's often these people who share knowledge the most and have the most to offer the rest of the team. This is YetAnotherSadPageForEngineering?. It says, aspire to be good, just don't aspire to be too good because that bad. Did I say ugh already? Life is full of risks. You shouldn't mitigate risks to the point where you have no chance of achieving excellence.

"Indispensable to the team" is different from "Indispensable to the code". We decry the IvoryTower types who do _not_ mentor.

Sure, but an indispensable programmer has very little to do with someone who does not share information or mentor. There is not intrinsic relationship between these two concepts. Often, a programmer is viewed as indispensable because of her ability to teach others the complexities of the system being worked on. Other engineers are vacuum cleaners when it comes to information. No one could keep up with them regardless of their ability to mentor (or teach). However, the team trusts him/her because this engineer is eager to teach all they hoover up. Should we get rid of this person because they are too talented?

Making one self indispensable should be a good thing to aspire towards. Sadly, in this cynical age of SoftwareDevelopment, we only aspire to Good Enough. Apparently, there are just too many risks associated with excellence. I mean, what would happen if an indispensable person left? You'd be surprised. Most upper-managers think this way about whole teams. In fact, I've read stories where executives have tried to slow TeamGel? out of concern that if the team left, another could not easily take over the project. Wow.

I honestly believe that each person on my team is indispensable both as an individual and as a member of the team. I'd also like to think that our team is indispensable as a unit. However, if you abstract the above quote, then our team should be gotten rid of by the company. I honestly think the opening lines of this page are an over simplification that, like so many of these pithy quotes, does more harm than good to the art and practice of software development. If we must make an extreme generalization, why not say something like GetRidOfTightFistedProgrammerAsQuicklyAsPossible?? -- RobertDiFalco

The paper "A Field Study of the Software Design Process for Large Systems" by Bill Curtis, Herb Krasner, and Neil Iscoe in CACM Nov. 1988 (V 31, N 11) pages 1268-1287 says that this advice is completely wrong for large projects. All the large projects that they studied that were successful had an indispensable person. The authors thought that it would be good to have more than one of these people on a project, but that these people were so rare that the real choice was between having one, and a successful project, and zero, and an unsuccessful project. Of course, these were LARGE projects, with hundreds or thousands of programmers and budgets in the hundreds of millions.

This is a great paper that I recommend for many reasons. But one of them is that it obliterates the myth of the need to get rid of the indispensable person. -- RalphJohnson

If found the paper at http://www.acm.org/pubs/articles/journals/cacm/1988-31-11/p1268-curtis/p1268-curtis.pdf. Pity this Aussie isn't a member. -- DanGreen

The paper proves nothing of the sort. If you study projects that were successful, how can you learn anything about projects that were unsuccessful because someone got hit by a truck? (That's all too real - I've seen it happen, truck and all.)

Anyway, there's a lot of sloppy definition above. The kind of indispensable person I was talking about was the type (actually several types) who ensures that he (almost always he, in my experience) is in a position to extort things from teammates and, yes, management. Usually, this person has been enabled by bad management to continue in this way and cement his position. If you have one of these, and that's not what Curtis was talking about, then you certainly need to get rid of his indispensability. Whether or not that means getting rid of the person is a matter of cases - some people can actually learn.

And, by the way, this type of indispensable person ALWAYS claims (vocally) to be smarter than anyone else on the team, and ALWAYS the ones who cannot learn to change and so depart are discovered - in their code - to be far less talented and smart than the other members of their team. Their "indispensable" pose, with its secretiveness, is the only thing that kept this fact from being revealed years earlier. It's an attitude we're talking about here, not a talent. -- GeraldWeinberg

As a software manager, I will certainly second Mr. Weinberg's assertion about "indispensable" programmers. These types tend to consume a lot of management time and the only thing worse than having one indispensable programmer is having two. It is certainly acceptable to have opinions on how things need to be done, but one also needs to realize that he will not get his way 100% of the time. -- WayneMack

It seems like there are two ways to be indispensable. Some programmers become indispensable without any intention on their part, because of their knowledge or skills. Others make themselves indispensable by being territorial and uncooperative. Some programmers may be indispensable for combinations of these reasons -- but judgments about one type of indispensability probably should not apply to the other type.

How about getting rid of indispensable managers? Will any manager agree with GetRidOfIndispensableManagerAsQuicklyAsPossible?? All of the reasons above (TruckNumber, information sharing, mentoring, attitudes) applies to management as well as to programming. In fact, they seems to apply to any group effort such as sales, support, etc. So should this approach generalized to GetRidOfIndispensableMemberAsQuicklyAsPossible??

Some employers interpret this advice pre-emptively and try to refuse to hire indispensable programmers in the first place. The people most likely to become indispensable are the highly talented programmers, who are rarely found, and therefore difficult to replace. These employers refuse to hire highly talented people, preferring instead to hire only mediocre programmers, who cannot become indispensable and are easily replaced.