Technical Debt: Nope, It Exists and That Debt Means Operational Poverty, Then Death
August 28, 2020
“Technical Debt Doesn’t Exist” is an interesting view of software. The problem is that “technology” is not just software. The weird behavior of an Adobe application like Framemaker can be traced to the program’s Unix roots. But why, one asks, is it so darned difficult to manage colors in a program intended to print documents with some parts in color? What about the mysterious behavior of Windows 10 when a legal installation collects $0.99 cents for an HEVC codec only to report that the codec cannot be installed? What about the enterprise application from OpenText cannot display a document recently displayed to the user of the content management system? Are these problems due to careless programming?
According to the article:
There is no such thing as technical debt. There is work to do, that we can agree on, but it’s not debt payment.
The punch line for the write up is that technical debt is just maintenance.
Let’s think about this.
The constraints of Framemaker result from its Unix roots. Now decades later, those roots still exist. Like the original i2 Analyst’s Notebook (a policeware system), some functions were constrained by the lovely interaction of the hardware, the operating system, and the code. The Unix touches remain today: Enter Escape O P C and the list of styles pop up. Yep, commands from 40 years ago are still working and remain inscrutable to anyone trying to learn the program. Why aren’t there changes? Adobe tried and ended up with InDesign. I would suggest that the cost of “fixing up” Framemaker were too high if Adobe could corral engineers who could do the job. Framemaker, therefore, is still around, but it is an orphan and a problematic one at that.
What about Microsoft and a codec? The fact that Microsoft makes a free version available for a person willing to put in the time to locate the HEVC download is one thing. Charging $0.99 for a codec which cannot be installed is another. Figuring out the unknown and unanticipated interactions among video hardware, software in the Windows 10 fun house, and third-party software is too expensive. What’s the fix? Ignore the problem. Put out some marketing baloney and tell the human doing customer support to advise the person with the failed codec to reinstall Windows. Yeah, right. A problem exists that will be around for exactly as long as there is Windows 10.
What about the OpenText content management system? We encountered this problem when trying to figure out why users of the system could not locate a file which had been saved the previous day. We poked around the hardware; we poked around the content management system; we poked around the search system which turned out to be an Autonomy stub. Yep, Autonomy search was “in” the OpenText system. The issue was the interaction of the Autonomy search system first crafted in the late 1990s, the content management system which OpenText bought from a vendor, and the hardware used to run the system. Did OpenText care? Nope, not at all. Open a file and wait 15 minutes. And what about the missing file? Updates sat in a queue and usually took place a couple of days after the Save command was issued. The fix? Ho ho ho.
Let me be clear: When a system is coded and it sort of works, that system is deployed. If a problem surfaces quickly, the vendor will have someone fix it. If it is a big problem, maybe two or three people will work on the issue. Whatever must be done to get the phone to stop ringing, the email to stop arriving, and angry customers to stop having their lawyers write nasty grams will be done. Then it is over. No one will go back and figure out what went wrong, make fixes, and dutifully put the ship in proper shape. The mistake is embedded in digital amber and the “fix” is part of the woodwork. How often do you look at the plumbing connections from the outside water line to your hot water heater. What happens when there’s a leak? A fix is made and then forget it.
What about technical debt? The behaviors I have described mean that systems persist through time. The systems are not refactored or “fixed”. The systems are just patched. Amazon enshrines this process in its two pizza teams. And how about the documentation for the fixes made on Saturday morning at 3 am? Ho ho ho.
Let me offer some observations:
- Significant changes to software today are mostly cosmetic, what I call wrappers. The problems remain but their pointy parts are blunted.
- The cost of making fundamental changes are beyond the reach of even the largest and most resource rich organizations.
- The humans required to figure out where the problem is and make structural changes are almost impossible for most technologies.
The article calls this maintenance. I think that’s an okay word, but the reality is that today’s software, particular software based on recycled libraries, existing systems accessed via application programming interfaces, and hardware with components with checkered or unknown pasts are not going to be “fixed.”
We live in an era of “good enough.”
The technical debt is going to catch up to those who sell and develop products. Users are already paying the price.
What happens if one pushes technical debt into tomorrow or next week?
That’s an easy question to answer. The vaunted “user experience” becomes more like a carnival act while the behind the scenes activity is less and less savory. How about those mandatory updates which delete photos, kill a Mac desktop, or allow a mobile phone to go dead because of a bug? The new normal.
It’s just maintenance. We know how much bean counters like to allocate cash for maintenance. Operational poverty, then the death of innovation.
Stephen E Arnold, August 28, 2020
Comments
-
- Subscribe to Beyond Search
Feature archive
News archive
-
