Five big myths surrounding technical debt
- Myth #1 is that tech debt is amorphous, when in actuality it is usually a collection of many discrete problems. This means you can quantify tech debt (frequency, impact, cost to fix) on a spreadsheet or tracker and then prioritize based on impact.
- Myth #2 is that all tech debt has a single cause. In fact, there are three major sets of causes (or enablers):
a) Intentional tech debt, where the team knowingly took shortcuts to meet deadlines.
b) Unintentional, where poor code results from inexperience or incompetence or misunderstood requirements.
c) From age, where incremental enhancements and bug fixes cause a bit rot.
- Myth #3 is that you should never intentionally take on tech debt. But there are three situations where it may be justified: you are building a prototype or demo module to solicit feedback on a new feature or product, time to market is critical or you are building based on guesswork and anticipate client requirements will change sooner than later.
- Myth #4 is it only hurts engineers. In fact, it affects developers, product managers, customer support teams and customers, technical operations, and any executive team you may set up.
- Myth #5 is that only a full rewrite can repay the debt, whereas more often, a detailed plan of incremental fixes will solve it.
Full post here, 8 mins read