I would say technical debt is a better problem to deal with. At least the project is alive at that point and you are able to get feedback from actual users.
Agreed. I feel like technical debt is more of a locus of control issue among developers than a real business concern. The only thing we look at all day is code; therefore, if the project fails, it must be because of the code.
Technical debt can be a very real issue though. I always strive to highlight the 'interest' we are paying on our technical debt to our product owners, so that they understand what deferring necessary work is costing them.
Agree, with the caveat that I think finding the balance here is really the hard part, and projects that don’t pay down technical debt eventually fail, if only because people decide to replace them because of the debt.
I think you're arguing against people using the phrase "technical debt" as a criticism, but those people are missing the point.
Technical debt isn't a perfect metaphor, but there's an aspect of it I think you're neglecting - the interest payments.
The point about debt isn't that you'll have to pay it back [1], but that you pay an ongoing cost until you do. In the technical debt case, the ongoing cost is opportunity cost - the initial quick hack may make it harder to evolve the code, or you may have to spend time fixing bugs instead of adding features.
As with financial debt, if that ongoing cost doesn't matter - because the payoff outweighs the compounded ongoing cost, or because you can offset the ongoing cost with other sources of cash flow / bandwidth - then taking the debt was the right call.
If you abandon the project (declare bankruptcy) then you never have to pay off the debt :)
If you "make it big", though, someone eventually will want to pay it off. Either you make it big by becoming a successful business, in which case your time horizon extends, and at some point the interest payments compound enough that you don't want to pay them any more. Or you sell to someone else, in which case they have the same problem, and (if they're smart) they should have paid you less because you sold them a liability along with an asset.
[1] Most financial debt has a maturity date, so eventually you do have to pay it back, although not if your lender is willing to indefinitely roll over. Technical debt generally has no maturity date, so you really don't have to ever pay it back!
I feel like this is a good illustration of the problem with "eh, why does technical debt matter, everything is still working isn't it?" It is, until it's not. And then it's too late.
We treat technical debt the same as any other issue. Put an issue on the board, decide on timing, assign it to a release, etc.
I think the problem for some is that they don't realize they are creating technical debt.
And yet. Technical debt costs you time and money over time. Fixing code six months down the line takes 5-10x as much effort than just fixing it while it's still fresh. Worst case scenarios is where you end up throwing away an application and rebuild it because the technical debt has made progress grind to a halt.
If there's nobody left who understands the code, or if there's hero coders who 'own' one section of the application, it's a huge risk to the company - which can, and has, bring a whole company down (there's a few stories on the daily wtf iirc).
A recurring thought with me and my projects after about six months is always "I wish we had done this properly the first time around"; in hindsight there was more than enough time, and it's costing a lot more time to fix it now.
I think it's valid to take on Technical Debt, but only when it's been explicitly decided that there's a good reason to take on technical debt. It's when you make a habit of always taking the quick and dirty approach and never take the time to refactor that you start running into problems.
Ok for your first point - although I'd argue that technical debt is something that usually asks to be repayed within months. A two year old technical debt is just an improvable software - that is, it didn't yet show problems serious enough as to call for a refactor at unchanged requirements.
As for your second point, what should I do? Try to get it wrong? To get it working how? We're not talking of premature optimization here, we're talking about understanding the requirements, understanding the tools, understanding the big picture, understanding your time constraints, and pulling out the best job you can.
Yup. Technical debt is a liability you take on now in the hope that it enables later being better than if you hadn't taken out on. But it's still a liability that may impede forward progress.
There are a few side-affects of technical debt that drive me nuts. These come from companies where developers are autonomous, self-choosing of time investment:
* continuous complaint without action (i.e. pretending to be a victim of the system you’ve built)
* lack of measurements for a system (technical debt or not, how is it working? Are you improving your measurement system after each failure to further understand the system?)
* unbuilt is better than unmaintained (this builds off the previous two — tell me what we learned from our previous attempts. If you didn’t understand the quality of the previous attempt, then how do we know if we actually improved?)
I’m down with fixing technical debt, just show me some metrics that prove that it was an improvement.
Technical debt is also more costly to pay in terms of morale. Slogging through painful refactors for weeks on end can pretty quickly make me start to resent my job and question whether this is a product I want to work on.
I don't know why you're getting downvoted. Tech debt is a tool and I think it's absolutely fair to put the needs of the business before documentation, or even code quality to a certain extent. As long as developers and management are aware that isn't free, and the cost must be repaid, I think it's the right decision in many cases.
I agree with what your saying, but the important idea with Technical debt is it's the interest rate and payments that you really need to consider not the capital.
A lot of terrible UI code may be acceptable as it rarely infects the rest of the system where a smaller design bug in a tiny utility library may end up causing worlds of pain even if it's rather elegant code that could be reused on other projects just fine.
Technical debt not only makes it harder to add features, it makes it harder to remove technical debt and make technical improvements. Choosing not to pay down technical debt is fine, but at some point it will be such a mess you won't be able add features or fix the technical debt issues without a total rewrite scale project.
reply