4 ms·
The analogy of the pine tree is an interesting one, it identifies that the shape of a technical product is not just about what problems it needs to solve today,
by andrewingram 5y ago
The analogy of the pine tree is an interesting one, it identifies that the shape of a technical product is not just about what problems it needs to solve today, but also the history of problems it's had to solve to get to today.
What the post fails to call out is that many of those problems simply might not exist anymore. That tree may have had to weather a freak once-in-a-thousand-years stormy season, and has structural baggage as a result; but if that tree were to grow again starting today, a repeat season may never happen and the tree would end up looking different.
One way we can consider technical debt is the extent to which the current solution differs from an (often mythical or at least hypothetical) ideal solution. How different would it look if we built it today, with only today's constraints, rather than all the historical ones? How much is that historical baggage getting in the way of us moving forwards?
- louwrentius 5y agoI still don’t see a benefit of being vague and call this TD. You can be explicit and explain why things are as they are and if we have to do some extra work because of code addressing no-longer-relevant-use-cases, that’s just it. No need to call this TD. Be clear and explicit. I think in most cases, Technical Debt is a much abused term to bullshit and cover up past mistakes. TD sounds much better than mistake and it sounds so ‘inevitable’, so you can’t be blamed.
- andrewingram 5y agoI don't disagree, I have no real attachment to the term and I think there's too much nitpicking about what the precise definition is. At the end of the day, sometimes past work can slow down present and future work; and if the impact is significant, you should do something about it.