Ward Cunningham wrote:In other words, the whole debt metaphor, let's say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.
I think that the term got co-opted by many developers to refer to messy code.
Vaseem Mohammed wrote:What is the time we should work on the TechDebt when we are in a middle of a project?
Marco Behler wrote:That of course doesn't mean you shouldn't fix/refactor a messy codebase, but I find the term "technical debt" simply too vague.
Many developers either forget or don't realize that habitually spending a few minutes or seconds to rename, rearrange, or clarify code, no matter how insignificant they may seem in the small, can have very significant cumulative effects.
But postponing refactoring till the next day or week, iteration is very bad because the context of the problem will be gone from your head.
So switch between hats as often as possible but never combine them.
Everything's going to break at once and it won't be something you can band-aid, it's going to require literally months of redesign and coding.
Tim Holloway wrote:I've seen - and been wearied - by situations where you have systems so complex that one or more components could be updated daily (if permitted, this would be one of them). But letting everything slide like this borders on criminal. These are people with large-computer IT backgrounds and they should know better. I'd say that they're just planning to ride until it blows, then bail, but the way they're set up at the moment looks like all that would do is get them sued from every direction at once.