- Technical debt: That is the code that you realize is sub-par, however that you simply determined to jot down for good causes, and that you’ve a plan for correcting. Let’s face it—hardly any code on the market suits this description. What number of growth groups even have a plan for paying again technical debt? Not quite a bit.
- Unintended complexity: Fred Brooks coined this time period, which completely describes code that isn’t proper and that outcomes not from negligence or dangerous coding abilities, however as a result of nobody understood the system and made dangerous selections. Perhaps the crew selected a framework that was method too heavy for the duty at hand. Perhaps the crew created pointless abstractions or added a function in a method that doesn’t match the system. Sadly, that is the sort of factor that doesn’t seem till nicely after the actual fact.
- Simply dangerous code: Most of what will get referred to as technical debt is simply rushed, slapped-together, or “emergency” code that was by no means reviewed, or was glossed over as a result of it “labored” and the client was screaming. band-aids for buyer fireplace drills, vital bug fixes that had been checked in over the weekend, or artifacts of builders working with out sufficient time, readability, or help.
A fairly label
The issue with calling all of it technical debt is that it places a fairly label on avoidable issues. We give ourselves an excuse to do the improper factor as a result of we may give it a flowery identify that means we’ll “pay it again” later, when everybody is aware of that we by no means will. When the crew is allowed to make use of the time period to justify not doing issues the precise method, you’ve received a tradition in decline.
As well as, labeling all of the dangerous stuff technical debt can result in justifying dangerous selections and practices. It could conceal issues like under-investment in engineering and poisonous, fixed deadline strain.
So let’s cease doing it. Let’s all agree that we are able to’t name it technical debt except we even have a backlog merchandise to repair it. Actual technical debt ought to have a piece ticket, a correction plan, and a deadline. Anything must be acknowledged for what it’s: crappy code. Let’s construct a tradition the place we’ve actual technical debt, and the place we name every thing else by the precise identify. Let’s reserve “technical debt” for what it truly is: a aware tradeoff with a reimbursement plan.
The whole lot else? It’s not technical debt. It’s plain outdated code rot.