September 8, 2025 at 12:00 am
Comments posted to this topic are about the item Requiring Technical Debt Payments
September 8, 2025 at 7:34 am
I wish that a more business-oriented name had been proposed rather than 'tech debt'. Something that conveys the friction that tech debt introduces into what the business really cares about.
Some tech debt is within the gift of the tech teams to be addressed as part of the natural development process. My colleagues and I have stretched this definition on occasions, knowing that it is easier to ask for forgiveness than permission.
There are areas of tech debt I would like to address; however, doing so takes time, money and an acceptance that the necessary changes require the people who need the system to accept significant risk. Anything that requires time and money will be competing against work, which the business values more.
Anything that incurs significant risk is deeply unattractive.
September 8, 2025 at 2:01 pm
There are areas of tech debt I would like to address; however, doing so takes time, money and an acceptance that the necessary changes require the people who need the system to accept significant risk.
I've been unsuccessful in convincing business people that a tech solution should be replaced in 5-8 years, depending on importance of the system. This just seems to fast/frequent for many managers to accept. I'm not sure business people know that the longer a solution is in place the more expensive it becomes to run. Employee turnover rates, the inevitable loss of institutional knowledge, the decreasing number of available workers with "that" particular skill set, decreasing product support, and decreasing community support all impact the bottom line.
I know there are accounting processes that depreciate assets over time. I wonder if there is a similar process that increases costs for technical solutions over time? Is something like this in practice already by most accountants?
September 8, 2025 at 8:14 pm
I don't think there's a good way to measure the lifetime of an app. There are plenty that run for years with relatively few issues. Most keep getting upgraded, and replacing them is hard because they keep growing and changing.
I wish it were easier to change things, but I do like the Phoenix Project model. They started the replacement while the original was still being worked on. Move new functionality to a new thing, maybe enough that you can slowly add old functionality and get rid of the ole thing.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply