A 2024 Plea for Lean Software (with running code) - Bert Hubert's writings

Skip to Main Menu

This post is dedicated to the memory of Niklaus Wirth, a computing pioneer who passed away January 1st. In 1995 he wrote an influential article called “A Plea for Lean Software”, and in what follows, I try to make the same case nearly 30 years later, updated for today’s computing horrors.

The really short version: the way we build/ship software these days is mostly ridiculous, leading to 350MB packages that draw graphs, and simple products importing 1600 dependencies of unknown provenance. Software security is dire, which is a function both of the quality of the code and the sheer amount of it. Many of us know the current situation is untenable. Many programmers (and their management) sadly haven’t ever experienced anything else. And for the rest of us, we rarely get the time to do a better job.

In this post I briefly go over the terrible state of software security, and then spend some time on why it is so bad. I also mention some regulatory/legislative things going on that we might use to make software quality a priority again. Finally, I talk about an actual useful piece of software I wrote as a reality check of the idea that one can still make minimal and simple yet modern software.

I hope that this post provides some mental and moral support for suffering programmers and technologists who want to improve things. It is not just you, we are not merely suffering from nostalgia: software really is very weird today .

The state of software

Without going all ‘old man (48) yells at cloud’, let me restate some obvious things. The state of software is DIRE. If we only look at the past year, if you ran industry standard software like Ivanti, MoveIT, Outlook, Confluence, Barracuda Email Security Gateway, Citrix NetScaler ADC and NetScaler Gateway, chances are you got hacked. Even companies with near infinite resources (like Apple and Google) made trivial “worst practice” security mistakes which put their customers in danger. Yet we continue to rely on all these products.

Software is now (rightfully) considered so dangerous that we tell everyone not to run it themselves. Instead, you are supposed to leave that to an “as a service” provider, or perhaps to “the cloud”. Compare this to a hypothetical situation where cars are so likely to catch fire that the advice is not to drive a car yourself, but to leave that to professionals who are always accompanied by professional firefighters.

The assumption is then that “the cloud” is somehow able to turn insecure software into a secure service. Yet even the past year, we’ve learned that Microsoft’s email platform was thoroughly hacked, down to classified government email (update: it happened again!). There are also well-founded worries about the security of the Azure cloud. Meanwhile, industry darling Okta, which provides LOG IN SOLUTIONS got comprehensively owned. This was their second breach within a year. Also, there was a suspicious spate of Okta users getting hacked subsequently.

Clearly we need better software.

The EU has launched three pieces of legislation to this extent (NIS2 for important services, the Cyber Resilience Act for almost all commercial software and things with plugs, a revamped Product Liability Directive that extends to software). Legislation is always hard, and it remains to be seen if they got it right. But that software security is terrible enough these days to warrant legislation seems obvious.

Why software is so bad

I briefly want to touch on incentives. The situation today is clearly working well for commercial operators. Making more secure software takes time and is a lot of work, and the current security incidents all don’t appear to be impacting the bottom line or stock prices. You can speed up time to market by cutting corners. So from an economic standpoint, what we see is what you would expect. Legislation could be very important in changing this equation.

The security of software depends on two factors - the density of security issues in the source code, and the sheer amount of exposed code . As the US defense community loved to point out in the 1980s, quantity has a quality all of its own. The reverse applies to software - the more you have of it, the more risks you run.

As a case in point, Apple iPhone users got repeatedly hacked over many years because of the huge attack surface exposed by iMessage. It is possible to send an unsolicited iMessage to an Apple user, and the phone will then immediately process that message so it can preview it. The problem is that Apple in its wisdom decided that such unsolicited messages needed to support a vast array of image formats, accidentally including PDFs, including PDFs with weird embedded compressed fonts using an ancient format that effectively included a programming language.

In this...