These articles are aimed at senior management funding Software Developer or IT Professionals attempting to show the ROI benefits of what can sometimes seem counterintuitive.
This ever growing library is provided free of charge and can be found here.
In this article, part of my series explaining better ROI from software development, I’d like to look at what productivity looks like in software development.
TL;DR
Productivity in software development is not about quantity. Productivity is multifaceted thing and care should be taken to understand what that looks like to avoid dysfunctional behaviour and outcomes.
What is productivity?
When I talk about Return On Investment from software development, I’m looking for anything that could affect the output of a given development team.
One of the key things I talk about is the productivity of a team. Generally speaking the more productive they are, the better return you are getting from the investment that you put in.
Productivity in software development is often misunderstood. It is often expected to be the amount of code (quantity) that can be produced within a given time.
It really isn’t that.
It is very easy for me as a developer to produce huge amounts of code which produces no value. By focusing on the quantity you create a dysfunctional driver.
Productivity within software development is about delivering value.
And perversely, there will generally be little correlation between amount of code and the value produced.
Take an example;
Developer 1 is given a project. They just plough into the code. They work on it for a week, 8 hours a day and present their finished project.
Developer 2 is given the same project. They spend the first day really understanding the problem with the stakeholders. They spend the second day designing the solution. Days three to five they focus on the key requirements of the stakeholder while continually improving the solution.
And what would I expect at the end of that week:
- Developer 1 will likely have much more code, maybe even more features than Developer 2
- Developer 2 will likely have addresses the core problem much better
- Developer 2 will likely have produced code that is cheaper to amend or maintain
- Developer 1 will have “looked” busier
How would you see those two developers?
Developer 1, in most environments, would be celebrated over Developer 2 as working harder and not “wasting time”.
Developer 2 however has produced you better return on investment. He has addressed the core problem better (by understanding and exploring it) and reduced your long terms costs (by avoiding bloat and focusing on continual improvement).
And you see many leading development organisations understanding this. The likes of Google, Microsoft, Spotify, Umber, Amazon, etc all understand that productivity is not from the amount of code. (I’m going to share some concepts from Spotify in a future article).
So why is more code not the best thing?
We’ve been taught by manufacturing to measure productivity by the quantity of the output.
How many boxes have been moved from A to B?
How many cars come off the conveyor belt?
How many miles of road have been laid?
There has certainly been a belief that you can apply that same expectation to software developer; How many lines of code have been produced?
While rare now to find people doing it; I’ve even see productivity bonuses based on the lines of code produced in a day.
So why is that bad?
Quantity is no measure of quality.
If you measure by quantity alone then you create a dysfunctional bias towards poor behaviour. I can pour out a very high quantity of code that can vary from not working to dangerous. And if I’m being paid to do it … then I will.
Aside; I’m highly opinionated on performance management of software developers – more on that in a future article.
Quantity & Quality of code is also directly related to the total cost over its lifetime.
The cost of your software is not just the time to write it originally. It’s the cost to run it, support it, maintain it and changing it over its lifetime. Until such point as you destroy it, that software will be costing you money.
And the bigger and poorer the construction, then the more expensive that ongoing cost is.
This is a tight ship, my developers aren’t allowed to goof off
It’s too easy to use the appearance of busy as a proxy for productivity.
For years it’s been almost management 101 to jump on anyone that does have their head down focused on the job.
But what guarantee that the “appearance” of work is actually productivity?
I can look really, really busy – while watching cat videos on YouTube.
Conversely, I can do my most creative (and valuable) thinking staring off into space (looks very much like day-dreaming).
At this point I can actually picture an old boss saying “I’m paying to work, not to think”
Oh the irony
Software Development is problem solving
Problem solving is thinking
Thinking is working
The bit where I do stuff on the keyboard is the last part of that thinking process.
If we accept that thinking is a key part of the job, then we have to accept that it is correct (and indeed expected) for a developer to look like they are “goofing off”.
How to measure productivity
The short answer is that you measure the value of the work of the team over time.
“Team” because you need a team effort to produce software. If you are looking at the value of the individual you again drive dysfunctional results. You are pushing them towards thinking as individuals. They will prioritise their work over the work of the team … generally leading to a lot of incomplete, messy pieces of work that are struggling to progress.
Over time you can observe trends in the productivity. From week to week, month to month, it can go up or down or remain the same. Over time however you’d want an improvement trend.
Value is subjective to the organisation. This is normally the hardest thing to achieve. Mainly due to it being difficult to quantify as a real metric. In an ideal world this is revenue or profit delivered through the work done. It is rare however that anyone measures that.
So I can’t measure productivity?
Yes, you should be able to measure productivity.
The bigger question is should you?
When I talk about productivity in my articles, I talk about it in the abstract. I talk about it as being improved from its current “level”.
In most cases this is best to be treated as subjective rather than quantitative.
The effort to achieve a quantitative metric is generally a waste of effort. It is rarely going to help you.
Ultimately if you have a development team that are producing more value than they cost – they you are winning.
If your development team are able to improve their lot by having the autonomy (and desire) to improve, you will then see that ratio improve as a trend.
Here be dragons
As I’ve said in other articles, this is not something that can be forced.
Attempts to force will, in my opinion, always lead to dysfunctional results. Most often those dysfunctional can be difficult to predict before you go into it, so you having to make assumptions, which of course can be dangerous.
Create the right environment, the development team will flourish and you will produce better ROI.
Or, to steal from the film:
