Thoughts on Return on Investment (R.O.I) in Software Engineering

Why bother with R.O.I

In order to know the Return on an Investment, you need to know the cost of the investment. More than that, you need to know what you expect the return to be (how you will measure it) and when you expect to see it.

There are some base assumptions here that go unspoken everywhere you go, but I am somewhat of a scientist myself, so let's make them explicit:

Those two things are enough to suggest you have to make good choices now and they must be based on some kind of evidence. That evidence is the projected return on investment.

N.B. If you find your self calculating the R.O.I of something that has already happened it is probably not for a good reason, but will help you avoid the same mistake in the future.

Armed with this knowledge you can make a decision about what to do next. You can decide to invest in something or not. You can decide to invest in something now or later. You can decide to invest in something else instead.

Measuring things in general

Lets begin with some background on my experience with R.O.I.

In the before times, when I was a Chemical Engineer at X large company the way that things could be measured was much more straight forward. The company had a target IRR that it aimed for and business cases that would operate in the range of decades.

Before that I was a student, mostly working in thermodynamics and established laws of physical systems, where everything was also easy to measure.

Both these previous statements are lies, nothing of course was easy to measure in thermodynamics. People smarter than me had toiled away for centuries to simplify things. I arrived on the scene ready to have it regurgitated at me in a way that I could understand. I was not disappointed.

Do you think that measuring the impact of software engineering is supposed to be harder than this?

Research and truth seeking

I took to the internet to find out if there was a simple set of rules for calculating return on investment for software engineering and I was not disappointed.

I found a book with mixed reviews which I think I will give a hard pass.

I found some news articles about stripe acquiring a company that measures engineer productivity. I'm not sure that this is the same thing as R.O.I but I'm building a mental model here. For anyone that has systems design experience you'll know we are just doing discovery, hold tight, I will get there.

I found a blog post that was a little more interesting. It talks about the fact that R.O.I is a financial metric and that it is hard to measure the impact of software engineering in financial terms. It gives a foot note of advice on why R.O.I is important and talks about what to use it for.

Finally on InfoQ I found a presentation by none other than Kent Beck that was a little more interesting. It starts with a focus on communication (okay Kent, you got me hooked) then it delves a little into the idea of measuring the impact of refactoring. Finally it touches on Net Present Value (NPV) which is a financial metric that I am familiar with.

The basics of Engineering

Kent and I are not on first name terms, as you might imagine, but I think he is on to something here. At around 27 minutes he said something that suddenly crystallized a thought in me that had been brewing for some time. Seeing Kent say this I realized I could be right (yes, here comes a confirmation bias). So here is what he said:

"May you live long enough, that people start doing the dumb things you did when you were young" - Kent Beck source

This quote applies to Software Engineering.

Specifically Chemical Engineering has lived long enough to have a significant equity of experience to look down on Software Engineering and say "give it a try, let's find out what happens?". Which, coincidentally is fine in software engineering, but a terrible idea in chemical engineering for reasons that are obvious to anyone that has ever worked in a chemical plant.

Software engineering is not yet old enough to have a set of best practices that are universally accepted. We are still in the wild west of software engineering. We are still learning how to do things. We are still learning how to measure things.

I'll tell you why. As Kent goes on to talk about the Time Value of Money and the Net Present Value (NPV) I transform Kent Beck into 3 separate talking heads. One from 2012, another form 2014 and a third from 2016. There are about 70 people I know that would have had the exact same reaction to this. Everyone that attended University with me.

That is because the powers that be in my Engineering school decided that before they let loose a bunch of half informed engineers on the world they would teach us about the Time Value of Money.

They would teach us about the Net Present Value (NPV).

They would teach us about the Internal Rate of Return (IRR).

They would teach us about the Discounted Cash Flow (DCF).

The best news here is that I know more than Kent Beck does about something. Which is something I thought I would never say, and likely to be something that will evaporate as soon as I hit publish on this post.

Software engineers, the great truth seekers

You are maybe wondering how we got here?

Accessibility.

Now, I am not talking about the kind of accessibility that you are thinking about. I am talking about the kind of accessibility that means that anyone can write software. Anyone can write software that is accessible to anyone else. And that software can be used by anyone else.

I'm not sending you a link to my latest open source Polystyrene factory that I decided to build on Sunday to avoid cleaning the car now am I!

This flows both ways. Traditional engineering is not accessible!

It takes a huge amount of time and resources to do anything in traditional engineering. That is only one part.

For the price of a small family car you could go to a boot camp in your nearest major city for 12 weeks. You could then get a job; probably paying you too much money (separate rant) and you could have software in front of unwitting users in under 4 months.

The equivalent in traditional engineering is 4 years of university, 2 years of graduate training and 2 years of experience before you are allowed to do anything that might impact the world.

Closing thoughts and a conclusion

I think that the reason that we don't have a good way to measure the impact of software engineering is because we are still learning how to do it. Any time someone comes up with a good attempt, they think they can monetize it into some software to sell to software companies. Once that happens market demand dilutes the pure academic idea into a polarized competition between two companies that are trying to sell the same thing.

I think that there is a missing component in the training of software engineers. Economics and finance. I think that if we taught software engineers about the Time Value of Money, the Net Present Value (NPV), the Internal Rate of Return (IRR) and the Discounted Cash Flow (DCF) then we would have a better understanding of how to measure the impact of software engineering.

I think that all forms of engineering have a similar set of universal constraints. Time, Money, People, Materials, Energy, Information, Equipment, Space, and Environment. Just like all software systems, these are not simply the sum of parts. The outcome is a product of the interactions. In software however you are often able to create time through automation, and simultaneously reduced the required amount of people in a tighter iteration cycle than traditional engineering.

This plays out at a macro level in behaviors that reward failing fast and failing cheap in these fast cycles. In contrast the cost of failure in say, buying the wrong sized pipe for a chemical plant is much higher. In part due to the upfront (Capital) costs but also because the time it takes for the N.P.V to become positive is much longer than software projects.

Finally to those that thought they would learn a quick way to calculate return on investment for software engineering. I'm sorry, I don't have one. I think that the best way to calculate the return on investment for software engineering is to do it the same way that you would calculate the return on investment for any other engineering project.

I can recommend a good book from 1970 on Polystyrene manufacture if that helps?