davidbgk
/
larlet-fr-david-cache

title: The Net Negative Producing Programer
url: http://www.software-thoughts.com/2009/08/net-negative-producing-programer.html
hash_url: eb1b9ce654fcbfc8ff4bb88df862fa72

It has been well known for a long time that there is at least an <a href="http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx" id="gq.:" title="10x Software Engineering (Steve McConnell)">order of magnitude difference</a> between the most productive developers and the least productive.  But if you've been in the software industry for any period of time, you've probably met this person: the <a href="http://www.pyxisinc.com/NNPP_Article.pdf" id="wi90" title="The Net Negative Producing Programmer (G. Gorden Schulmeyer) (PDF)">net negative producing programmer</a> (NNPP).   This is the person that is so bad, that they actually have a negative effect on team productivity: <i>you would be better off not having this person on your team.</i><br />
<br />
<br />
The NNPP drains a software development team and the business in a variety of ways:<br />
<ol><li>Initial hiring and training costs</li>
<li>Ongoing mentoring from your top developers</li>
<li>Unacceptably high defect rates</li>
<li>Very low output, if any<br />
</li>
<li>Lowers team morale (they make roughly the same amount of money as <i>you</i>)</li>
<li>Causes the business to delay or miss deadlines</li>
<li>Taking up a position that could be filled by a great programmer<br />
</li>
</ol><br />
So how do you identify and avoid the NNPP and what do you do if you are stuck with one?<br />
<br />
<h3><b>Identification</b></h3><br />
The first step in ridding your team of the NNPP is identification.  You may have an intuitive sense of who is the lowest performing member of you team, but this doesn't necessarily make them a NNPP.  The NNPP will exhibit a number of the following red flags over a significant period of time:<br />
<ul><li>Takes a long time to get the development environment running<br />
</li>
<li>Codes by copy and paste<br />
</li>
<li>Reinvents the wheel<br />
</li>
<li>Doesn't check in much code<br />
</li>
<li>Takes a long time between check-ins<br />
</li>
<li>Keeps saying the code is almost done</li>
<li>Tasks always take significantly longer than estimated<br />
</li>
<li>Has a high defect rate and/or significant defects</li>
<li>Doesn't perform basic desk checking<br />
</li>
<li>Avoids responsibility / passes the buck<br />
</li>
<li>Doesn't use/understand naming conventions<br />
</li>
<li>Asks questions that lack depth</li>
<li>Asks too many questions (unable to do things by themselves)<br />
</li>
<li>Doesn't ask enough questions (works in a silo)</li>
<li>Doesn't integrate with the team</li>
<li>Lacks passion for software development<br />
</li>
<li><a href="http://www.codinghorror.com/blog/archives/001188.html" id="v0.-" title="We Are Typists First, Programmers Second (Coding Horror)">Types slowly</a></li>
</ul><br />
New hires, junior developers may exhibit more of these and any programmer might exhibit some of these from time-to-time.  For these<br />
developers, they deserve time, mentoring and training to get them on<br />
the right track.  But if you have a senior software engineer consistently displaying<br />
a lot of these characteristics, you have at least an over-paid, under-performing developer and likely an NNPP.<br />
<br />
You can catch these red-flags through with a variety of techniques:
<ul><li>Performing Design Reviews</li>
<li>Performing Code reviews<br />
</li>
<li>Pair Programming</li>
<li>Measuring defect rate</li>
<li>Measuring estimates vs actual time<br />
</li>
<li>Counting defects fixed</li>
<li>Counting source control commits</li>
<li>Reviewing daily source control logs</li>
</ul><br />
For instance, here are the source control commits and defects fixed for an actual 6 person development team over about an 8 month period.   Each developer has at least 10 years of experience and all have the titles of at least "Senior Software Engineer".<br />
<br />
<img src="http://docs.google.com/File?id=ddbsfzbp_25c3cbcjd9_b"/><br />
This shows we have a big performance gap between our top and bottom<br />
developers, but these two data points don't tell the whole story: programmer B is a new hire and what separates programmers A, the NNPP, and C are the other red-flags listed above: missed estimates, high defect rates, naming conventions and re-inventing the wheel.<br />
<h3><br />
</h3><h3><b>Remediation<br />
</b></h3><br />
Once you have identified a NNPP, your goal should be to get as far away from them as possible.  For better or worse, the team's productivity and ability to meet deadlines and produce value for the business reflects on <i>you</i>. You should want to be part of a small, highly productive team that builds great software.  You can't do that with one or more NNPPs on your team.  You can:<br />
<ul><li>Fire them immediately</li>
<li>Give them a 30 day warning, then fire them<br />
</li>
<li>Find them a new role</li>
<li>Change jobs</li>
</ul><h4>Fire Immediately</h4>If you are able and if your organization culture supports it, this is the best solution.  Your team gets an immediate productivity boost and you get the opportunity to bring in a replacement that can be a net positive instead of a net negative.  This is probably not possible in many large organizations or European countries, but for at will employment consider this your first option.   If you are unable, or can't bear to fire them, you'll have to look at other options.<br />
<h4>30 Day Warning</h4>Similar to immediate termination, the 30 day warning gives the NNPP time to get their act in gear.  If you've mis-read the situation or there are external factors that you haven't considered, this gives the NNPP a chance to prove you wrong.  This also gives the NNPP a chance to start looking for another job which may solve the problem without having to resort to termination, don't count on it.<br />
<h4>Find them a new role</h4>Not everybody is cut out to be a programmer.  Maybe the NNPP would be better off with a different role.  You've already invested in hiring and training them, so they should at least be knowledgeable about your products, practices and culture.  Maybe they would be a great QA engineer, a customer advocate, a sales engineer.  Look around at the open positions in your company and see if there is something that might be a better fit.  A tool such as <a href="http://www.strengthsfinder.com/" id="j6.z" title="www.strengthsfinder.com">StrengthsFinder</a> might help them discover what they would be really good at instead of continuing to struggle with software.<br />
<h4>Change jobs</h4>If nothing else will work, you can always change jobs, internally or externally to get away from the NNPP and move to a place where you can be part of a highly productive team.  There are no guarantees that you won't be in the same situation or worse at your next position, but you should have an idea of what questions to ask to find a good team.<br />
<h3><br />
</h3><h3><b>Avoidance</b></h3><br />
Of course, the best course of action is to avoid the NNPP in the first place.<br />
<br />
If you are building a team, you want to hire <a href="http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html" id="v5uy" title="Joel Spolsky - The Guerrilla Guide to Interviewing">smart people who get things done</a>.   This article isn't about interviewing, but you must identify if they can:<br />
<ul><li>Write a program</li>
<li>Understand code</li>
<li>Debug</li>
<li>Fix defects<br />
</li>
<li>Desk check their code</li>
<li>Learn new languages and skills easily</li>
</ul><br />
You can require code submissions and problem solving as part of the interview process, hire people you know, subject new hires to a 30 day trial period or use a variety of other interview techniques.<br />
<br />
If you are coming into a new job, you probably won't know if there is an NNPP on the team already.  Chances are, you won't interview with them, but you can do <a href="http://www.codecrankers.com/2009/06/top-interview-red-flags-for-programmers/" id="ffu2" title="Code Crankers - Top Interview Red Flags for Programmers">normal vetting</a> and you always have the option to change jobs later or work from within to improve the team.<br />
<h3><br />
</h3><h3>Conclusion</h3><br />
The Net Negative Producing Programmer is bad for you and bad for the business.  While not everybody is a top performing programmer, we shouldn't stand for the NNPP taking away from what we can accomplish.  Do your best to avoid the NNPP as new hires and be on the looking for them on existing teams.<br />
<br />
<h3>References</h3><ul><li><a href="http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx" id="fs43" title="Productivity Variations Among Software Developers and Teams: The Origin of &quot;10x&quot;">Productivity Variations Among Software Developers and Teams: The Origin of "10x"</a>, Steve McConnell</li>
<li><a href="http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx" id="e2wr" title="10 Developers For The Price Of One">10 Developers For The Price Of One</a>, Phil Haack</li>
<li><a href="http://itscommonsensestupid.blogspot.com/2008/05/why-good-developers-are-not-getting-10.html" id="t05:" title="Why Good Developers Are Not Getting 10 times the Pay?">Why Good Developers Are Not Getting 10 times the Pay?</a>, Soon Hui</li>
<li><a href="http://www.pyxisinc.com/NNPP_Article.pdf" id="bx_v" title="PDF">The Net Negative Producing Programmer</a>, G. Gorden Schulmeyer</li>
<li><a href="http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html" id="nc03" title="Programming's Dirtiest Little Secret">Programming's Dirtiest Little Secret</a>, Steve Yegge</li>
<li><a href="http://www.codinghorror.com/blog/archives/001188.html" id="s7k4" title="We Are Typists First, Programmers Second">We Are Typists First, Programmers Second</a>, Jeff Atwood<br />
</li>
<li><a href="http://blog.kriskemper.com/2008/08/07/preventing-the-net-negative-producing-programmer/" id="j.:l" title="Preventing the Net Negative Producing Programmer">Preventing the Net Negative Producing Programmer</a>, Kris Kemper</li>
<li><a href="http://blog.jayfields.com/2008/08/elitist-or-optimist.html" id="lp3h" title="Elitist or Optimist">Elitist or Optimist</a>, Jay Fields</li>
<li><a href="http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html" id="koio" title="The Guerrilla Guide to Interviewing (version 3.0)">The Guerrilla Guide to Interviewing (version 3.0)</a>, Joel Spolsky</li>
<li><a href="http://www.codecrankers.com/2009/06/top-interview-red-flags-for-programmers/" id="ch:5" title="Top Interview Red Flags for Programmers">Top Interview Red Flags for Programmers</a>, Code Crankers<br />
</li>
</ul>