Knowledge creates technical debt

The post argues that technical debt is not only the result of bad decisions. It can also appear when a team learns a better way to build software, and the code base still contains the older approach.

Seen this way, the debt is the gap between what was known before and what is known now. That makes repair less like paying off a burden and more like using a knowledge-based opportunity, while also giving people a reason to avoid calling every disliked code path tech debt.

Reading notes

#

• Technical debt can arise when new knowledge makes an existing implementation harder to justify.
• The older code becomes debt because it now sits between current knowledge and current practice.
• The post presents the choice as either live with the extra cost or spend resources to update the code in light of what was learned.
• This framing includes better languages, libraries, tools, patterns, or other knowledge gained through the project or from elsewhere.
• The author says the word “debt” can sound negative, so the knowledge framing may help explain why fixing code is worth doing.
• The pile of technical debt is described as a pile of knowledge about how the software could be better.
• Refactoring then becomes an investment that can pay off over time, rather than only a liability to remove.
• The post also says this framing can curb the habit of calling every disliked codebase issue tech debt.
• Before treating something as technical debt, the author asks whether the team really knows the code is inferior or is only reacting to a hunch, preference, or trend.