On Wed, Feb 12, 2020 at 01:16:03PM +0000, Rhodri James wrote: > On 12/02/2020 00:53, Python wrote: > > In pretty much every job I've ever worked at, funding work (e.g. with > > humans to do it) with exactly and precisely the resources required is > > basically impossible, and management prefers to underfund the work > > than to overfund it, for cost-savings reasons. This basically means > > that any non-trivial work you do inevitably will become technical debt > > s/become/accrue/. The work itself isn't the debt, but its sub-optimality > creates debt (or future headaches, if you prefer to think of it that way).
I think it's a purely semantic distinction without a practical difference...which was the point I was trying to make. The work is the direct cause of the debt, and at the time it is performed the debt is realized. Without the work, that particular debt is not incurred. You may have eliminated some old debt when the work is done, but your new debt replaces your old debt. Depending on the resources you can devote, that debt may or MAY NOT be less than the other, and sometimes the truth of this can not be discovered until you're already knee deep in it. > > So conceptually "costs" may be different from "debt" but in > > practice, you never have one without the other, and "debt" is > > really just "costs" you haven't paid yet. > > It's that last bit, "you haven't paid yet", that's the important part. > Project managers and accountants alike are very much in favour of putting > off paying for things if they can. Sometimes they can be persuaded that the > interest on the debt (the extra cost that the code structure imposes on > fixing bugs) is too much, and then you get the opportunity to refactor and > reduce the overall debt (at a cost, obviously) and the interest you will pay > in the future. Right. Or... not. More often than not, in my experience. And sometimes you can convince them you need to, but other priorities continually surface that block it from ever happening anyway. > Sometimes, and this is the bit that bean counters really like, you can get > away without paying the debt by ditching the project entirely before the > debt is paid off. If you don't want to piss your customers off you need to > pay the cost of a replacement project, which will accrue its own technical > debt... Or it may become obsolete due to changing circumstances. Or (as in many cases) it is sufficient to tell your customers, "don't do that," perhaps with admittedly annoying but not particularly costly consequences if they don't listen. :) [It's not always feasible, but often if they complain, you can say something like, "...but we're working on this other magic thingy that will really help you, and spending time on fixing this thing you're complaining about now will significantly delay the delivery of that." It may or may not be true, but in the interim the customer learns to stop doing that thing, and forgets they ever cared.] Technical debt is just about inevitable, for most non-trivial software (again, unless you've got a special case of a full solution for some problem whose circumstances never change), and isn't necessarily a bad thing. It just depends entirely on the details of your situation. And while I'm not particularly a fan of Agile in practice, the philosophy behind it addresses this reasonably well... But then again, you don't *need* Agile to do that, either. You just have to pay attention to the problem. Like everything else. -- https://mail.python.org/mailman/listinfo/python-list
