The Cost of Net Negative Producing Programmers(blog.jayfields.com)

blog.jayfields.com

The Cost of Net Negative Producing Programmers

http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html

4 comments

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.

pchristensen18 anni fa

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.

yummyfajitas18 anni fa

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?

loluyede18 anni fa

Don't think it's gonna change anytime soon. Contrary of other professions we don't really have a blueprint to create good software and estimate it. We can't even decide which is the better paradigm or software methodology to create something...

jodrellblank18 anni fa

Software will continue to be bad

Not bad. As Randy Pausch said in the lecture that was on the front page yesterday, "There's a reason we have the phrase 'good enough' - for things that are good enough".

Companies will continue to buy bad software as long as it's good enough. (That is - maybe they aren't even looking for demonstrably better software).

nsoonhui18 anni fa

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...

DanielBMarkham18 anni fa

"...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.