I love what Steve Yegge says here about designing great software. Here’s an excerpt (edited for brevity):
I think the most important principle in all of software design is this: Systems should never reboot.
If you design a system so that it never needs to reboot, then you will eventually, even if it’s by a very roundabout path, arrive at a system that will live forever.
I think the second most important design principle, really a corollary to the first, is that systems must be able to grow without rebooting.
Essential Features
Here are some of the properties shared by the best software systems in the world today.
First: every great system has a command shell. It is always an integral part of the system. It’s been there since the system was born. All existing command shells are crap, but they are an essential component of building the best software that can be built today.
Great systems also have advice. There’s no universally accepted name for this feature. Sometimes it’s called hooks, or filters, or aspect-oriented programming. Advice is a mini-framework that provides before, around, and after hooks by which you can programmatically modify the behavior of some action or function call in the system.
Moving right along, world-class software systems always have an extension language and a plug-in system — a way for programmers to extend the base functionality of the application. Sometimes plugins are called “mods”. It’s a way for your users to grow the system in ways the designer didn’t anticipate.
What other features do great software systems have?
I think one important element, at least today, is that they either have to be a killer app, or they need one. Every world-class software system is, by its very nature, a platform. If you have a command-shell, and an extension language with advice, and a plug-in architecture, then you’ve already got the makings of a platform. But you need to give users some reason for using it in the first place.
So software systems need a niche. Someday there may be a generic software system so powerful and well-designed that it’s the best system to use for literally everything. Maybe you’ll be the one to build it.
The last big feature I’ll enumerate today, and it’s just as important as the rest, is that great software systems are introspective. You can poke around and examine them at runtime, and ideally they poke around and examine themselves as well. At the very least they should have some basic health monitoring in place.
This is something we can work with. In no small way, Steve is talking about what it takes to bring software marionettes to life, to actually pull off the Pinocchio miracle in software.
Steve also slips in this gem, right in the middle of the article:
Note: most of these are features for programmers. Features for non-technical end-users don’t contribute to a system’s lifespan. In the fullness of time, I believe programming fluency will become as ubiquitous as literacy, so it won’t matter.
For those of you who haven’t caught this meme, it echoes Ken Perlin‘s Procedural Literacy advocacy (also discussed at GrandTextAuto, with props to A. J. Perlis‘ 1961 advocacy of the same idea). This concept is overdue for broader support.
Today we realize that nearly ubiquitous written-word literacy has changed the world in profound ways, touching nearly every aspect of the first world.
It is not so far fetched to imagine a world where widespread procedural literacy reshapes how we interact with the world around us, how we craft our communications with others, and indeed how we structure the systems that govern our society. That’s exactly what written-word literacy did, after all. Where would we be without public laws, books, street signs, public notices, newspapers, research publications, email, or the web? (Just to name a few high-value uses of modern written-word literacy.)
If everyone (or almost everyone) knew how to script their personal widgets to process and present openly available data streams, every individual would be an empowered knowledge worker in the truest sense, creating what they want, how they want it, when they want it, and fully able to pipe that value back into the rest of the community for even greater leverage.
Consider the introduction from Ken’s Polly experiment:
Some of us want to start an on-line world that kids can build, with creatures they can grow and play with together. But the kids will need to learn how to program to do really cool things. The (not so secret) agenda is for our society to achieve near-universal literacy in programming, sooner rather than later. After all, society once thought near-universal written literacy to be impossible, even nuts. That was back when “literacy” involved a small elite memorizing texts in a sacred language. In that context, people couldn’t see why you’d want everyone to read and write. We know better now.
Getting little kids to see the potential social relevance of programming is a first step, kind of a “Cat in the Hat” level. We also need to eventually extend to the “The role of the Female Protagonist; Shakespeare versus Virginia Wolfe” level, but first things first.
Here’s how Ken put it at the Academic Summit of the Game Developers Conference in 2003 (as reported by jane at GameGirlAdvance) :
Citizens who can make things, he said, would understand that they can affect the world; if we institute programming languages as part of the general education of all, we will be helping to guide a revolution in the way people think and act. Imagine if a child knew how procedural thinking worked – imagine if programming became like writing, like literacy, not a technical skill learned by engineers, but a fundamental language of self-expression naturally used by writers, artists, musicians, anyone. Way beyond open source, it was a manifesto for democratizing access to cultural participation at the most basic level.
In many ways, this is exactly what Steve is talking about, from the other side of the same coin. We need programs that have a clear, compelling purpose and support user-driven evolution. At the same time, we need users who can drive that evolution. Truly great software both empowers procedural literacy and depends on it.
We can see that today in some of the programs Steve highlights. My favorite in the list is Excel, which, as I mentioned in a previous post on User Programmers, puts fairly extensive programmability into the hands of average users. It has become the defacto knowledge worker tool in the corporate office, the accepted platform for collating, coordinating, analyzing, and presenting all kinds of business data. It has also trained a generation of managers how to think about numbers and algorithms.
We can also see this dynamic in comparing the efforts of microformats and RDF (or other formal semantic web technologies). Both systems are helping to bring semantic clarity to the world wide web, which should create a huge boost for machine-based automated services.
However, RDF is essentially written for machine-to-machine communication. Large systems are generally required before you have the economy of scale to invest in it. Microformats, in contrast, is written for people first and machines second, precisely because so much of the web is authored by individuals. That ocean of human-authored content would be more useful if it were semantically presented, and microformats makes that easy to do. By allowing regular web developers to write semantic html using a shared set of terminology, microformats significantly extends the procedural literacy that has already enabled so many average folks to build their own web pages. That’s what makes it so powerful.
So, if you are working on software today, ask yourself how you measure up against those features. Asking that simple question may result in better software, better users, and a better future.
Thanks, Steve.
