I like logical frameworks and structures. When I think about technical excellence, I can’t help but wonder: “What’s the intellectual basis for design? What does it mean to have a good design?”
Unfortunately, many discussions of “good” design focus on specific techniques. These discussions often involve assumptions that one particular technology is better than another, or that rich object-oriented domain models or stored procedures or service-oriented architectures are obviously good.
With so many conflicting points of view about what’s obviously good, only one thing is clear: good isn’t obvious.
Some folks describe good design as elegant or pretty. They say that it has the Quality Without a Name (QWAN)—an ineffable sense of rightness in the design. The term comes from Christopher Alexander,a building architect whose thoughts on patterns inspired software’s patterns movement.
I have a lot of sympathy for QWAN. Good design is Truth and Beauty. There’s just one problem. My QWAN is not your QWAN. My Truth and Beauty is your Falsehood and Defilement. My beautiful domain models are uglier than your stored procedures, and vice versa.
QWAN is just too vague. I want a better definition of good design.
Let me digress for a moment: software doesn’t exist. OK, I exaggerate—but only slightly.
When you run a program, your computer loads a long series of magnetic fields from your hard drive and translates them into capacitances in RAM. Transistors in the CPU interpret those charges, sending the results out to peripherals such as your video card. More transistors in your monitor selectively allow light to shine through colored dots onto your screen.
Yet none of that is software. Software isn’t even ones and zeros; it’s magnets, electricity, and light. The only way to create software is to toggle electrical switches up and down—or to use existing software to create it for you.
You write software, though, don’t you?
Actually, you write a very detailed specification for a program that writes the software for you. This special program translates your specification into machine instructions, then directs the computer’s operating system to save those instructions as magnetic fields on the hard drive. Once they’re there, you can run your program, copy it, share it, or whatever.
You probably see the punchline coming. The specification is the source code. The program that translates the specification into software is the compiler. Jack Reeves explores the implications in his famous essay, “What is Software Design?”[61]