The Fallacy of Technical Debt | Hacker News Reader

The Fallacy of Technical Debt

medium.com

3 pointsfpgaminer4 comments

> This is because the real cost of software is time.

Exactly... And so it follows that technical debt is the debt of time. What your quick and dirty ^solution^ achieves today will be more expensive in terms of time, to fix/scale/debug/maintain tomorrow.

How is the author not seeing this? There is a cost and a value to everything. A highly valuable quick and dirty solution today makes sense only if it will cost less to throw away, replace or clean up.

Sigh, I'm tried of this industry that keeps not just reinventing wheel but rediscovering the entire process that leads up to it.

"What your quick and dirty ^solution^ achieves today will be more expensive in terms of time, to fix/scale/debug/maintain tomorrow."

This is also a fallacy. You are assuming that you know how and what to do better today to make it less expensive tomorrow. The simple truth is - you don't. You can only know how to do better once you do it in a quick and dirty way and it might not even be worth it.

Technical debt is very broken and very misleading concept that should be avoided.

My comment itself is a good demonstration of the point I was trying to make. I anticipated the possibility of misunderstanding or misinterpretation of my first statement and put in the time to add the second to qualify my point.

I did not intend make a blanket generalization against quick and dirty solutions (ref: google about Doug McIlroy and Don Knuth trying to solve the same problem[1]). I am in fact stressing that there exists a tradeoff that needs to be considered. Usually the tradeoff is made towards less work (ie: lazy programmers) -- less work for the foreseeable future (and if you can't forsee at least somewhat in the future, you're not doing it right).

By responding to just the first part of my comment you've confirmed the last part.

[1] https://www.google.com/search?q=literate+programming+the+wor...

edit: I mistaken said Bill Joy instead of Doug MaIlroy initially

"and if you can't forsee at least somewhat in the future, you're not doing it right"

This is the idea I'm trying to discuss. You cannot know future trade offs in advance. You can only make a bunch of assumptions about the future. But the more assumptions you make, the fewer of them will be correct or worthy of the time and even more will not be addressed at all. Which defeats the purpose of the technical debt concept.

Jumping into the future with the "no-technical-debt" solution is generally a bad idea.

Reply on news.ycombinator.com