Code Story
Code Story
Compiler Recast - Do we want a world without technical debt?
Original episode: https://www.redhat.com/en/compiler-podcast/what-is-technical-debt?pfe-ngumm8p1n=show-notes
Hey guys, I'm back again to share another fantastic episode of the Compiler podcast, from Red Hat. As a reminder Compiler is a show hosted by tech veterans, discussing tech topics - big, strange and small.
On this particular episode - which is episode 4 - the team dives into the topic of technical debt, by first asking the question - what the heck is it? Its starts quite humorous, with the hosts slinging thoughts about financial debt and trying to bridge the gap there.
There definition comes down to this - technical debt is the cost of delaying necessary work on a project or platform, so that you can hit your milestones on time. Essentially, the cost of delivering new features as a priority over bug fixes or maintenance of a platform.
I think this is pretty accurate, but incomplete view of technical debt. I'd like to add my 2 cents to the definition. In my view, technical debt can also be inferior approach or framework decisions early on in the life of a piece of software, that you plan to uplevel, change or completely replace in the future. In the startup world, I find this to be the more commonly occurring form of technical debt, with the former definition occurring for more mature software solutions.
At any rate, this was a great discussion on technical debt. Have a listen to Episode 4, titled "Do we want a world without technical debt." Be sure and subscribe on Apple Podcasts, or your favorite podcast catcher. I'll make sure and add a link to the show notes as well.
And as always... Enjoy.
Support this podcast at — https://redcircle.com/code-story/donations
Advertising Inquiries: https://redcircle.com/brands
TL;DR; Define SLAs for your software/service/etc and use that to plan how technical debt should be addressed.
It's true that our time to work on a given project is finite, hence improving our ability to identify the most important problems caused by technical debt is essential. Only then can we make good decisions about how and when to address technical debt.
Not all technical debt is the same, e.g., there's technical debt created accidentally and without being aware of it, there's another kind which is created wilfully but with good intentions, yet another kind created wilfully by negligence, etc.
Also, not all software is equal, IMO critical infrastructure needs to have stricter Quality Control than other non-critical systems.
What is really useful, is to have the ability to track the impact of the technical debt, we can then plan resources to fix/improve things a way that's proportional to the magnitude of problems it generates.
These ideas come from the field of Cybernetics/Control Theory, the critical component I think, is to establish a feedback loop in which the "negative impact" of technical impact is given a numerical value, and that is fed into the process that creates the systems until this "negative impact" is kept below a certain threshold.
Quality of Service is the name of the game.