Agile 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.17.2014
| 29688 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 above 1.  Even if programmers do not average 50 lines of code per day, the following is clear 2

  • 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

Raging Infernoz replied on Thu, 2014/03/20 - 10:06pm

The hard part is not writing the code it is writing the right code; the typing you see is only the very final result of huge effort to get there, which can involve a getting a proper spec.(this can be surprisingly hard!), planning, thought, design, prototyping, testing, discussion with other people etc.  Basically code line count is a sheet metric which should be banned; it is only ever the working results which matter, including how maintainable they are!  This process can take much longer as a project ages, due to technical debt, functional dependency management, refactoring, shouty customer stress, and any number of other problems!  If I see any code from contractors or oursourcing I reliably turn the air blue, because the code quality and technical debt are often horrible, so very time consuming to fix, and can turn a manager's quick and dirty profitable project into a multiple times net loss!

David Sanderson replied on Thu, 2014/03/27 - 5:58am in response to: Raging Infernoz


Whilst I do agree with most of what you've said, I do think that the accountability of code quality is wider than just the developers. Whilst I have seen "bad" code before, I have also seen how that bad code has come to pass. Sometimes the burden of guilt should lie with project managers and Business sponsors - imposing ridiculous demands and expectations of delivery without understanding the nuances of whats really involved at a technical level.

I have many instances where a team have been asked to put together a project plan for a piece of work. Once that plan is completed and then comes under review, the business sponsers ask - "why will it take so long?" and seek to reach some sort of dilluted compromise in time delivery (usually because they have a deadline of their own to meet or some other agenda). So time for testing, and time for proper analysis/design get cut down, and low and behold the project is delivered, but the technical debt is massive. This then inhibits the extensibility of the code, and when they hear that refactoring is needed before work starts on the next phase of functionality, they cant understand why.

I have worked with very competent, well-intended developers/architects (both contract/outsoruced and permanent I might add), and I have seen the ideas planned with the best intentions go up in smoke because of the pressure from upper management to get a quick result for their satisfaction.

In that regard, I think the project manager is responsible for - getting together a competent team of developers(or should i say creating the right environment for the developers - correct quality processes/checks are put in place), taking time to understand fully the problem domain(listening to and understanding feedback from developers), preparing realisic plans, and provide enough push-back to the business/clients to prevent dilution of the quality feeding down to the developers themselves.

Dalip Mahal replied on Thu, 2014/03/27 - 10:12pm in response to: David Sanderson

David,

There is no doubt that programmer productivity is only one part of the equation for working software.  As you point out, proper business cases, proper project management, and proper quality control need to be present for a project to succeed. :-)

If you go back about 10-20 years, it was well known that the programming phase should be about 30% of the entire project.  However, with the rush to agile development, planning has gone out the window and there is a tremendous focus on writing code.

Just wanted to point out the fallacy that 'coding' is not the most important thing...


Vinay Kumar replied on Mon, 2014/04/28 - 12:48pm

I would say that productivity depends on your ground work and research efforts. If you have 8 hours to cut the tree , you should spend 6 hours in sharpening the saw. The amount of efforts that should go into researching a solution is very important.  Again productivity comes from what tools an technologies you use for eg I build a website in Java , hibernate , spring skill-guru. There was a lot of efforts involved in development, testing,  tomcat installation , memory issues etc. The idea was to test the business idea not the coding skills. Based on my learning , I build my next product in php and wordpress Study in USA The time taken to go live was around 2 months and we used so many out of the box functionality and plugins.

Dalip Mahal replied on Mon, 2014/04/28 - 5:15pm

There is no doubt that development cycles can be dramatically shortened with:

  • Proper requirements (correct, consistent, concise)
    • Only happens when the requirements are thought through BEFORE coding
    • Outsourcing problems are exponentially magnified with poor requirements
  • Heavy reuse of standard components
    • Use only production components, i.e. no beta components
  • Heavy communication between the requirements person and developers
    • Until all people are in sync it is pointless to start writing code
    • Once in sync, code gets written very fast :-)
Dalip

Comment viewing options

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