Most engineering disciplines have physical laws that influence and constrain their respective design spaces.
Want to build a bridge? A good design balances function, durability, and safety, while also considering cost and environmental impact. And you’d better take gravity, tension, compression, torsion, and shear into account. Or else.
Want to build a skyscraper? A good skyscraper design is characterized by its structural stability, functionality, and sustainability. And you should think hard about gravity, wind, seismic forces, and thermal forces. Or else.
Each field’s physical laws are an important part of that field’s design process. They are a natural starting point for any design, create a firm set of criteria for whether or not each design meets its requirements, and even allow for different designs to be compared quantitatively.
And it doesn’t matter whether you agree or disagree with physics. Physics doesn’t care. Physics wins. Every time. So there’s not much room for debate on how these designs are evaluated, at least functionally. Bridge designers agree that bridges shouldn’t fall down. Skyscraper designers agree that skyscrapers shouldn’t fall over.
Software engineering, on the other hand, has no such physical laws. Software is ultimately just an abstract process, albeit a potentially very complicated one, so physical concepts like gravity and mass and momentum simply don’t apply.
But if there are no laws, where does a design even start, let alone a good design?
On the one hand, this lack of universal laws is freeing. Ignoring problems that are actually impossible, you can build just about anything you can imagine with software. Want to build a game where you’re a plumber that eats mushrooms to grow bigger and stomps on turtles to save a princess? Sounds like fun. Good luck building that in the real world!
But that flexibility has a price. If there are no physical laws to contend with, no up or down, then what is a good design? For bridges, it shouldn’t fall down. For skyscrapers, they shouldn’t fall over. But what about for software? Maybe good software should...
These "physical laws" -- perhaps better called "universal laws” in the context of software design -- are poorly defined at best. And this is only a few examples. But no matter how many examples are given, there will always be those who say there are too many, or too few. And no matter how they are defined, there will always be those who say the definition is wrong. Since there are no “real” universal laws to arbitrate the disagreement, who is right, and who is wrong?
In essence, the field of software design presents a unique paradigm unlike any other form of engineering. Free from the physical constraints that dictate the creation of bridges or skyscrapers, software design operates under principles that are inherently flexible and subjective. This lack of universal laws is both liberating and challenging; it allows developers to innovate without limits, but also leads to ongoing debates about what constitutes "good" design.
Fortunately, many smart people have been working on this problem, directly and indirectly, for a long time. In this blog series, I will revisit this idea of what defines "good design" in software, and how you and your team can use these ideas to improve your own designs.
