
The Fallacy of Technical Debt - fpgaminer
https://medium.com/@fpgaminer/the-fallacy-of-technical-debt-202f7406337e#.4wxxnqksy
======
devnonymous
> 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.

~~~
zzzcpan
"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.

~~~
devnonymous
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...](https://www.google.com/search?q=literate+programming+the+word+count+problem)

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

~~~
zzzcpan
"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.

