Technical debt is a topic that's been written about extensively by many people over the years. It can be a little tough to define, but in the broadest sense, technical debt is any unaddressed opportunity to improve a codebase.
The cause might be rushing a feature out the door at the expense of code quality, a framework the codebase was built on becoming outdated, or three developers creating code that's nearly identical except for subtle differences.
If a non-programmer asked what technical debt was though, how would you explain it?
Here's 10 ways I might try.
- To a chef, it's choosing to make a meal faster at the expense of leaving the kitchen looking like a warzone. Things need to be tidied up occasionally or no one can find what they need before the food burns.
- To a physician, it's maintaining their current pace of work using outmoded methods, at the expense of taking extra time to learn and implement new techniques in medicine.
- To an architect, it's trying to build bigger and better structures, but not putting in the time to learn about new improvements in material and design.
- To a mechanic, it's a quick fix like adding more oil without fixing a leaky oil pan, or replacing unevenly worn tires without doing an alignment.
- To a vehicle owner, it's saving a few bucks by skipping needed maintenance, knowing something will eventually break - and at the least convenient time too.
- To an electrician, it's overloading a circuit with a few more lights and outlets (just one more...) instead of taking the time to rewire the breaker box.
- To a construction worker, it's building something on a flimsy base that looks good in the short term, at the expense of holding up for years to come. Looking at you, Ryan Homes.
- To a child, it's sweeping toys under the rug and into the closet in order to get to what they really want to do - and then complaining when they can't find what they're looking for anymore.
- To a parent, it's taking the easy route by skipping out on discipline now, only to discover later on that the lack of discipline bites you big time.
- To a business owner, it's finding yourself the owner of a program that takes new employees longer and longer to understand, is more and more likely to break in unpredictable ways, and scares the living crap out of old employees who avoid large swaths of the codebase due to a sense of self-preservation. :p
What'd you think of these? Good? Bad? Ultimately, all comparisons fail to capture the many aspects of what exactly technical debt is. How would you explain it? Share below!
And if you want to read some pragmatic posts on the subject, here's a few from Erik Dietrich that I liked:
And then there's Ward Cunningham, who (afaik) originally coined the phrase: