Thank you - I think you're framing the discussion in a more nuanced way than the author, by talking about different kinds of issues or technical decision which

Thank you - I think you're framing the discussion in a more nuanced way than the author, by talking about different kinds of issues or technical decision which lead to qualitatively and quantitatively different footprints of future maintenance effort. We could go a bit further and start trying to categorise decisions by the different footprints of future maintenance effort that they cause. Roughly, we could differentiate between decisions that: (a) cause no additional effort in future, (b) cause a once-off impulse of additional maintenance effort in future, (c) cause an ongoing pattern of periodic maintenance effort in future, separately from any other change, (d) cause the effort required to make any other change in future to be amplified linearly, and (e) cause the effort required to make any other change in future to be amplified superlinearly. So now we've invented five somewhat arbitrary, non-exhaustive categories of maintenance effort to talk about [+]. Technical decisions that cause future maintenance effort of the form (a) are (relatively) fantastic, and (b) are often fine as well. (c) can become problematic depending on how often and how much effort regular maintenance has to be performed, but maybe can be dealt with by hiring an extra pair of hands to perform the activity. (d) and (e) will act as productivity dampeners and bog down any other development efforts, if they get out of control may completely prevent progress. Technical debt issues of the form (e) might be: the system is built in a hand-rolled programming language that is not well defined, doesn't have specified behaviour or test cases, the developers are terrified of changing it but need to change it in order to make functional changes or fix defects in the system, but changing it tends to introduce more regressions that are discovered a few months later. Or maybe the code is arranged in an exponentially growing number of long-terms forks that need to exchange patches to support different special features sold to the latest key client, without good tooling support or test coverage. Or generally any system that's ended up in the state where the least-energy solution to fix any local problem makes the overall system globally worse, and for whatever reason no-one ever overcomes the energy barrier to do anything other than the locally easy globally corroding fix. [+] We can define a lot more than five categories -- for simplicity let's assume we live in a world where it is not possible to make a technical decision that can ever _reduce_ the effort to make changes in future ("what if we migrated from using global variables, if expressions and goto to prefer using locals and structured programming constructs wherever practical") and act as a global productivity amplifier for all future development. Let's assume for simplicity that maintenance burdens are never probabilistic or conditional ("approach X will never require additional maintenance effort in future unless the client ambushes us with unlikely requirement R, which will invalidate the entire theoretical and practical foundations of X at the core of the product. it's a wager, most likely the debt won't ever be called in") edit: i guess this could be characterised asymptotically with big-oh notation: "what's the asymptotic complexity of future maintenance effort introduced by this decision? as a function of t, time, or c, the cumulative number of changesets? O(0)? O(1)? O(t)? O(c)? O(c log c)?" Although it is slightly wacky focusing on asymptotics of maintenance burden as the time or number of changeset goes to infinity, since in relatively finite timescales all the clients will defect or go bust, the product will fall out of use, the company will go bankrupt, the developers will quit or retire. hopefully someone remembers to ceremoniously burn all remaining copies of the source repository.