Cost of Tech Debt
Hey!
Welcome back to another week of musings.
This past weekend was Burning Man, so the City was empty. It is always interesting to see this every year.
We went to have a fantastic brunch! I hope you had a great weekend and had time to restore.
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the past week
- Sara Dietschy's YouTube video about Vibe Coding, I like seeing people outside the software engineering bubble try it out without all the hype.
- I've been hearing a lot of DJ Sets on YouTube, and this 90's Chillout Set by Derrick Gee was good to have as background for work. I recommend his podcast if you like discovering new music.
- TBM 374: Strategy & Urgency by John Cutler, another great piece by John, talking about how Strategy actually has a timing dimension, to act proactively we need to take it into account.
If you've ever had to deal with tech debt, like me, you might have complained about not investing enough time to fix it, or even that we're investing too much time with tech debt and not enough time with new features.
Easy vs Simple
Most of the time, due to pressure to deliver against timelines and increase the business's prospects, we provide the fastest solutions, which tend to be the easiest to implement.
However, easy solutions generally don't lead to a simpler system without intentionality.
Build the Right Thing or Building the Thing Right
While we generally agree that we want simpler systems, I've come across groups of people who don't think a simpler system is the "right" system to have. I've even been that person in the past.
From experience, simpler systems, even with sub-optional architecture, are better than "right" systems, which require more operational support.
All Systems Need to Evolve
One trap we fall into is that we'll fix it later, or we'll delete it later, only to have Hyrum's Law make anything we put out in the wild become load-bearing.
Evolution comes organically through squeaky wheels or new features required by customers.
Intentionality
When intentionality kicks in? Well, that is separate from the technology discussion. In practice, your organization needs to be adjusted to deal with modernization, or tech excellence (as we refer to it in our organization).
In other words, you need to gain buy-in from multiple stakeholders, including Product, Operations, and Infrastructure. Because in many cases, turning down a system or rewriting it might involve double costs, productivity hits, and less time for bug fixes, etc.
If your organization is aware of the costs, you can consider setting up an architecture group or forming a modernization team.
With these types of teams, you can establish guidelines and help the team make decisions within the guardrails. As well as the organization having a muscle to deal with the costs.
Cost of Existing
In my current organization, most of our systems have spent more time in maintenance than in the initial development.
The ROI was huge, and at the same time, by existing, they incur costs in keeping dependencies up to date, updating them for new use cases, build times take longer, etc.
Eventually, there will be a threshold where the amount of effort is not returning the same amount or more. How do we know that we're close to it or even past it? If we're not growing, we're losing money by maintaining it.
Your turn!
Have you ever been involved in modernization efforts? What went well? What didn't go so well? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others