3 ms·

I just do not think that there is anything magic about what some people call "technical debt" (but I prefer to call a "code smell", since how debt works fundamt

I just do not think that there is anything magic about what some people call "technical debt" (but I prefer to call a "code smell", since how debt works fundamtentally is quite different from people's typical conclusions around "technical debt"). Eliminating a particular code smell is like any other improvement to an application, but with a special focus on its lifecycle and the associated costs and benefits. And there are opportunity costs: Fixing a particular code smell means that future features of the application will get delayed. And the question is not only at what point in the future, in some (YAGNI) cases perhaps never, our now improved code quality let us catch up with otherwise earlier feature implementations: The extended time-to-market for our new features also comes at a price. So to decide what is actually best, it is not enough to look only at the technical side of a software project. The time-to-market (or time-to-use) cost, which has nothing to do with engineering per se, must also be taken into account. When deciding when a particular code smell should be fixed, both technical and business aspects are important: Technical effort and benefit must be evaluated and weighed against the aforementioned opportunity costs of feature delays. That is why good cooperation and open communication between engineers and business people within a company is important. If this is not the case, well, this is another smell that perhaps needs to be refactored first. If it is worthwhile ...

jahewson 4y ago
I disagree that technical debt should be viewed through the lens of code smells - those are specific, narrow concerns and if they are not burdensome then they do not constitute debt. There exists debt-ridden code with zero code smells (because its domain model is flat out wrong) and smelly code without debt (because it’s simply not of tangible impact). Technical debt is, to me, usually half-finished work. Instead of completing the job, we accepted an 80% solution that is designed in such a way that makes the 100% solution impossible without a complete rewrite. Eventually new features always break something or take a year each. It is this drag on speed that is the interest on the debt - we pay it with our time, endlessly.
wpietri 4y ago
I agree with you that open communication is vital to correct prioritization. But one good way to resolve that problem is to agree up front that there's a bunch of small stuff that's just not worth getting business stakeholders educated about, and that they should trust professional technical judgment as to how to spend some of the project time. And I think technical debt is a fine metaphor, because the term gives non-technical people useful intuitions about what is normally invisible to them. E.g., they can take it on when needed, pay it down as available, declare "bankruptcy" via rewrites. And if they don't pay it down, it will consume more of the "income", constraining future choices.

jahewson 4y ago

I disagree that technical debt should be viewed through the lens of code smells - those are specific, narrow concerns and if they are not burdensome then they do not constitute debt. There exists debt-ridden code with zero code smells (because its domain model is flat out wrong) and smelly code without debt (because it’s simply not of tangible impact). Technical debt is, to me, usually half-finished work. Instead of completing the job, we accepted an 80% solution that is designed in such a way that makes the 100% solution impossible without a complete rewrite. Eventually new features always break something or take a year each. It is this drag on speed that is the interest on the debt - we pay it with our time, endlessly.

wpietri 4y ago

I agree with you that open communication is vital to correct prioritization. But one good way to resolve that problem is to agree up front that there's a bunch of small stuff that's just not worth getting business stakeholders educated about, and that they should trust professional technical judgment as to how to spend some of the project time. And I think technical debt is a fine metaphor, because the term gives non-technical people useful intuitions about what is normally invisible to them. E.g., they can take it on when needed, pay it down as available, declare "bankruptcy" via rewrites. And if they don't pay it down, it will consume more of the "income", constraining future choices.