Hacker News new | past | comments | ask | show | jobs | submit login

All code is technical debt. We should not write it unless it serves a purpose of high enough value.



I like the idea but find that an overstatement that trivializes the nature of technical debt: at some level one is talking about things that "pay off now" but require "interest payments" in the future" and while one can kind of squeeze the line `for (let i = 0; i < array.length; i++) {` into that framework, experience says that that line by itself almost never requires a maintenance debt payment; if you have a list then you almost certainly want to iterate through it and refractors are driven by the size of the list, not by the bugginess of the looping construct...

I think what's really at stake is that code and data are a sort of inventory: they are not what you are selling, but they get turned into what you are selling. Inventory always has a carrying cost, and generally people underestimate that because they are only looking at the direct cost of storage, not how the presence of the inventory itself gets in the way, makes getting to other things harder, makes bottlenecks harder to see.

And that's where you see that debt is a wrong metaphor, because debt has the particular property that you can pay all of it off and that would be a good thing. By contrast inventory is a good thing in the right place: It means that if one thing stops working, the system can still continue for a while. Really operating with zero inventory everywhere is possible, and it's not done because it would drive you out of business. Similarly, deleting all of your code is not accessible in the way that getting rid of all of your debts is.

Designing an API to have a separate messaging later from its business layer from its data management layer from its data fetching layer is a technical debt; the fact that any change in the system now needs to be distributed across 10 different places in the code base is your interest payment. I would argue that you would like to derive all of these from some shared source of truth to remove those interest payments, and when you do, I no longer think that it's a bad thing for you to have a homebrew HTTP framework that has those separations in its internal functions.


I don't think that's true. If it's properly abstracted and implementation details are encapsulated, well written code can serve as documentation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: