As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too.
The sources of the depreciation are tech debt and general turnover/churn in the method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today).
We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for?
If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?).
Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.
This is very valid and well written. One point I like to stress is the external context I often observed for why it is deprecating. As a company grows initial architectural decisions become more of a burden. So even though some software is running just fine for the specific business case, your new stack can do 80% but also a lot more. This is my way of selling modular solutions, where you can easily take away things and put new things into place.
Yes, that's a great point. Once we think of a software system as a depreciating asset we start to see a number of factors which are beyond our control. Another example when we're building web apps is that the competitive landscape has changed -
* 15 years ago no one expected their website to work well on a phone, or serve up much in the way of streaming video.
* 10 years ago no one was expecting that a server should respond in under a second, aka Lighthouse's TTFB, and the concept of say a "Largest Contentful Paint" did not exist.
We can go on forever, so what has happened is that all the practices and expectations within the industry have been redefined (occasionally even for good reason!). To stick with the car analogy, you don't expect much in the way of self-driving features from an older car... hell power windows didn't even become ubiquitous until the 1990s.
So maybe we just can't get a great TTFB and LCP out of our old dependency stack which existed before those concepts were really a thing, and there you have an example of why a rebuild will probably continue to be a "when" rather than an "if" for years to come.
Now we can frame the discussion as "let's partner up to ensure we make the best use out of this system and extend its life as much as is reasonable," which doesn't have to be an adversarial discussion.
The sources of the depreciation are tech debt and general turnover/churn in the method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today).
We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for?
If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?).
Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.