…and do it well. That’s the underlying philosophy of Unix. Most of the basic Unix commands either have output ready formatted to pipe into the standard input of another command or have options to remove the human-friendly parts of their output. The individual component parts do their jobs efficiently, and you can re-jig them in a variety of ways if you need to. We prize modularity like this in software design, so why does it escape our notice in application specifications?
There is a philosophy of software development that I thought we had successfully knocked on the head back in the late 1990s but which keeps popping back up. It’s the philosophy of the monolithic program, the monster that does everything. The idea of the monolith goes way back before personal computing was a thing. I’m going to start by considering EMACS, the text editor evolved by Guy Steel and Richard Stallman in the 1960s and still going strong. It didn’t start out as a monolith — none of them do — or even intending to be one. It was simply (!) a revolutionary change in that it made editing programs a WYSIWYG experience. Since it evolved from a collection of macros, it made sense for it to be extensible and for features to be added to assist with writing in different programming languages, resource files and what have you.
EMACS’ monolithic tendencies didn’t really start until people became dissatisfied with the edit-compile-run loop as they had to use it. When you had a single terminal (no graphics) that could run a single program, quitting EMACS to run the compiler and having to restart it and find your place again was a serious pain. Pausing it to access the terminal command line wasn’t much better. Obviously it was more convenient to provide a command line within EMACS that you could run other programs from (Shell mode and its relatives as it now is), or editor commands to invoke compilation tools (sending it down the IDE path two decades ahead of Visual Studio), or both (because you could). Since at this point your humble editor is essentially pretending to be the operating system you might as well throw in direct control of printing files and so on.
Behold, the monolith. We jokingly decoded the acronym as “Eight Megabytes And Constantly Swapping” back in the days when 8Mb of RAM was pushing it for what a process could reasonably expect to get its hands on. It all works perfectly well, if rather flabbily, until OS drivers change. Or, in EMACS’ case, it had to cope with multiple operating systems with deeply incompatible approaches to all the things EMACS was doing over and above its actual job. At this point it becomes a maintenance nightmare, and sensible people back away from the cliff. Much as I love it, EMACS still does an enormous number of things that have no direct bearing on text editing, and they don’t always port well (or at all) and can be finicky. Fortunately you can ignore almost everything that isn’t involved with what you actually need; I will never want to use EMACS’ window manager or mailer, for instance, but their existence doesn’t intrude on my editing experience.
Convenience and control becoming inconvenience and a battle for control. Remember that.
Moving into the personal computing era, things were stable and equitable for a good long while. Microsoft, much as I enjoy decrying them, had the right idea in the Office suite of letting the appropriate application deal with any given object; a spreadsheet displayed in a Word document is actually edited by Excel code, and so on. Not that there weren’t monolithic tendencies around; Word blurred the distinction between word processing and desktop publishing in a way that still helps no one, and Outlook grew calendar management, for instance. And just like EMACS, additional facilities grew for this, that or the other special feature, to the detriment of the girth and response time of individual applications.
And then someone had the brilliant idea of Web 2.0, of dynamic content being downloaded to run in your browser and make web sites more exciting, and overnight browsers started becoming monoliths.
Oh boy.
It’s sometimes hard to convince people that you didn’t used to have to enable Javascript in order to view most websites, and that indeed the security advice was that you shouldn’t enable JavaScript if you could help it. As the sort of old curmudgeon who wants information from the Internet rather than something pretty, I ended up with a long blacklist of sites I didn’t bother visiting any more because they didn’t supply me with that information unless I enabled Javascript. The thought of browsers, whose sandboxing I knew to be inadequate, usurping the privileges of the operating system to run anything you downloaded was downright terrifying.
The anti-trust action against Microsoft back in 2001 ended up enforcing the separation of browser and OS, essentially requiring everyone to think a lot more carefully about implementations, APIs and exactly what facilities were needed. Browsers still have a habit of trying to be all things to all people, and to a limited extent they succeed, but now they are the “eight gigabytes and constantly swapping” applications. I’m writing this article in a google doc, and just out of interest I fired up LibreOffice Writer to compare the usage stats on my machine. Once the initial load was out of the way, Writer didn’t register in the “top” command’s usage reports. Firefox, however, was consistently at or near the top of the CPU usage list, even when the browser didn’t have focus and I wasn’t typing anything.
The newest generation of monoliths is now on us, wanting to control your computer so that they and they alone can provide you with everything you don’t need. It’s very sad in a lot of ways; some excellent applications have been ruined by overexpansion. I understand the impulse; being an application that works reliably isn’t sexy, you need this feature and that feature and the other vague promise of a feature to succeed in this world where people allegedly have the attention span of a gnat. When that happens at the expense of actually working reliably, it is unacceptable in my book. The chat application that we use internally (no names, no pack drill) has grown videoconferencing, documents, and the ability to run apps inside itself much like a browser (by no coincidence at all). It’s a terrible video system, we didn’t need yet another version of electronic scrap paper, and personally I’d rather not encumber my applications with yet another compatibility layer. The underlying chat system has not got better for this, is less responsive and nearly got uninstalled the week it crashed my computer several times. And it eats system resources like Pacman eats dots.
There are many other examples, such as the video conferencing systems that have acquired whiteboards, project managements systems and who knows what else to the detriment of actually serving video; the everything that has acquired AI assistants, only some of which offer more than well-written documentation or a simple search function would have; or the email systems that want to be able to handle every form of attachment they could conceivably be sent by themselves. They all bloat and suffer, and we suffer with them even as we exclaim at the shiny new features we don’t actually need.
This isn’t to say that you can’t add new features to old programs, but you should think about why you are doing it. Syntax colouring was once a brand new idea for programmers’ editors, and chewed up quite a bit of resources parsing your file, but it’s hard to imagine doing without it now. People still write new packages for Emacs that add to its usefulness, and it’s far from the only application like that. AI I’m a little more cautious of precisely because it is such a marketing buzzword at the moment, and there’s an awful temptation to add AI to a product purely to add a shiny “powered by AI” sticker to it without considering exactly what it’s going to add. There are some very good uses of AIs out there, but also some very poorly thought out ones; something like Claude is an amazing aid to understanding and debugging large code bases, but is total overkill for when I’m quickly looking over a short script I wrote last month to remind myself what it does. Heck, even running up Emacs is overkill for some of those scripts!
Regardless, the old proverb is still true. The jack of all trades is the master of none. Some of the monolithic jacks used to be masters, but that mastery inevitably suffers as they spread. I suppose that as these applications decay through the sheer amount of maintenance effort they take, they do leave holes in the ecosystem for some bright new spark to write a new version of the original application that actually does the job it was designed for well again.
I keep circling back to the maxim I started this article with. Do one thing, and do it well. The alternative is doing many things at best mediocrely, and that’s just sad.