Some time ago, I had ranted about bloated systems and software. I have recently come across an IEEE Spectrum article titled Why Bloat Is Still Software’s Biggest Vulnerability – A 2024 plea for lean software, where the subtitle is a reference to N. Wirth’s 1995 paper A Plea for Lean Software.
The above IEEE Spectrum article is worth reading. The author approaches the bloat problem from a security perspective. He writes:
A typical app today is built on Electron JS, a framework that incorporates both Chromium (“Chrome”) and Node.JS, which provides access to tens of thousands of software packages for JavaScript. I estimate just using Electron JS entails at least 50 million lines of code if you include dependencies. Perhaps more. The app meanwhile likely pulls in hundreds or thousands of helper packages. Many packages used will also, by default, snitch on your users to advertisers and other data brokers. Dependencies pull in further dependencies, and exactly what gets included in the build can change on a daily basis, and no one really knows.
It’s this “dependencies pull in further dependencies” that’s worrisome, leading to software that no-one really fully understands.
Wirth wrote (emphasis mine):
The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.
But he also wrote (emphasis mine):
Time pressure is probably the foremost reason behind the emergence of bulky software. The time pressure that designers endure discourages careful planning. It also discourages improving acceptable solutions; instead, it encourages quickly conceived software additions and corrections. Time pressure gradually corrupts an engineer’s standard of quality and perfection. It has detrimental effects on people as well as products.
Remember that one?
If the above survey is of any indication of today’s reality in companies’ programming and operations shops, I don’t feel at ease about the future of our increasingly complex systems that touch, or even handle, so many aspects of our lives, directly or indirectly. We possibly should not even mainly blame the software developers responsible to put untested code into operation, if handcrafted or generated by a ChatGPT-like systems, but the time and cost pressure put on engineers by the companies. Good engineering takes thought and time.
I really don’t know how – or even if – we’ll get out of this deeply troubling situation. The above IEEE Spectrum article describes the increasing number of security breaches and problems, and the misguided incentives for companies and programmers.
Wirth again (emphasis mine):
Reducing complexity and size must be the goal in every step – in system specification, design, and in detailed programming. A programmer’s competence should be judged by the ability to find simple solutions, certainly not by productivity measured in “number of lines ejected per day.” Prolific programmers contribute to certain disaster.
The IEEE Spectrum article argues that simply the amount of code that gets pulled into a program, or feature thereof, via all its dependencies, increases the attack – or problem – surface. See the Electron app example cited above: it’s just not possible to test all that code thoroughly. Again and again, as hundreds of dependencies will be in flux all the time.
Add what counts as “artificial intelligence” these days, and the outlook becomes even grimmer.
For some time now, I have kept my devices and services as separated as possible, not taking “advantage” of all the integrations and automatisms available. Better do some legwork, eg. copy-and-paste of data, than wait for the next security breach or breakdown of iMessage.