3 ms·

Ward Cunningham disagrees with your interpretation of his metaphor. http://www.youtube.com/watch?v=pqeJFYwnkjE&t=4m18s http://www.youtube.com/watch?v=pqeJFYwnk

by zupatol 15y ago

Ward Cunningham disagrees with your interpretation of his metaphor. http://www.youtube.com/watch?v=pqeJFYwnkjE&t=4m18s http://www.youtube.com/watch?v=pqeJFYwnkjE&t=4m18s He explains that technical debt is code written before you have a complete understanding of the problem to solve. You repay the debt by refactoring it when you have a better understanding. This only works if the code is clean enough to be refactored.

geebee 15y ago
Why can't you repay the debt by just rewriting the code instead of refactoring it? I once paid off a technical debt incurred by a previous programmer who had done a code and dash of epic proportions. The code was utterly horrendous, and so many changes had been done in-place, right on the production server, with hard coded paths, that we had to rewrite it bit by bit. We didn't even know all the functionality in it, other than that it was in active use (we found and interviewed people to get a full sense of what it did). It took years, but we did pay it off.
- kragen 15y ago
  One of the "refactorings" in Fowler is "change algorithm", which I think is a bit of a cheat.
mattmanser 15y ago
It may not be what he intended but that how's the term is in usage. Technical debt also means making a mess. Because you were trying to get it out the door asap. Or you didn't really understand the paradigms of the language you were using. Or the framework. Or because that part of the system was written by someone who's not a very good programmer. Or because requirements changes and you didn't have time to fix it properly as the db schema change was too massive to do all at once. Or one of the many other reasons. Because so many people use it that way, that's the definition now. tbh I have no idea what Uncle Bob's talking about in that blog post, it didn't make much sense to me and he really seemed to be grasping at straws with that example. You use a crappy old paradigm (frames) because you're not good enough at the new one (ajax) as no-one really knows what to do or what works best and there are no established patterns to copy yet. Why you then need more tests or more pairing when the code's simpler and the paradigm's known to everyone doesn't ring true to me at all. These days of course the opposite is probably true of that example.

by zupatol 15y ago

geebee 15y ago

Why can't you repay the debt by just rewriting the code instead of refactoring it? I once paid off a technical debt incurred by a previous programmer who had done a code and dash of epic proportions. The code was utterly horrendous, and so many changes had been done in-place, right on the production server, with hard coded paths, that we had to rewrite it bit by bit. We didn't even know all the functionality in it, other than that it was in active use (we found and interviewed people to get a full sense of what it did). It took years, but we did pay it off.

kragen 15y ago
One of the "refactorings" in Fowler is "change algorithm", which I think is a bit of a cheat.

mattmanser 15y ago

It may not be what he intended but that how's the term is in usage. Technical debt also means making a mess. Because you were trying to get it out the door asap. Or you didn't really understand the paradigms of the language you were using. Or the framework. Or because that part of the system was written by someone who's not a very good programmer. Or because requirements changes and you didn't have time to fix it properly as the db schema change was too massive to do all at once. Or one of the many other reasons. Because so many people use it that way, that's the definition now. tbh I have no idea what Uncle Bob's talking about in that blog post, it didn't make much sense to me and he really seemed to be grasping at straws with that example. You use a crappy old paradigm (frames) because you're not good enough at the new one (ajax) as no-one really knows what to do or what works best and there are no established patterns to copy yet. Why you then need more tests or more pairing when the code's simpler and the paradigm's known to everyone doesn't ring true to me at all. These days of course the opposite is probably true of that example.