Principles of good design
I’m still reading through the book Dreaming in Code. It’s taking longer than I had hoped, but sometimes it’s been a difficult read for me – not because it’s a bad book or bad writing, but because sometimes the author is describing something about software development of which I have enough personal knowledge that his pages of discussion become boring.
I suppose that’s what you get for reading a book about software development targetted at anybody but a software developer.
Anyway, recently I came across a passage about Mitch Kapor’s thoughts on software design, which was interesting because it gave me some ideas on how to better frame software design when communicating with both engineers and management. It also led me to reassess my own views on software design. 
It turns out that Kapor wrote about his thoughts on software design in a manifesto in 1990, including this idea of applying to software the architecture theorist Vitruvius’s principles of good design (Vitruvius is from Ancient Rome):
- Firmness, meaning "A program should not have any bugs that inhibit its function." aka, no bugs
- Commodity, meaning "A program should be suitable for the purposes of which it was intended."
- Delight, meaning "The experience of using the program should be a pleasurable one."
These three principles have been a backbone, so to speak, of building architecture for many, many years, and I think Kapor is (or was) onto something here in that these core architectural principles can and should be applied to software design. I don’t know if Kapor believed they applied to implementation or not.
Of course, I believe software design and implementation are the same activity at different levels of abstraction. A software architect designs algorithms at the system-level while your entry-level software engineer designs algorithms at the function level. An architect may use UML or a whiteboard as the design tool of choice, while the entry-level engineer uses code, but in the end the thought processes required are fundamentally the same.
When I think of these principles and view them in the context of the development I or my peers engage in I see that the best engineers are the ones who consider firmness, commodity, and delight at all levels of abstraction in design – from architecture to high-level design to subsystem implementation to function implementation.
So, I wonder, are truly great software designers the ones who know how to maintain that architectural integrity of design principles in the software? This isn’t an easy thing to do. It requires discipline. It requires the ability to see the big picture while diving into the weeds. It requires conceptual integrity in the design from start to end.
Yet, it makes sense. The best engineers are the ones who can see the big picture and work in the weeds. They are the ones who have the discipline to follow design principles from start to end and from architecture to code. They follow Vitruvius’s design principles not just from an architecture view, but even for each line of code.
It’s pure design integrity at every level of the software. It’s hard to do, but doing those things that are hard to do is what makes people great and it should be what everyone strives for.
Filed under: Design
