[Off-Topic] Net Negative Producing Programmer

During the Encontro de TI event last Saturday, I had the chance to trade ideas with Guilherme Chapiewski. We landed on the subject of the Net Negative Producing Programmer (NNPP). I first read about this term in Jay Fields’ article. Other bloggers explored the subject too, like Kris Kemper. There’s also a paper by G. Gordon Schulmeyer that digs even deeper.

The executive summary, in Schulmeyer’s own words, is this:

“Taking a poor performer off the team can often be more productive than adding a good one.”

Found out you have a bad programmer? Fire him, as fast as possible. There’s no other solution. Many managers assume that bad or mediocre programmers are, at worst, just slower than the good ones. That assumption is absurdly wrong: a single bad programmer causes irreparable damage to a project and literally puts the team in reverse.

The damage isn’t always obvious. Most of them are accumulators of Technical Debt (note 2012: this post talks more about technical software problems, but generalize to problems in general, like low team morale, dissatisfied clients, etc). Maintainability and extensibility end up deeply compromised.

One thing is certain: spotting a bad programmer is very hard, especially if you, the manager, aren’t a programmer yourself. Worse: you need to be a good programmer to recognize the bad one. In a reasonably balanced team, with programmers at least slightly above average and only one or two bad elements, the team itself separates the wheat from the chaff and expels the rotten apple from its midst (if they’re smart).

That’s a double-edged sword. If you, as a programmer, think your colleague is the bad one, who guarantees the others don’t think the bad one is you? If you’re a programmer, make sure your work speaks for itself.

I tend to separate “coders” from “developers.” Both are programmers, but the first group clocks in at the door, does only what they’re told, goes home at the same time every day, and worries about nothing else. The second group is made of true artists, people who understand that software is art and, as such, demands dedication and constant study, with no regard for business hours. As I like to put it: it’s the difference between a house painter and Da Vinci.

A manager needs to be very conscious of this: every software development team needs Senior Technical Leaders. Tip: look in Open Source communities, your odds of finding the best programmers are better there. Don’t look in educational institutions and, above all, be suspicious of any programmer who leads with the certifications they have.

I liked what Kris Kemper wrote on his blog about how ThoughtWorks hires: the candidate goes through a battery of tests. One or two interviews won’t cut it: they need to get past several senior engineers and show code that other seniors will review. They have to truly earn the seat. They need to demonstrate experience (following Malcolm Gladwell in Outliers, I’d say you should only hire programmers approaching their 10,000 hours of experience, at least for roles with less important tasks), they need to show resourcefulness and excellent communication skills, they need to show code, and good code, code that wouldn’t embarrass them in front of Martin Fowler. (note 2012: that model isn’t bad, but today I think there’s a better way, which is a topic for another post.)

Now, I’ve seen very bad situations where an entire team is made of NNPPs. In those cases there’s nothing to do: dissolve the entire team. Be very careful not to fall for the Sunk Cost fallacy. Many think like this: “but I’ve already invested so much time and resources in this team, it would be a waste to throw all that away.” No. What’s wasteful is keeping them around while they create more and more technical debt that you’ll be the one paying for. It’s cheaper to dissolve the team, form a new and better one, and restart the project from scratch if necessary. You’ll stop for 6 months, but at least you won’t go bankrupt in 2 years.

Another thing every manager always gets wrong: immediate results versus long-term results. This is a constant in every company I’ve been through: the manager loves the cowboy programmer, the guy who solves every problem thrown at him. All cowboys are devotees of what we call POG in Brazil, “Workaround-Oriented Programming” (in Portuguese). It would be funny if it weren’t tragic: it exists, and it’s practically the norm in most software teams. I’d risk saying that at least 4 out of every 5 programmers do POG daily.

So if you’re a manager, be suspicious of magical results, unexpected software behavior, constant bugs fixed instantly. You know the pattern? A problem blows up today, you send an email to the team, they reply an hour later saying “everything’s fine now.” And this repeats every single day. That’s a very strong POG signal. Cowboy programmers are “coders” who think they’re “developers”: an insane house painter who thinks he’s Van Gogh. It’s the most dangerous type, because the house painter knows his limitations and would never claim to paint portraits, but the cowboy genuinely believes he’s Van Gogh. And the worst part, paradoxically, is that managers love them because they solve all the problems.

Now for the shocking part: managers love cowboys because they solve all the problems they created themselves. The penny hasn’t dropped yet: all the merit credited to the cowboy is generated by the problems he created. If you’re this type of manager and it just clicked that you have cowboys, fire them too. There’s even the classic dilemma: “but I can’t let him go, he’s the only one who knows how the system works!” Exactly. That’s an even stronger reason to let him go: he is, literally, a massive Single Point of Failure (SPOF). Real developers don’t hide things, don’t mask results, don’t stall the process. Want a symptom? Is there any software whose source code lives only on your programmer’s machine? Watch out: you just found a cowboy.

One more motivator: when you swap a bad programmer for a truly good one, the effective gain is 1 for 10, as the good old Frederick Brooks put it in The Mythical Man Month. For 30 years we’ve known that a good programmer can be 10 times better. On top of being faster, he writes quality code, which makes maintenance, extension, and knowledge transfer to other programmers easy.

And these days there are several symptoms that expose cowboys who should be fired. Does your programmer wrinkle his nose when Pair Programming comes up? Does he scoff at Collective Code Ownership and prefer to keep some code hidden? Does he think testing is optional, something to do later? Worse, does he defend the use of practices or technologies without being able to explain, technically, why he’s using them? All of those are symptoms. Even one of them is reason enough to have the dismissal paperwork ready and start interviewing new candidates.

By the way, I might sound like I’m joking when I say “fire them,” but I’m dead serious. Another thing that’s very important for a company is staff turnover. When the same people stay together for years, they get too comfortable with each other and start turning a blind eye more often, drastically dropping service quality. One goal worth adopting: renew 10% to 20% of the staff every year. Keep the true developers and fire the NNPPs, unless, of course, you have money to burn.

Update 03/30: I forgot to mention a few more things, responding to some of the comments as well. As I already said in my Killing the Average talk, the market as a whole benchmarks everyone from the bottom. So a good programmer, even being up to 10 times better than a bad one, never earns 10 times more. Sometimes the difference barely reaches 10%, which is truly sad. Of course when I say “fire them,” I mean it, but it’s also a provocation. Given Brazilian laws that protect the underperforming professional, in practice it gets difficult. So the pragmatic approach is: fire whenever you can and, more importantly, hire with great care. It’s always better to take longer and hire someone truly good than to assume someone might have “potential” based on credentials alone.

One important thing: don’t read this as an attack on newcomers, juniors, and recent graduates. There are many young folks with lots of potential, especially those who know they’re early in their career and want to learn, make an effort to learn, change course when they receive feedback, and know at least how to start arguing their positions. A cowboy can be a recent graduate or someone with 20 years of career, it doesn’t matter. Good juniors should be well taken care of and given adequate coaching so they don’t go down the cowboy path.

One more thing: “I want to be a good programmer, but my boss pressures me to deliver everything early, he even encourages POG.” Alright, here we go. In aviation there’s the so-called co-pilot’s Catch-22. A few decades ago many planes crashed because the captain made wrong decisions and the co-pilot, even knowing this, stayed silent because of hierarchy: someone of lower rank must not contradict someone of higher rank. The aviation world evolved and now there’s a procedure called PACE (Probing, Alerting, Challenging, and Emergency Warning). If the co-pilot knows the captain is wrong, there’s a procedure for him to assess the situation, alert the captain, challenge him if he doesn’t understand and, if the error persists, the co-pilot must notify the control tower and take control of the aircraft. That culture shift in the cockpit helped bring aviation accidents down drastically.

A good programmer must say no to a boss who is pushing the team off a cliff. If the company punishes that kind of initiative, that company isn’t good for you. Skip the childish move of going around your boss to gossip with his boss: face the man and discuss the problem like an adult. Here’s a passage from the PACE paper:

For the actual announcement of change of command on the flight deck, the Co-pilot could use a phrase such as “Captain (Jones), I must take over control of the airplane. (Jerry), take your hands off the controls. NOW!” This use of a personal first name or a nickname can very effective to break the perceptual narrowing of the Captain. A third crew member, if present, can use terminology such as, “Captain (Jones), you must give control of the airplane to (Barry) immediately.”

Update: 03/31 I think it’s worth digging a bit more into the “Cowboy” concept, since it can be misread. Again: the newcomer gaining experience and the senior learning new things are not cowboys. Those are the ones worth investing in. The problem is the Lemmings, the suicidal ones: the guy is bad, everyone knows he’s bad, everyone warns him he’s heading toward a cliff, but the damn fool has it in his head that he can’t change, won’t change, or doesn’t know how to change, and therefore he won’t. That’s the guy who keeps going off the cliff and drags everyone around him along. That’s exactly the NNPP: negative productivity, guaranteed damage. After being warned once, twice, there’s no point anymore: he has to go, because at that point it’s him or you.