In fundamental science, one starts from a bunch of phenomena, and then one tries to drill down to find out what’s underneath them—to try to find the root causes, the ultimate primitives, of what’s going on.

In science, if one does a good job at finding the primitives, then one can have a very broad theory that covers not just the phenomena one started from, but lots of others too.

And in software design, it’s the same kind of thing.

If one does a good job at finding the primitives, then one can build a very broad system that gives one not just the functionality one was first thinking about, but lots more too.

Then what do you design for? 95%? 99%? […]

Even 100% would not satisfy my goal of supporting creativity. I don’t design for preconceived use cases. I design a coherent world that captures the uses I can think of while being a simple/general as possible. (I measure simplicity in a particular way, by describing a precise math model.) The anticipated uses serve to give me hints about that world, rather than defining it.

If a design meets my expected uses and is very simple, then I’m confident about it handing my unanticipated needs as well. If it uses complexity (special cases) to address my expected uses, then I expect it will need more complexity thrown in to handle unexpected uses.

As Tony Hoare said in his Turing Award lecture,

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is make it so complicated that there are no obvious deficiencies.