The future will always be stuffed with software breakdowns
2 May 2024 — As most men my age, I did my military service. Mine was in the U.S. Marine Corps, and the Corps certainly followed Friedrich Nietzsche’s credo: that which does not kill you makes you stronger.
During the basic training field exercises, a recurring task was setting-up our tent for the night – but the tents got larger and more complex on each subsequent field trip. And the timing was made so the weather would not be cooperative: vicious rain, howling winds. Often the tent pegs pulled out in the wind, or the center tent poles broke. Their size made them unwieldy, impossible to control, even with a team.
There we stood, in the driving rain, a collapsed tent before us, as our commander (doing his best impersonation of Lou Gossett Jr. in “An Officer and Gentlemen“) gleefully reamed us out.
I thought about the tent pole failures, and those miserable (but somewhat rewarding) field experiences as I read “Laws of Software Evolution“. The write-up sets forth some ideas which may not be firm guidelines like those articulated by the World Court – but they are about as enforceable.
Let’s look at the laws explicated in the essay.
The first law is that software is to support a real-world task. As result (a corollary maybe?) is that the software has to evolve. This is that old chestnut “No man ever steps in the same river twice, for it’s not the same river and he’s not the same man“. The problem is change, which consumes money and time. As a result, original software is wrapped, and peppered with calls to snappy new modules designed to fix up or extend the original software.
The second law is that when changes are made, the software construct becomes more complex. Complexity is what humans do. A true master makes certain processes simple. Good software has artists, poets, and engineers with vision. A rarity. Simple may not be a key component of the world the programmer wants to create. Thus, increasing complexity creates surprises like unknown dependencies, sluggish performance, and a giant black hole of costs and security and entropy problems.
The third law is not explicitly called out like Laws #1 and #2. But it is there. Here’s my interpretation of the “lurking law,” as I have termed it:
• Code can be shaped – and will be built upon
My reaction to this essay is positive in what it attempts to explain – but the link to evolution eludes me. The one issue I want to raise is that once software is built, deployed, and fiddled with it is like those Marine tents I described above. Or better yet, if you have ever taken an engineering course, those river piers built by Ancient Roman engineers. Moving those piers or fixing them or attempts to make them bigger (which the Romans did) was a very, very difficult task. At some point, even the incredibly resilient Roman concrete weathered away. The bridge or structure fell down. Gravity always wins.
So I am more okay with the concept of software devolution. The future, therefore, will be stuffed with software breakdowns. The essay makes a logical statement:
• we should embrace the malleability of code and avoid redesign processes at all costs!
Sorry. Won’t happen. Woulda, shoulda, and coulda cannot do the job.
My best example is Microsoft. One of its biggest problems it that it just kept building on its legacy hardware/software, its “new” software applications simply built for old hardware and outdated operating systems, build upon defective software. This just rendered huge compatibility issues and massive cybersecurity issues – its capacities just blown out of the water.
Side note: two colleagues who have detailed the Microsoft issues at great length are Steve King and Andy Jenkinson. I urge you to follow them in all matters of cybersecurity and software development.
But I even see it in more simple, primitive software such as that used in litigation eDiscovery.
I own a company that provides attorneys for short-term projects in litigations and government investigations, all utilizing eDiscovery software. Every week these attorneys send me notices on software failures which I forward to the respective software companies.
We are long past the day when Nikola Tesla invented the first “litigation search technology” (the first use of keyword search in legal discovery). Tesla’s continual legal battles with Thomas Edison led him to recognize the importance of tangible evidence in court. By 1938, lots of information was being transmitted electronically and recorded electronically and Tesla noted “valuable evidence that could be used in court was being lost and should be preserved”, so he invented a primitive form of eDiscovery for selecting, capturing and storing evidence for later use in court.
My legaltech readers all know how crucial that technology would become to the process of legal discovery. But the development of complicated data filtering, attempts at “intuitive” search tools, complex search parameters, etc. all led to … entropy.
The future will always be stuffed with software breakdowns. C’est la vie.