

The Cost of Net Negative Producing Programmers - bdfh42
http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html

======
skmurphy
Gordon Bell, architect of the DEC VAX wrote "High Tech Ventures" and included
this section on NNP's

    
    
       Negative Productivity is a principle that I claim is worthy of a Nobel Prize. 
       Normal principles of productivity assume that workers create positive output. 
       Brooks refined the concept of software productivity to express it in terms of 
       the "mythical man month," and in software engineering, it is understood that 
       different programmers vary in their productivity by several orders of magnitude. 
       According to the principal of negative productivity, it is possible for an individual
       to produce bad results that others must then redo; hence, someone who is 
       very negatively productive can keep a whole team busy with damage control, 
       preventing the team from producing any output whatsoever.
    

For me this reduces to a set of four challenge for a software startup:

1\. Screen out folks with negative productivity in the interview process.

2\. Avoid screening out potential employees who have great strengths in
addition to some obvious weaknesses.

3\. Attract, hire, and retain enough strong players from the start to complete
your first product in a timely fashion.

4\. Fire anyone who made an initially strong impression but who is actually
negatively impacting the performance of the team (more broadly: identify and
eliminate sources of negative productivity).

This last category, the "plus minus" people, are only truly dangerous if you
don’t have the ability to detect them and acknowledge that you have made a
mistake.

------
pchristensen
This and the NASA piece both talk about how all software should always be
better, and the comments all have a resounding "here, here!" agreeing quality
to them. But no one mentions that there is a cost to higher quality software.
The system is the way is because people have made it work this way.

Software will continue to be bad as long as clients accept bad software.
Companies will continue to buy bad software as long as they don't know where
to find demonstrably better software.

~~~
yummyfajitas
Bad software is often better than none at all. Unfortunately, there are not
enough good programmers available to provide good software to all.

What's worse, a database that screws up 1% of the time, or an army of paper
pushers that costs thousands of times more and also has a 1% error rate which
can't be fixed (if necessary) by some overpaid consultant?

------
nsoonhui
His suggestions are not realistic. Sad as it sounds, the net negative
producing programmers are here to stay.
[http://itscommonsensestupid.blogspot.com/2009/01/why-net-
neg...](http://itscommonsensestupid.blogspot.com/2009/01/why-net-negative-
producing-programmers.html)

------
DanielBMarkham
"...But, truthfully, I'm not saying anything really new..."

Been better if he said that in the first sentence, instead of 2/3 down the
page.

I took the article to mean "I used to have all of these trivially constructed
boxes and simple ideas for how things work. Then I got wiser and now I have a
new set of trivally constructed boxes and simple ideas for how things work.
Only now I get to blog about them"

The market exists and rewards code that is sub-standard by our judgment.
Everybody's code but yours is crap -- you learn that the first time you manage
more than 2 people. Your own code is crap too -- you just don't realize it
until you look at it a year or two down the road. (If you don't realize it,
you've got ego problems)

So instead of simpleton boxes for programmers, how about dealing with each
person on an individual level. Nobody goes in to work each day thinking "Boy!
I hope I can screw things up royally today!" Or least most folks don't. Work
with people as a partner and mentor, don't label them, 'cause if you're
sitting around labeling people, you can bet they have some interesting labels
for you too.

