Contact Us

Maximising Development Productivity

This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed at davechaplin@byte-vision.com.

Date: Monday, December 16, 2002


Productivity is one of those wonderful management buzzwords that everyone wants lots of but few actual qualify, quantify or even measure. This article introduces the concept of a ‘Chaplin Productivity Graph’ as a tool for discussing productivity and explains how it can be improved.

What Is Productivity?

In software terms I am going to define productivity as follows:
“Productivity is the rate at which we can develop high quality software that meets the requirements of the customers”. High quality refers to fit for purpose, as opposed to the utopian Zero Defect.

Ensuring you meet the customers’ requirements and deliver something of value is a whole topic itself which I’ve addressed in a previous article Mitigating Requirements Risk With Agile Processes. This article will focus on increasing development productivity with an underlying assumption that the right thing is being built in the first place.

Based on that assumption, if we wanted to measure productivity we would need to measure the time it takes from the start of design through to build, testing, deployment, and any further bug fix releases until the software was considered fit for purpose.

This article will focus on productivity increases in development. The productivity gains associated with the build and deployment process warrants another article.

First of all lets define a simple measure for Productivity.

Measuring Productivity With System Test Cases

We can measure productivity using system tests. Productivity is the rate at which you add further system tests (that pass) to the existing system. For example, you might have a new User Story (requirement) called Transfer Cash. You then define some screen flows and determine that there are 15 system test cases that need to pass to prove that the User Story has been implemented.

The average number of test cases passed each day is the productivity rate. In Extreme Programming this is called Velocity.

The maximum productivity rate (maximum velocity) for individual developers will vary considerably. In the Mythical Man Month Brooks says that different developers can vary as much as ten fold in terms of productivity rates.

The Maximum Productivity Rate

The maximum productivity rate is the best velocity that a developer can achieve. For example, Mr Super Developer when left alone in a quiet room with no meetings and disruptions can build a system which passes 10 additional system test cases each day. I mention no distractions for the developer. I’m actually referring them to being in a state of flow throughout. Eh…What is flow?.....


Being in flow is when you are fully immersed in a task. You are so focused on it that you are almost in a trance like state. Hours can go by without you noticing. Work gets done very fast. When you are in flow you are at running at your highest velocity. It takes approximately 20 minutes to get into flow. However, if you get disturbed and knocked out of flow, it will take another 20 minutes immersion time before you are back in full flow. It is important to stay immersed in flow for long periods at a time to get anything considerable done.

The ‘Chaplin Productivity Graph’

A ‘Chaplin Productivity Graph’ (CPG) has productivity rate on the vertical axis and time on the horizontal axis. It also has a horizontal maximum productivity rate bar indicating the best productivity rate that can be achieved. The area under the graph indicates the amount of actual valuable work competed. For example:

In this graph we can see the developer starts work at 9am and takes 20 minutes immersion time before they are in full flow. They then work until 12 noon when lunch is taken for an hour. After lunch it takes another 20 minutes to get into flow and then they remain at full flow for the rest of the day when they then go home. The developer is running on full flow for most of the day and thus gets a lot of work done. The area under the graph is at an optimum.

I’ll use the concept of a CPG throughout this article.

Now lets take a look at some of the various factors and the effect they have on the CPG.

Effect of Personal Distractions (Environmental Factor)

The CPG below details the day for a developer who is constantly interrupted and thus only achieves a small amount of the day in flow.

This developer is constantly being interrupted. They try to get into flow but something stops them getting there. This is often the case for a developer who responds immediately to the email pop up window. Many large organisations seem to like to send out untargeted spam email to their employees every 10 minutes. You know the type. Further, you get developers who sit on their email. As soon as something comes in the inbox they hear the beep and drop everything to read the message. Another common distraction is the phone whether it be the work one, or the mobile with text messaging. As soon as that phone rings they stop everything, deal with the call, and then attempt to start off where they left off. The problem is they’ve wasted their flow and it will take 20 minutes to immerse again. The advice I would give here is to turn off email and switch the phone to answer phone. If someone needs you that urgently they will find you. Deal with your emails at the start of the day, at lunchtime, and then at the end of the day. The same with phone calls. Then watch your productivity rapidly rise.

Other common distractions in the office are other people who want to spend the day talking about last nights television or football match. They seem to want to disturb you when it suits them, not you. It would be worth politely pointing out to them that you are working and that you will talk to them at lunchtime. Alternatively, go and grab a coffee with them and have the discussion away from other people so you don’t disturb them.

Noisy Environments (Environmental Factor)

A noisy environment is not good for the developer. In a noisy environment a developer can no longer get into full flow. The concentration is being constantly disturbed. In effect the maximum productivity rate line falls. The developer is running with half the oxygen. The CPG now looks like this.

Creating a working environment with no noise is often problematic for developers. Managers just don’t understand the problem. This is because managers spend more time communicating with others and don’t need to immerse themselves in a state of flow. It is a different job. A solution to this problem is to work from home provided it is quiet there. If that is not possible then the next best thing is to put headphones on to drown out the noise. The drawback with putting headphones on is that it breaks down communication between developers within a team. For example, two developers might be sitting discussing a particular problem which a third developer knows the answer to. The third developer has their headphones on though so can’t hear them and lose the opportunity to pitch in and offer advice.

The best solution is to get a room for the whole team to work in away from noisy areas.

Slow Typing Developers (Personal Factor)

It never ceases to amaze me how many developers I meet who have years of experience using a keyboard but still type with one finger whilst staring at the keyboard. So, why do I feel the need to mention this? Well, consider how you drove when you first passed your driving test. Personally I spent a lot of time concentrating on actually doing the driving. Now it is of course automatic and I can spend time thinking about other things, like where I’m going, or if there is a better route to get to the same place. It’s the same when you are developing. If you have to spend your time concentrating on typing at a snails pace you are going to take longer to get there, and may find you took a poor route. Because typing isn’t natural you take longer and lose valuable thinking time whilst you are typing. One observation is that slow typing developers tend to also be dreaded ‘cut and paste’ developers who introduce duplication, and hence code rot, into the system.

Effect of Training (Training Factor)

Training a developer will hopefully raise their maximum productivity rate. Well, that’s the theory! If the developer spends all day in a noisy office, sitting on email, making lot of personal phone calls and chatting about last nights football game then lack of training really isn’t the problem. I’m sure you know the type of people I’m talking about. Anyhow, if you provide the right training the graph should change like this:

Personal Time Management (Personal Factor)

The assumption that the maximum productivity rate is linear throughout the day is incorrect but does not affect the arguments for distractions and environment. However for this section we need to be a bit more realistic. The curve below is what I think a common developers productivity rate curve look like.

They are good in the morning, then start to decrease after lunch, and then pretty much useless after 5pm. This is one reason why working long hours is a waste of time. When you work long hours you get the same amount of work done, it just takes longer. If you work too late you can even start going backwards and creating more mess. As a general rule I don’t let any developers change production code after 5pm. In XP the concept of ’40 hour week’ is used to resolve these problems.

Personally I’m at my best between 9am and 3pm. After that I tend to tail off a bit and after 6pm I’m not great at all. I know this, so I organise my day around that. I schedule the harder work in the morning and easier work in the afternoon. Note however, that some days I’m better in the afternoon. I might have had a sleepless night or something.

The message here is that you need to schedule the tasks for the day optimally based on your own productivity rate curve.

Code Rot (Design Factor)

The code base can rot for many reasons. Here are a few: Tight timescales resulting in last minute hacking; junior developers let loose on system; no consistent architecture; lack of technical leadership; Cut and Paste Programming; failure to address design problems. I’m sure there are plenty more.

To avoid this the XP community uses Refactoring. Refactoring is the term used when improving the internal design of a system without changing the external behaviour. Code Rot is the reverse of this, which I call ‘Refuctoring’. This is when you ruin the internal design of the system by poor coding. Examples would be cut and paste duplication of code. The CPG below shows that the maximum productivity rate decreases over time as the code rots and developers wade through mud trying to shoe horn more features into the system.

Where does Technology Fit In?

I’ve described many of the factors that affect productivity. To improve productivity is to essentially do the reverse of these. It is worth noting however, that increases in productivity are not strictly related to technology. At no point will I ever tell you that using more XML, or using Web Services will make you build systems better and faster. That really would be missing the whole point.

Introducing new technology can help increase productivity, but there are so many other large fish to fry before even thinking about the technology issues. Issues about personal time management, environment and development process and project management are, in my opinion, far higher on the agenda.


Turn the email system off. Turn the phone off. Schedule your tasks to best suit your effectiveness throughout the day and learn to type. After that, start thinking about the development process and training, and finally technology.

In my next article I’ll talk about automated system testing and how to measure project velocity.

Happy developing.

Dave Chaplin

Other Articles

Test Driven Development (Dec 2003)
The Losers Olympics (Sep 2003)
Making Projects Succeed: Part 1 - Measurable Business Goals (Sep 2003)
Pitfalls In Software Development (June 2003)
Extreme Web Architectures - Testing Web Applications In Seconds (June 2003)
Pair Programming and Quad Programming - From Experience (June 2003)
Making Extreme Programming A Success (April 2003)
Contractual Test Driven Development (TDD with DBC) (April 2003)
Moving To XP (Feb 2003)
Maximising Development Productivity (Dec 2002)
Writing Automated Browser Tests Using NUnit and IE (Oct 2002)
Mitigating Requirements Risk With Agile Practices (Oct 2002)
10 Tips for Successful Team Leading (Oct 2002)
Developing Automated Using Tests Using NUnit 2.0 With VB.NET (Sep 2002)
Quality By Design - Part 1.doc (May 2001)
Quality By Design - Part 2.doc (May 2001)
Quality By Design - Part 3.doc (May 2001)

Other Resources


Extreme Programming


Agile Modelling

All content © Byte-Vision Limited 1997 - 2004