I have to wonder if this is a bit like what happens when something like Windows offers you an upgrade if you pay for it. Some people have noticed how after such things come out, a series of rapid bug fixes come along. So, they wait. Some wait long enough until another entire version has come along or even several such cycles. They then try to jump from say version 2.1 to version 5.0 and skip paying for all the in-betweens. Others may wait till something forces them to change like receiving documents their version of EXCEL cannot handle properly or at all. And, when that happens, they may simply jump to a different product entirely, like leaving Lotus for EXCEL.
And, as noted, some simply move on. All kinds of calendar programs and contact list managers can become obsolete when it is all bundled into something like Microsoft office Outlook. At some point, you toss the old or use some tool to migrate your data, or start over. With your own software a migration can be hairy and especially when the original staff are long gone or promoted and the manager has no clue and no budget for this. There seems to be substantial risk versus just leaving it alone and hoping it works long enough for you to get your bonus or move on. It is worse if the people maintaining it sort of made their own kludge variations like reinventing new features on their own in ways not compatible with the new. Do you port the kludge or switch over to the new way even if it means restructuring other parts of the code. A serious question. What has happened in other aspects of the field where a big enough change bifurcates the community? I am wondering what happened when PERL made incompatible changes. Are people still using both versions? What about largely discontinued languages that stopped being developed in any way and do not even have a compiler for newer machines? I know Microsoft periodically declares no further support for much earlier versions of Windows. I bet people who have old machines keep running without an upgrade, especially when their machine does not support the new version because it does not have enough memory or whatever. Why keep the old? I am sure they have their reasons that boil down to it runs programs they know well and that do what they need and do not add many bells and whistles that they don't think they need or that force them to change their ways. For some touch typists, the earlier word processors that do not know about a mouse and run in one big window, may be just right. But try sending one to others without using some conversion method first. But anyone teaching Python today who still uses version 2 exclusively may have some explaining to do unless the goal is to maintain and migrate those using it to version 3. Are there any serious new projects being built NOW using version 2? -----Original Message----- From: Python-list <python-list-bounces+avigross=verizon....@python.org> On Behalf Of Rhodri James Sent: Wednesday, February 12, 2020 8:16 AM To: python-list@python.org Subject: Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them) 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). > IMMEDIATELY, because you will not be given the time to do the job > completely in the first place, there will inevitably be bugs which are > minor enough to ignore indefinitely, and most likely, in order to meet > arbitrary-but-nevertheless-real time constraints you will find > yourself obliged to take shortcuts. 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. 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... -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
