- Technical debt: That is the code that you recognize is sub-par, however that you just determined to put in writing for good causes, and that you’ve got a plan for correcting. Let’s face it—hardly any code on the market suits this description. What number of improvement groups even have a plan for paying again technical debt? Not so much.
- 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 means too heavy for the duty at hand. Perhaps the crew created pointless abstractions or added a function in a means that doesn’t match the system. Sadly, that is the form of factor that doesn’t seem till nicely after the actual fact.
- Simply dangerous code: Most of what will get known 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, crucial bug fixes that have 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 elaborate identify that suggests 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 correct means, you’ve obtained a tradition in decline.
As well as, labeling all of the dangerous stuff technical debt can result in justifying dangerous selections and practices. It might probably conceal issues like under-investment in engineering and poisonous, fixed deadline strain.
So let’s cease doing it. Let’s all agree that we will’t name it technical debt until we even have a backlog merchandise to repair it. Actual technical debt ought to have a piece ticket, a correction plan, and a deadline. The rest ought to be acknowledged for what it’s: crappy code. Let’s construct a tradition the place we’ve got actual technical debt, and the place we name the whole lot else by the correct identify. Let’s reserve “technical debt” for what it really is: a acutely aware tradeoff with a compensation plan.
Every little thing else? It’s not technical debt. It’s plain previous code rot.
