A new term has sprung to fame in the past few years, technical debt. For me, technical debt is basically what gets created when a developer cheats and does a quick and dirty change to their system, usually due to time constraints. The formal definition of technical debt is below.
Technical debt and design debt are synonymous, neologistic metaphors referring to the eventual consequences of slapdash software architecture and hasty software development.
If you Google “Technical debt”, you will find over 200,000 results. There’s not a lot I can say that is new. I will make the points I feel are most important. Some are mine, others are my take on what others have said.
Accumulating debt by doing work in a minimal or wrong way is very similar to financial debt. It is usually created by inexperienced people under stressful conditions that need quick assistance. The debtor can sometimes grow accustomed to this quick and easy relief and start building debt more frequently without need. The debtor often gets into a perpetual cycle of creating debt under the false belief that their shortcuts will be corrected “one day” when the crisis of the month passes and they suddenly have 2-3 weeks of free time.
In my experience, most technical debt occurs due to time constraints. We cut corners because we feel we don’t have time to do things exactly how they should be done. More often than not, if you talk to your manager, a customer or other developers you work with and explain your situation, you will get the extra time you need. Don’t be afraid to ask or communicate.
Know the law – Parkinson’s Law. Work expands to fill the time available. If you believe a task will take 3 days to do correctly and you only have 2 days available, don’t start cheating. Do things the right way and you will find that your work will naturally adjust and you will do things the right way in the available time.
Bob Martin made a great analogy about developing the way a good sushi chef does their work. They subtly clean their tools as they slice and dice as a natural and important part of their process. It’s best to refactor and clean your code as you develop rather than waiting for the magical time afterwards to clean up things to the way they should be.
Don’t be afraid to delegate. Some examples of technical debt are not fixing compiler warnings or attending to TODO comments. If you are a senior developer and don’t really have time for these, they are great bits of work for a junior or new member of staff to work on.
If you absolutely have to cut corners and write code that breaks good design rules, below are the situations where it is okay.
- You are fixing a problem in an old legacy system or component that will be replaced very soon. Preferably tomorrow. The technically correct solution will take weeks or require a full rewrite.
- You are fixing an urgent emergency problem. E.g. your website has crashed. In this case, it’s better to make a quick fix that works right now, then start work on a clean layered solution to include in a later release.
- Capitalising on an opportunity. Just as a company can take on debt to give them the resources to capitalise on opportunity, so can a development team. For example, if you work for a games company and your game is targeted to be finished for the Christmas shopping season, take on some debt to be finished for then. It’s no good having a perfectly designed video game released January 1st, after everyone has done their Christmas shopping.