How to measure productivity in software development?

Productivity in software development isn't just about the number of lines of code or features delivered. It's an arena where knowledge is king. The real output is not just the software produced but the value it brings – be it business gains, customer satisfaction, or technical innovation.

Traditional inputs like time and capital are essential, but they miss a critical aspect unique to software development - the acquisition and application of knowledge. Think of it as a road trip where the efficiency isn't just about the fuel consumed but the experiences gained.

Outcome

“You cannot understand the meaning of productivity unless you know what the goal is. Until then, you're just playing a lot of games with numbers and words.” ~ Eliyahu Goldratt [1]

"...any true measure of software development productivity must be based on delivered business value." ~ Martin Fowler[5]

There are plenty of opinions on how to measure the productivity of knowledge workers, but no single approach is accepted as standard[3]. Productivity, in economics, measures output per unit of input. We improve productivity when we increase output and/or reduce input. The company producing more with a given set of inputs or using fewer inputs to produce the same output has an advantage over the company producing less.

What is the "output" of knowledge work in general and software development in particular? People measure output using Source Lines of Code (SLOC), Function Points or count Number of features, user stories, story points, commits etc.

Others prefer to measure the financial outcome produced by the output. Outcome could be the value the customer ascribes to the software. Could be the Business value e.g. Increased Revenue, Market Share etc. Could also be Technical value to the developers in how the solution was developed e.g. easy to change. Hence we can change the productivity formula to be:

Input, anyone?

"The basic economic resource - 'the means of production', to use the economist's term - is no longer capital, nor natural resources, nor 'labour'. It is and will be knowledge." ~ Peter Drucker [2]

What about the input, which is in the denominator?

Input can be a pile of raw materials, a bunch of machines, stacks of paperwork, and groups of employees, capital, or any other resource. In software development people usually use time spent, capital invested or operational expenses as the input in the productivity formula.

However all of the above inputs can actually be applied to manual work just as well! That is because they don't account for what is unique to software development only - its essence, which is the acquisition and application of knowledge.

Let's use a road trip as a metaphor. Say we are to go on a short vacation with friends or family. Our desired outcome is to go to a place in the mountains to enjoy recreational activities. So in the productivity formula the numerator would be our desired outcome.

What would we have in the denominator? We shall travel by car so it is useful and very practical to spend as little fuel as possible. The less fuel consumed the more efficient our trip would be. This type of efficiency works with any outcome. For instance, next week we may decide to go to the seaside and enjoy recreational activities there. Even though the travel distance will be different we can still measure the efficiency in liters/100 kilometers or miles per gallon (MPG).

What would be the equivalent to fuel consumption in knowledge work in general and software development in particular? Software development is a process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer.

Cars run on fuel. Software development runs on knowledge.

Productivity in software development

Software developers apply knowledge in order to deliver outcomes. We really want to count not the knowledge~ they have, but the knowledge they don't have, since it is this (lack of ) knowledge that really takes the time in developing software systems[6]. If software developers don't have the knowledge needed they have to discover it. The knowledge they have to discover is the total of what they don't know they don't know and what they know they don't know.

Prior knowledge is the easiest and the fastest to discover - it is in the head, one just applies it. In other words, when prior knowledge is applied then there is the most efficient knowledge discovery. Conversely, when a lot of knowledge is missing then the knowledge discovery is less efficient. The more prior knowledge was applied i.e. the less knowledge was missing for achieving the desired outcome the more efficient the software development process is.

If an organization is more efficient in terms of knowledge discovery it should produce more working software for the same time.

Software developers discover knowledge by asking questions. The average number of “Yes/No” questions we need to ask in order to gain the knowledge needed is called “Missing information”. “Missing information” is defined by the Information Theory introduced by Claude Shannon[4]. A Knowledge Discovery Process consists of asking questions in order to acquire the missing information about "what" tangible output to produce and how to produce it.

Hence we can change our productivity formula to be:

f the outcome we search for is a gold coin hidden in one of 8 equally sized boxes we need to ask a minimum of 3 questions on average. If the outcome we search for is $100 billion hidden in one of 8 equally sized boxes we also need to ask a minimum of 3 questions on average. That means the same number of questions could bring different outcomes. That's why we analyze not the outcome but how efficiently the outcome was produced.

Productivity is high when less knowledge needed to be discovered for the outcome to be produced.

Fortunately, there is a way to measure the knowledge discovered (missing information) in software development. KEDEHub allows you to measure the knowledge discovered using the scientifically backed and patented metric - Knowledge Discovery Efficiency (KEDE).

Now we can rewrite the productivity formula for software developers to have KEDE in the denominator.

For example, if we have an outcome of $100,000 and KEDE of 2, then productivity will be $2048 per bit of information. On another hand, if we have the same outcome of $100,000, but this time KEDE is 20, then productivity will be $25,000 per bit of information.

Works Cited

1. Goldratt, E. M. (2012). The Goal: A Process of Ongoing Improvement - 30th Anniversary Edition (3rd edition). North River Press.

2. Drucker, P. (2018). Essential Drucker. Routledge.

3. Ramírez, Y.W. and Nembhard, D.A. (2004), "Measuring knowledge worker productivity: A taxonomy", Journal of Intellectual Capital, Vol. 5 No. 4, pp. 602-628. https://doi.org/10.1108/14691930410567040

4. Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal. 1948;27(3):379-423. doi:10.1002/j.1538-7305.1948.tb01338.x

5. Martin Fowler CannotMeasureProductivity

6. Phillip G. Armour. 2004. Beware of counting LOC. Commun. ACM 47, 3 (March 2004), 21–24. https://doi.org/10.1145/971617.971635

How to cite:

Bakardzhiev D.V. (2022) How to measure productivity in software development? https://docs.kedehub.io/kede/kede-productivity.html