Let’s talk about technical debt. There are probably three sorts:
- The aftermath of a consistently poor-quality process of code stewardship
- The temporary scar tissue produced when a deadline was prioritised over “doing it properly”
- A deliberate act of hacking scheduled for near-term rework
Of these, the middle one is immediately one to watch. Ideally it wouldn’t exist. We would make a conscious decision to compromise something with planned rework on the roadmap. If the middle one happens and is not addressed by the natural order of the process, then it turns into the first one. For the purposes of this discussion, let’s classify the first two types of technical debt as the same thing.
In debt terms, the assumption is that debt is a bad thing. Getting into debt seems to be a regressive state. This is certainly true for those folks who find themselves paying a fortune to credit card companies in terms of compound interest, while unable to make ends meet and getting deeper into the situation.
Technical debt is called so for a good reason. Any cruft hanging around your code is a solid reason that your code cannot easily and safely grow. This is similarly true for poorly written tests, by the way. The absence of tests, or the presence of over-wrought tests either adds risks when you change your software, or adds spurious failures, respectively.
But debt is not a bad thing. People get into debt all the time and it helps their businesses and lives progress. Mortgages are a very manageable form of debt. When buying houses, a bridging loan is equally an important measure to temporarily get you from A to B.
So consciously managing your way into technical debt is another tool in your toolbag.
Here are some suggestions for how to make the most of the idea:
- Consider the principle of Fix it Twice
- Have a clear boundary around the area that’s going into debt. Confine it to one service, hidden behind an abstraction, enabling future rework without much impact.
- If the implementation is going to be ropey, try to produce high quality tests to help you get back out
- If you’re skipping tests, then produce more documentation/understanding in your people so that things don’t become a mystery for the future
- Most importantly: challenge yourself over what if you would do it properly? Maybe even have an attempt to do it properly running in parallel with the “workaround”
Business deadlines don’t go away. Often hacking can push getting a meaningful result further away, but that’s clearly not ALWAYS true. If you keep yourself honest in terms of when to go into debt and when to get out of debt, and if you use a short cut as a short term win, then you’ll manage your borrowing and be able to keep control of your tech stack.