Introduction
“A plea for lean software” (1995) is an influential paper by Niklas Wirth. I want to share my short, but modern point of view (POV) on this paper.
About the original paper
Certainly many aspects of the original paper are funny from the modern perspective.
Memory requirements of today’s workstations typically jump substantially—from several to many megabytes—whenever there’s a new software release. […] About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much!)
I am writing this text in an IDE which uses 475MB of my disk drive.
The modern user experience POV
Those arbitrarily overlapping windows suggested by the uncritically but widely adopted desktop metaphor; and fancy icons decorating the screen display, such as antique mailboxes and garbage cans that are further enhanced by the visible movement of selected items toward their ultimate destination.
It is fundamentally funny, that this aspect experienced little change. I consider the following considerations for this discussion relevant:
-
Aesthetics is subjective and importance of features depends on the target audience.
-
The platform (operating system, GUI toolkit, web standards) defines the generic capabilities of software. If software development sufficiently understands the abstraction, they can provide the appropriate interface between the technical device and the application software. Shall a web browser be able to handle the trash folder of the operating system? No, for security reasons. Shall a GUI toolkit be able to access hardware features of the graphics card? Yes, likely. The point of these questions is that many considerations go into decisions, what shall be possible in software. The more powerful the system is, the more complex it becomes. This will lead to a hunt for features, many users won’t care about. This the effect Wirth describes in my opinion. If we don’t understand the constraints and consequences, software development should not expose functionality externally. This ensures complexity has limits. Web browsers should not provide unlimited access to the filesystem to a website. GUI toolkits must be able to use graphics card features for improved performance. Assuming you understand the abstraction, you can design a beautiful interface which integrates well into the remaining system. This allows you to reach for the principle of least astonishment when it comes to end user exposure.
-
I think these days we better understand that user tests are important. Sketch your GUI on paper and ask a novice to use it (you can act as computer and swap papers to achieve interactivity). Ask novices to read your README file and let them explain your software to you. In smaller software bundles, it might just be a good idea to save one final week before release for testing on actual users.
-
If there are no surface-level changes to the software, software companies still add awkward UI changes to provide some recognizable changes with a new release. Improved UX is rarely the goal of these changes. Instead marketing requires mentionable features for the next release. This drives incomes and the perception how actively developed a software is.
-
There is still no unified way to give feedback back to the developers, but the situation improved. FOSS (free open-source software) can often be found on github and its issue tracker can serve for feedback. For commercial software, questions like “How was your call?” - with different emojis for rating - got more common. In the end, if you think fancy icons shall not be part of the software, you should have means to complain.
In total, I think we understand UX better these days, but implementation is still lacking.
The modern software requirements engineering POV
Requirements engineering is IMHO the common source, why software cannot be built as Wirth imagined. I will give some examples:
-
In a terminal, ANSI escape sequences specify the way how colors are encoded. However, what might work on one Linux & terminal emulator combination, might not work on another combination. There is even more risk, if you switch to Windows.
-
Several programming languages speak of strings as datatype. But which input is accepted for a string? Is any Unicode content a string (python, Java)? Is an arbitrary byte sequence a string (Lua, golang)? Is only UTF-8 content a string (rust)?
-
Your company only ships a deprecated software package to your clients. You are supposed to use the package (as dependency) for your own software implementation. But you know that some clients already have the updated package and soon most clients are going to use it as well. If you develop your software implementation, are you going to write two implementations for two dependencies or do you write one common one?
The common answer to these questions is abstraction. We try to provide one interface which can achieve the same behavior independent of the underlying technical details. How does this relate to the paper?
Abstraction drives complexity. Every interface needs implementation for the various target settings. This increases the software’s size. In the end, size is a serious goal, but abstraction for technical details is usually more important. This holds true for encoding of file system entries, ANSI escape sequences, logging mechanisms, error representation, and output of test suites. But can we avoid it? Simply put, standardization would achieve that no abstraction is needed. But sadly standardization is lacking in so many situations. As a result, I certainly rate nice abstractions higher than size as measurement of software quality.
The modern software development POV
Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration.
Indeed, complexity is a problem. I see increasing problems in technological decision making.
-
One example is the current trend for AI. Why does a neural network decide in favor of one choice in a binary decision? Why is a decision tree built the way it is built? Neural networks cannot (yet?) sufficiently express decision making reasons. It is just a bunch of numbers (“weights”) evaluated arithmetically. But AI tools get increasingly integrated into our software stacks.
-
It is a good thing to see the many advancements in the field of IT security. However, implementations for multi-factor authentication are rolled out without appropriately integrating users into the decision-making process. The end users are forced to follow complex security practices completely inadequate for their own (sometimes just fine and secure) workflows.
Overall, I conclude that policy making has a stronger effect on these decisions than learnings in software development. Can we limit complexity? When it comes to software development, the goal must be use reduce the amount of source code, the amount of dependencies, reject too complex requirements, and spend time on reviewing legacy source code. The goal must be to break software into small individual components with well-defined interfaces as Wirth proposed.
The modern software management POV
“Precisely defining the right decomposition is difficult and can rarely be achieved without iterations. Iterative (tuning) improvements are of course only possible up to the time of system release.”
In order to achieve this decomposition one has to revise and study software components. This takes time and reiterating designs and architectures should be desirable for every developer of software. I hope every software developer is aware of his/her responsibility.
Conclusion
Software requirements certainly changed over time. Size is not a major concern anymore due to the growth of storage devices. Complexity, standardization, and organization of software are still a big deal though.
Thank you, Wirth!