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
Abstract
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?.....
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.
Conclusion
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
NUnit
http://www.nunit.org/
http://sourceforge.net/projects/nunit/
Extreme Programming
http://www.extremeprogramming.org/rules/testfirst.html
http://www.extremeprogramming.org/index.html
Refactoring
http://www.refactoring.com
Agile Modelling
http://www.agilemodeling.com/
|
