Software Ownership Experience

When I was a teenager I started saving up for my first vehicle and I remember my dad saying the cost of buying it was the cheapest part of the ownership experience. I had not a clue what he meant but as I grew I understood that the cumulative cost of insurance, maintenance, registration, fuel, etc over the time of ownership often dwarfs the cost of purchase.

The same can be said for software design and implementation. We are often faced with the choice of adding more functionality to an existing code base or building a whole new solution. Over the last decade or so, with the advent of microservices, micro-frontends, microeverything architectures, it is often the default position that the new functionality should be a new, independent deployable microservice. It’s easier than dealing with someone else’s code and you can deploy it separately and scale it independently and so on, because these are definitely problems you have and need to solve, right? But I digress …

Build takes longer than expected as it always does, we had to write the service, make a new repo, set up a new pipeline, setup a database, build out some tests, etc. It takes a few months but that’s not so bad because …




It’s out in the wild doing the thing and now we can move on to our next creation! No, actually, now we need to do the boring stuff like monitor it, scale it, patch and upgrade it, be on call for it, debug it when it breaks. Now we’re into the cost of running the software and it turns out that can be a long time. The first thing I ever wrote after I left university in 2004 is still up and running and doesn’t look like it’s changed all that much. If you work somewhere like a bank or government you start to really understand how long software can live for.

Anything worth building will have a lifetime measured in years and will often outlast the decisions that lead to its existence and the author’s tenure at the company. When considering the architecture and build of systems, I often find the long term cost of ownership makes a much more compelling argument than short term cost to build. Maybe we should really be asking the cost to decommission a service before we consider the cost to commission it?

Although this post focuses on the cost of adding a new service to the fleet, this is just one example. The point to take away is that anything that is a drain over the life of the software is likely to have more impact than something more short term. Something as simple as toil in your deployment pipeline that uses up a few hours a week of engineering time will accumulate to an impressive amount that could have been used more wisely.

If I take it back to the vehicle thing, don’t buy a Lamborghini when a Prius will do.

Photo Ref: Young Frankenstien (1974)