|
|
|
|
|
|
by aeternum
657 days ago
|
|
|
There is some real technical debt but there is often also imagined technical debt. To use an analogy, some engineers may think gothic architecture is ugly and should be replaced. That doesn't mean it is structurally unsound or that there is anything wrong with it. |
|
|
Debt is garbage that fights you every day in delivering project goals. Everything else doesn’t need to be addressed now, or maybe ever. Write down what limitation it might introduce and move on. Just hope you have the history and experience to properly solve that problem later - it’s either on the project maintainer or business, and they are only good at their job if they know which will matter.
I have an internal rating scheme I use to classify debt based on risk / lost opportunity:
1. Efficiency
2. Feature Quality
3. Growth
4. Continuity
Efficiency projects lost productivity to the development team. It should eventually be addressed or you will lost momentum in hard to measure ways. Examples: Developer tooling issues, lacking documentation, failure to reach consensus, stable code with suboptimal API design.
Quality projects continuous customer impact due to bugs within certain vertical areas. Examples: Poorly coded features at the “leaves” of your code that don’t affect other areas but block improvement of itself.
Growth projects failure to meet a subset or all future deliverables. A failure is defined as anything that doesn’t meet required timelines to capitalize, or becomes downright impossible. Examples: Bad system architecture, data modelling, shared component that cannot scale to planned future requirement.
Continuity means what we currently have is going to fuck us at any moment. It’s a time bomb that gets worse passively. Examples: Security, major vendor deprecation, declining system stability.
Many developers I’ve worked with have never bothered to categorize debt, which is their fault. Many gravitate toward 1 and 2, but 3 and 4 are true debt today. The others may or may not evolve into 3 and 4 over time. You keep an eye on them but don’t argue about them until they will definitely become 3.
This is easy because a 2 flips to a 3 as soon as the code is even talked about being shared, or if it’s DX related and you’ve been asked to stretch it to the point productivity can be predicted to measurably decline. Come with numbers to prove your case, it will become easier and the evidence based approach plays much better than feelings and complaining.