Net Negative Producing Programmer

A management and staffing AntiPattern.

Originally described by G. Gordon Schulmeyer, it can be resumed, in his own words, as:

"There are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one."

For a complete description, read http://web.archive.org/web/20011023084845/http://pyxisinc.com/pyxis_artmain.html

-- GeraldoXexeo

I realise that I am young, naive and optimistic, but I haven't come across an NNPP whose lack of usefulness has been their fault. Either they were being managed in a way that made them less productive, or they were being set tasks that were inappropriate to their skill set, or outlook at the time. Seeing as software projects have such a huge variety of tasks and needs, it should generally be possible to re-direct a person so they are productive for the team. -- SvenDowideit

Realizing that people in your team are net negative producing will hopefully get these people the education and training they need faster. The usual way of dealing with it is unfortunately just to leave them struggling, in the hope that they won't be in the way.

This should also motivate us to pair program more with the inexperienced. It's not as fun as pairing with someone experienced, but it's far better than having someone negating the value you're adding.

I do not think lack of experience qualifies one as an NNPP, so training is rarely the solution. Even though they won't help much, smart, eager neophytes will not drag down a team, assuming they don't make up the majority. I can think of only three types of people that qualify as NNPPs: (1) those with personality problems; (2) those without aptitude for programming; (3) those whose past experience, no matter how voluminous, is an impediment to their working well on this team (see AntiExperience).

It is easier to program on a project than to manage a project. This can be a hint that an NNPP is more likely to be because there is a management problem than a programming problem.

But don't overlook the (unfortunately not hypothetical) situation where the time required to train/guide/instruct/correct/review a borderline programmer (see UnconsciousIncompetence), requires more time from the manager/lead-programmer than it would take for said managing-programmer to simply write the code himself. Taken in isolation the NNPP is producing work. From the project's point of view, however, he is a resource drain.

In 25 years of working, I have only come upon one truly irremediable negative producer, as opposed to people who were so miserable at a job (including me) that it was an act of mercy to fire them. -- AnonymousCoward

I actually agree that a large company can try to train or educate a NNPP expecting them to become a NPPP. However, small companies or small teams can't afford them. -- GeraldoXexeo

Where I'm at now we've had 2 people (out of 7) who've had everything they wrote added to the "needs to be rewritten" list after they departed. There's another one still with us, cranking away. (For political reasons you won't see all your code trashed until you leave.) He's been programming longer than anybody else, so it's definitely not lack of experience. This trend of people producing bad code probably indicates a lack of management/LeaderShip...

It seems like people on this page are thinking of the NNPP's as inexperienced programmers. The one I currently work with is the most experienced on the team (in years) and considers himself to be a very skilled programmer. His problem is that he refused to DoTheSimplestThingThatCouldPossiblyWork. Instead, he insists on DoTheMostComplicatedThingThatCouldPossiblyWork. Unfortunately, the things he writes never do work. We were eventually able to get him out of our hair by promoting him.

In my only experience of a NNPP, the root cause was not inexperience or even extreme technical incompetence, but extreme social incompetence, coupled with limited technical competence. The NNPP had such an impact on harmony and co-operation within the group that total output was reduced.

I have known developers like this. I think it's mainly a problem of *arrogance*. If you're willing to learn from others, you can change from someone who uses only one-letter variable names, writes 200-line methods, and doesn't use UnitTests into a good programmer. But if you think you are a genius (a strangely common belief) and should be worshipped, you will never learn to write clear, simple, maintainable code.

I have seen just the opposite cases. They know their code is bad, messy, and difficult to maintain, but they don't believe they can do any better, so they give up trying to be better. Writing and fixing messy code late into the night becomes the norm. I usually find these kind NNPP in large companies with 100s/1000s of employees.

Sooooo... there are NNPPs on almost every project. If you look around your team, and can't seem to find the NNPP, perhaps you should consider stepping aside! :)

Perhaps this is a special case of the NNPP.

A NNPP has the following qualities:

Produces solutions in record time
Produces solutions that work only on the happy path, otherwise they fail
Writes code with no consideration of future maintenance

The NNPP is an anti-pattern, because it appears to those not working with his source code that the NNPP is fixing bugs, and generally getting things done. Unfortunately, the only one able to understand let alone read the NNPP's code is the NNPP himself. The more code produced by the NNPP, the harder it is for other team members to maintain or modify the application.

We had a NNPP on our team that caused so much damage in three weeks (before firing him) that it took us months to fix. We call it "Ben" code. He refactored the working code to his old coding style including renaming variables and methods, rewrote fundamental library classes like globalization, added the most convoluted comparison code you can imagine instead of using built in comparison functions, and added his own "Datalayer" that decorated many classes with "IReadsData" instead of using built-in data access methods. I still can't believe how much time it took to undo his damage.

I hear you, and unfortunately I wish that I could say that yours was an isolated case, but it is becoming an all to familiar nightmare for everyone. It is now necessary to "closely" monitor all employees, especially new ones. Occasionally, the damage can never be repaired...