[Off-Topic] Net Negative Producing Programmer

During the Encontro de TI conference last Saturday, I had the chance to exchange 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. After him, other bloggers explored the subject further, like Kris Kemper. There’s also a paper by G. Gordon Schulmeyer exploring it in even more detail. Either way, the executive summary is this:

“Removing a technically bad element from a team can be more productive than adding a better-qualified one.”

In other words, you discover you have a bad programmer: fire them, as fast as possible! There’s no other solution. Many managers assume that bad or mediocre programmers, at worst, are just slower than good programmers. But that’s an absurdly wrong assumption: a single bad programmer causes irreparable damage to a project — they don’t just move slowly, they literally put the team in reverse. The result 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). In other words, maintainability and extensibility are deeply compromised.

One thing is fact: it’s very hard to identify a bad programmer, especially if you, the manager, aren’t a programmer yourself. Worse: you need to be a good programmer to identify the bad one. In a reasonably balanced team, with programmers at least slightly above average and only one or two bad elements, it becomes easier to separate the wheat from the chaff — the team itself will start expelling the rotten apple from its midst (if they’re smart). That’s a double-edged sword, because now if you, as a programmer, think your colleague is the bad one, who guarantees the others don’t think you’re the bad one? If you’re a programmer, you’d better make sure your work speaks for itself. I tend to separate “coders” from “developers.” Both are programmers, but the first group are the types who clock in at entry, do only what they’re told, go home at the same time every day, and don’t worry about anything else. The second group are the true artists, those who understand that software is art and, as such, demands dedication and constant study — commercial hours simply don’t apply. As I like to illustrate: 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 — you’ll have better chances of finding the best programmers 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 mentioned on his blog about how ThoughtWorks hires: the candidate goes through a battery of tests. Not just one or two interviews — they need to pass through several senior engineers, they need to show code that will be reviewed by other seniors. In other words, they have to truly earn their place. They need to demonstrate experience (following Malcolm Gladwell in Outliers, I’d say you should only hire programmers approaching 10,000 hours of experience, except for roles with less important tasks), they need to show agility and excellent communication skills, they need to show code — good code, code they wouldn’t be embarrassed to show Martin Fowler. (note 2012: that model isn’t bad, but today I think there’s a better way, which I’ll cover in another post.)

Now, I’ve seen very bad situations where an entire team consists of nothing but 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 wasteful to throw all that away.” No. What’s wasteful is keeping them while they generate more and more technical debt that you’ll eventually have to pay. 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 vs. long-term results. This is a constant in every company I’ve been through: managers love the cowboy programmer, the guy who solves every problem thrown at him. All cowboys are devotees of what we call “Duct Tape Oriented Programming” — hacking things together. It would be funny if it weren’t tragic: not only does this exist, it’s practically the norm in most software teams. I’d risk saying that at least 4 out of every 5 programmers do this daily.

So, if you’re a Manager, be suspicious of magical results, unexpected software behaviors, constant errors that get fixed instantly. You know that pattern? Today a problem blows up, you send an email to the team, they respond an hour later saying “everything’s fine now.” And this repeats every day. That’s a very strong signal of duct-tape programming. Cowboy programmers are “coders” who think they’re “developers” — a deranged house painter who thinks they’re Van Gogh. This is the most dangerous type because the house painter knows their limitations and will never claim to be a painter of pictures, but the cowboy doesn’t — they genuinely believe they’re Van Gogh! And the worst part, paradoxically, is that managers love them because they solve all the problems!

Here comes the shocking part: managers love cowboys because they solve all the problems that they themselves created! In other words, the realization hasn’t hit yet that all the merit attributed to the cowboy is generated by the very problems he created! If you’re this type of manager and you now understand you have cowboys, fire them too. There’s even that 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 fire him: he is, literally, a massive Single Point of Failure (SPOF). Real developers don’t hide things, don’t mask results, don’t slow down the process. Want a symptom? Do you have any software whose source code lives only on your programmer’s machine? Watch out: you just found a cowboy.

Another motivator: when you replace a bad programmer with a truly good one, you’re not swapping six for half a dozen — you’re effectively trading 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 (not just faster, but a programmer who writes quality code, making it easy to maintain, extend, and pass knowledge on to other programmers).

And these days, there are several symptoms that expose cowboys who should be fired: does your programmer wrinkle their nose when Pair Programming is mentioned? Do they scoff at Collective Code Ownership and prefer to keep some code hidden? Do they think testing is optional and something that can be done later? Worse, do they defend the use of practices or technologies without being able to explain, technically, why they’re using them? All of those are symptoms. If your programmer has even one of them, that’s more than enough reason to have the dismissal paperwork ready and to start interviewing new candidates.

By the way, I might seem like I’m joking when I say “fire them,” but I’m being serious. Another thing that’s very important for a company is staff turnover. When the same people stay together for very long periods (years), they get used to each other and start turning a blind eye more frequently, drastically dropping service quality. A goal that should be adopted annually is to renew around 10% to 20% of staff every year! Keep the true developers, but fire the NNPPs — unless, of course, you have money to throw away.

Update 03/30: I forgot to mention a few more things. Responding to some comments as well. As I already mentioned in my Killing the Average talk, the market as a whole benchmarks everyone against the bottom. So a good programmer, even being up to 10x better than a bad one, never earns 10x 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 underperforming employees, that gets really difficult. So the pragmatic approach would be: fire whenever you can and, more importantly, hire with extreme care. It’s always better to take longer and hire someone truly good than to assume someone might have “potential” just based on credentials.

One important thing: I’m not talking against newcomers, juniors, and recent graduates — don’t confuse this. There are many youngsters 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 either 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 fast, even encouraging duct-tape solutions.” Alright, here’s the thing: in aviation there’s something called Catch-22. Decades ago, many planes crashed because the pilot was making wrong decisions and the co-pilot, even knowing this, had to stay silent due to hierarchy (someone of lower rank must not contradict someone of higher rank). Knowing this, the aviation world evolved and now there’s a procedure called PACE (Probing, Alerting, Challenging, and Emergency Warning). That is, if the co-pilot knows the pilot is wrong, there’s a procedure for them to assess the situation, alert the pilot, if they don’t understand, challenge them, and if they still don’t understand, the co-pilot must notify the control tower and take control of the aircraft. This drastically reduced aviation accidents. 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, then that company isn’t good for you. I’m not talking about the childish act of going over the boss’s head and gossiping to the boss’s boss, but about confronting them face-to-face and discussing the problem realistically. Here’s a passage from the PACE document:

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 exploring the concept of “Cowboy” a bit more since it seems it can be misunderstood. Again, a Cowboy is not the newcomer gaining experience, or even the senior learning new things. Those are the people you should invest in. The problem is the Lemmings — the suicidal ones, those who are bad, everyone knows they’re bad, everyone warns them they’re heading toward a cliff, but the damn fool has it in their head that they either can’t change, or won’t change, or don’t know how to change — and therefore won’t. That’s the person who keeps heading off the cliff and drags everyone around them along. That’s exactly the NNPP: someone with negative productivity, causing damage. That type — after being warned once, twice — you can’t keep them, they have to go, because at that point it’s either them or you.