I’ve been thinking about measuring developer productivity recently. I’m lucky to work in a great team with varying experience, everyone adding something and pushing eachother to do better, either by helping out on a tough problem, or giving a nudge to lay down a better foundation.
Developers work in very different ways; some are very methodical, figuring a lot of things out up front and then putting pen to paper. Others go at it all guns blazing in shorter bursts, letting the code stream out of them like some kind of divine inspiration before taking a big pause to recover before going back at it again. Both producing equally good results through their individual methods.
You may have heard of the “10x” developer. In short a developer whose output is demonstrably 10 times more (at equivalent quality) than another. This can be a contentious subject. Studies have come to conclusions that 10x is the minimum variance you see in developer productivity, in some areas like ability to debug it can be 25.
If not sufficiently supported it’s possible someone can have a net negative impact on a project, costing other developers more time than they spent in the first place just to fix things up again – Sometimes issues in the core are not easily seen on the surface of a codebase or manifest in unpredictable ways.
One thing is clear, you cannot measure all developers by the same yard stick. Often managers who have not been a developer are tempted to measure effort by the most common office metric of time spent at computer. This however is a very dangerous metric to use for developers, ultimately impacting on the project itself and I’d like to expand on why…
High Intensity Interval Training is a method of exercise where the individual performs short bursts of intense exercise followed by longer periods of low intensity on repeat until exhausted. This is in contrast to say a steady jog. It is very effective, but that’s beside the point.
Coding is to HiiT as spreadsheet and email tasks are to distance running.
Programming and system design is a high intensity task in terms of cognitive load, and it often takes maximum levels of concentration to produce “bug-free” and performant solutions out of nothing, with shifting sands (tools and requirements) under time pressure.
From one point of view someone who is jogging along (unblinkingly staring at the screen) is being productive. Whereas someone else who is taking a break because they are, to go back to the the analogy, recovering after an intense sprint (figuring out a hard problem and coming up with a unique solution) may be seen as slacking. If you measure them by the same metric of time spent typing code, you’re going to misrepresent their effort and output.
- Developers will feel pressured to work harder or longer, not better. This will lead to poorer quality code that inevitably costs more time in the end.
- It leads developers to fast burnout and low morale, which leads to more mistakes and churn.
Things that can help:
- Understand the development process for an individual and support that individual.
- Create a conducive environment to flow state. Disruptions will kill your project timeline.
- Provide a sufficient specification and involve the people who will build it as early as possibly to avoid going back to the drawing board and major frustrations down the line.
- Allow for autonomy to make decisions that may save time (a feature of low importance can sometimes cost a large % of the total work, does it warrant its place?)
- Set aside time periodically to tackle technical debt, it’s good for developer sanity and your project. We try to alternate “housekeeping” sprints with feature sprints.
What does that mean to project timelines?
- Reduced overall timeframe.
- Easier for other developers to work on the code and add features.
- Easier to estimate new features or changes (fewer cans of worms).
So developers vary, but does a more experienced developer provide measurably better performance?
Experience can give:
- Reduced error rate. Two reasons: 1. There’s only so many times you can stand to get burned by the same problem and 2. “Muscle memory”, or neural pathways form and run much faster and more reliably.
- Faster bug fixing. Programmers tend to develop a gut instinct or intuition for where to look and how to break a problem down into smaller testable pieces that leads to finding the problem much much faster.
- Forward planning. Spending more time upfront on architecture Vs Getting Things Done ™ prevents spaghetti code developing later.
How do these add up in terms of overall performance? The study previously linked to found that in many fields including programming, 50% of the work is done by just 10%. In other words, it’s possible that investing in more expensive, more experienced developers can actually save money in the long run. On the flip side, throwing several more junior developers at a problem does not get it done in the same amount of time, as Brooks said, 9 women can’t make a baby in 1 month. The ideal then is to create a balance, with the more senior developers able to delegate easier tasks, catch and fix major bugs quickly, mentor and raise the level of others to increase the productivity of the team as a whole.
The client and anyone who acts as a stakeholder for them can get bored of hearing about refactoring this, or writing tests for that*.
Forward movement is therefore defined as stuff you can see: features, screens, buttons. Hold on. Forward movement is equally fixing bugs, restructuring the foundations of code so that future features can be added in roughly the amount of time estimated without any nasty surprises.
*Until the metaphorical #&@! hits the fan and everyone has to down tools and regroup because you skipped the boring work and now something has fallen over. Or more often future tasks have taken much longer to complete due to “cans of worms” being opened up in the code.
So if you are interested in understanding and promoting developer productivity here are just some starters, any thoughts please leave a comment.