Both definitions provide valuable elements that help define the types of issues that we would refer to as Technical Debt. These types of issues may have many causes, and while the particular cause may be helpful in reflecting on potential process change or even providing insight into how to address them, the important thing is to identify the deb debt that exists.
These items are referred to as "debt" because correcting them has a cost and will will need to be dealt with at some point.
This article discusses Tech Debt and described three types of Technical Debt which we think are useful:
Deliberate tech debt
Often, engineers will know there’s the right way to do something, and the quick way to do something, says Dag. In many cases, the quick way is the right way (to avoid over-engineering), but at times the team will intentionally do something the “wrong” way because they need to quickly deliver product to the market
Accidental/outdated design tech debt
When designing software systems, Dag’s team tries to balance thinking ahead and future-proofing their designs with simplicity and quick delivery. This is a tricky balance, he cautions, and nobody gets it right every time. As systems evolve and requirements change, you might come to the realize that your design is flawed, or that new functionality has become difficult and slow to implement. A good original design will often be easier to refactor incrementally, but sometimes you may have to bite the bullet and do a more significant refactor.
Bit rot tech debt
Bit rot tech debt happens over time. A component or system slowly devolves into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design. Symptoms are, among others, copy-paste and cargo-cult programming.
Often Since Tech Debt is often tied to Non-Functional Requirements (NFRs). Consider , consider these categories of NFRs:
The definition above uses the loose and non-defined term "non-functional goals"specific terms like "need to revisit" and "known issues", mostly because we feel it will be impossible to list all non-functional requirements, and therefore also very hard to list those that are importantcircumstances that might cause a Tech Debt discussion. Instead, we recommend relying on the judgment of the people who are working on FOLIO to identify when things are deviating too much from what we feel are where we want to be.