If you’re reading this, you’ve probably come across the term “technical debt” before. If you haven’t, well, today is your lucky day!
Technical debt, like financial debt, means “being in the red”; when it comes to money, its meaning is clear. But with software development? Not so much.
If you search online (or ask your trusted AI), you will find that technical debt is:
A qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.
From Wikipedia
In layman’s terms, I define technical debt as:
Doing the quick and dirty solution, often with no regards for how badly it will age or escalate.
Examples include:
Silvia Tinena Coris (me)
- “Let’s hardcode this value instead of using a parameter from the database”
- Ideal world: all parameters are configurable and stored in the database
- Quick and dirty: let’s hardcode it (I assure you it will look like a “magic number” in a few months)
- Trade-off: let’s define a constant in the code with a sensible name
- “Oh, I’ve just written a really similar function for this… Let’s just copy/paste it in three different places with very small variations”
- Ideal world: keep it DRY. Write a function and pass whichever parameters you need.
- Quick and dirty: let’s copy/paste it (good luck remembering that you have something very similar elsewhere when you need to do changes)
- Trade-off: sometimes, “de-coupling” is better than DRY. But for a simple MVP? Just don’t copy/paste. Keep it clean.
Having just read this, we could think that technical debt is only about code. However, in reality, it rarely is just about code.
In software engineering, and most especially in start-up environments, where getting an MVP out of the door and being first-to-market is often-times primordial, we usually hear things like “ship fast” and “fix later”. Does this remind you of “buy now, pay later“? Exactly. We treat technical debt like a financial loan.
However, we often forget who actually ends up paying the interest.
In reality, most technical debt is really human debt. And, like any other debt, someone has to pay it.
Who pays the technical debt?
It’s not just a “dev team” problem… Like in the roulette, “all pay”.
We “All Pay”
The User
- Encountering janky UI and slow load times
- Dealing with bugs that break their workflow
The Team
- Turning 2-hour tasks into 2-day marathons, thanks to the spaghetti code (meatballs optional)
- Developing a “fear of touching code” because it feels fragile
The Business
- Paying an invisible tax on every new feature release
Conclusion
Taking on debt isn’t just a technical trade-off.
It’s a decision about someone else’s future stress.
My rule of thumb: borrowing time today can be fine… as long as there’s a clear plan to repay it.
Otherwise, you’re just creating a human problem for your future self (or your successor) to solve.
Leave a Reply