DevOps Zone is brought to you in partnership with:

Mr. Mahal has worked his way through all aspects of software development. He started as a software engineer and learned how to design and architect software systems in different industries. He has been a director of engineering, product management, and professional services; mid-career he worked for a company dedicated to training engineers in collecting requirements and understanding OO and conducted research into why software projects fail; and before starting Accelerated Development he rescued a technology startup in Vancouver as their COO. Accelerated Development is dedicated to the production of high quality software through implementing light weight engineering practices for all size organizations up to Fortune 500. Dalip is a DZone MVB and is not an employee of DZone and has posted 37 posts at DZone. You can read more from them at their website. View Full User Profile

The Programmer Productivity Paradox

03.12.2014
| 13932 views |
  • submit to reddit

 Programmers seem to be fairly productive people.

You always see them typing at their desks; they chafe for meetings to finish so that they can go back to their desks and code. When asked, they will say that there is not enough time to produce the code, and the sooner they can start coding, the sooner they will be done.

So writing code must be the most important thing, correct?

If the average programmer writes about 50 lines of production code a day.  A 50,000 line program would take 1,000 man days to produce.  The 50,000 line listing can be entered by a programmer at about 1,000 lines a day or about 50 man days.
So what the heck are the developers doing for the other 950 days?

Before addressing that issue, lets make a simple observation. Capers Jones has compared many methodologies (RUP, XP, Agile, Waterfall, etc) and programming languages over thousands of projects and determined that programmers write between 325 and 750 lines of code (LOC) per month, which is less than the 1,000 LOC per month suggested above1.  Even if programmers do not average 50 lines of code per day, the following is clear2.
  • Methodology does not explain the apparent productivity gap
  • No language accounts for the apparent productivity gap
The reality is that only a fraction of a developer's time is actually spent writing production code. If a developer is typing in code all the time then they are really trying different combinations of code until they finally find the combination of code that works.

Or more correctly, the combination that seems to match the requirements until either QA or the business analyst comes back and lets them know there is a problem.

That is why developers that plan their code before using the keyboard tend to outperform other developers. Not only do only a few developers really plan out their code before coding but also years of experience do not teach developers to learn to plan.  In fact studies over 40 years show that developer productivity does not change with years of experience. (see No Experience Required!)

Years of experience do not lead to higher productivity
Interestingly enough, there are methodologies that have been around for a long time that emphasize planning code.  Watts Humphrey is the created of the Personal Software Process (PSP)3.  Using PSP has been measured to:

PSP can raise productivity by 21.2% and quality by 31.2%
If you are interested there are many other proven methods of raising code quality that are not commonly used (see Not Planning is for Losers).

If your developers at their keyboard and not planning at a white board then odds are that your productivity is not as high as it could be.

Bibliography

1 The The Mythical Man Month is even more pessimistic suggesting that programmers produce 10 production lines of code per day
2 Jones, Capers and Bonsignour, Olivier.  The Economics of Software Quality.  Addison Wesley.  2011
3 Watts, Humphrey.  Introduction to the Personal Software Process, Addison Wesley Longman. 1997
Published at DZone with permission of Dalip Mahal, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabien Bergeret replied on Wed, 2014/03/12 - 7:09am

Unit Testing is also generally part of the developper's job.

For each line of production code, you can have one line of unit testing (or sometimes even more)...

Lund Wolfe replied on Sun, 2014/03/16 - 2:18am

I don't think code growth or lack of growth is considered to be a healthy metric.  The users (and often the developers) will tell you about functionality and quality.  If the functionality grows easily, the system is healthy.

Pumping out code is easy and getting easier all the time.  Software development that serves its purpose is hard.

Dave Rooney replied on Wed, 2014/03/19 - 11:11am

Seriously? It's 2014 and you still think programming is typing? How did that 50K line listing come into existence? Someone thought about the problem to be solved and created the code in the listing.

Programming requires thinking, and then eventually rendering those thoughts in the form of test and production code that the computer is able to understand. The typing part is by far the least important.

Thomas Fitzpatrick replied on Thu, 2014/03/20 - 10:58am

This article does not mention one crucial determinant of programmer productivity. Most developers work on legacy rather than greenfield projects. The cleanliness and maintainability of the code they inherit has a HUGE influence on their productivity. Anyone who has stayed up late refactoring someone else's mess, just so that you can understand the intention of the code will know exactly what I am talking about.

Management says "But Rockstar was our most productive developer. What's wrong with you guys??!!". Management does not know that "Rockstar" was creating mountains of technical debt that his co-workers had to wade through waist high, just to get the smallest bug-fix or feature change out of the door. 


Uueerd Doe replied on Fri, 2014/03/21 - 2:18pm in response to: Dave Rooney

I know; the article is ridiculous. Lines of code is possibly the absolute worst measure of code quality, and definitely not a good one for "productivity". A developer that is sloppy, uncaring, or just plain unfamiliar with the problem domain may write an order of magnitude more lines than a smart one that is familiar with the problem. He might even finish his solution first, but chances are it will run slower, take more resources, and/or be harder to maintain in the long run.

Will Mason replied on Sat, 2014/03/22 - 4:18am

Hi.

Well I'm voting for the key point:

  • "years of experience do not teach developers to learn to plan" (sic.)

Often the reverse can be seen to be true -- I have seen people with years of experience repeating and repeating the same few 'tricks' without considering the impact of design choices on scalability, maintenance or ... etc.  Why?  In general is it the pressure from people signing pay cheques to meet a deadline (so the fastest way forward can often be the one we already know...).

Counter example is some good programmers I've had on language courses.  Some people just apply some basic analytical techniques and look at what their code means in context to the users and the business.  It is a difference in approach I think, those who want to improve or know why approach thing differently.  

One thing only experience can deliver though is that business perspective, user/machine interactions.  Even the best theories need to be adapted to real-humans and real-cases.  Experience should help us develop flexibility and adaptability -- Don't you think :-)

Cheers,   Will

Dalip Mahal replied on Tue, 2014/04/15 - 4:48pm in response to: Will Mason

Will Mason,

"Years of experience" is definitely a touchy subject :-)

The reality is that in the aggregate there is no correlation between years of experience and productivity (or quality).  However, that does not mean that there are not hard working individuals who have used years of experience to become much, much better than when they started.

It just means that for every developer where years of experience has made them better, there are many developers (i.e. > 50) who have not taken advantage of training over the years. These are the guys that you are talking about, and they greatly outnumber the diligent developers.

Regards,

Dalip Mahal

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.