Productivity is Measured Differently in Software Development

Productivity has been a key performance measure of workers for millennia. The most basic measure of productivity would be Output divided by Hours Worked. The output measured of course will be different based on the work being performed. If you work on an auto assembly line, your output would follow how many cars are produced every day (macro productivity).

The challenge with measuring productivity for developers is their output is not as easily measured. For example, it was (and is still) common for developers to be measured by the lines of code they write, which is an inherently bad measurement because it provides an incentive to write code that is unnecessary and bloated to have a high output relative to hours worked. Unfortunately, this does not measure the underlying value returned from the entirety of the developers’ effort. We have not created a meaningful way to capture value output relative to the input required by developers because there is so much more than writing code.

OKRs represent one way to identify value, but too often they are focused on individual accomplishments in support of some goals that may or may not have a quantifiable value associated with them. And having written many OKRs in the past, I know I write them in a way that seems most likely for me to be successful and get my bonus. If we want to get serious about productivity regarding software development, we must create a way to quantify the value returned and do so in a time-sensitive manner. We cannot meaningfully measure the productivity of software development while continuing to run large multi-month/year projects which do not have a quantifiable value associated with them. To understand productivity, we must have our development teams work in shorter efforts that are associated with a quantifiable value that can be tracked once the code is pushed to production.

It doesn’t matter how much time is spent coding, what matters is how much value has been realized and if you have the right strategy, tied to the right solutions, you will inherently have more success in delivering value. And in those instances where value wasn’t delivered, it’s not the fault of the people doing the development, rather this becomes an input into understanding how we can create value.

By focusing on value delivered from a productivity perspective we accomplish two things:

1. Maximize the productivity of high-cost development.

2. Effectively manage our technology investments so that we don’t over-invest in low or diminishing-value work.

If you would like to learn how to develop a value-based technology planning capability for your organization you can contact me a michael@soundagile.om