One of the most eye-opening and influential ideas in my journey as a programmer was the concept of ‘conceptual integrity’, introduced by Fred Brooks in The Mythical Man-Month in his essay Aristocracy, Democracy, and System Design.
It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas
Fred Brooks
In a nutshell, conceptual integrity consists of a set of well-related, composable concepts and the relationships between them, forming a kind of conceptual algebra.
When we introduce a new concept that doesn’t integrate well with the others, the conceptual algebra suffers in the form of increased complexity. Special or exceptional cases must be considered, which limits the expressiveness of the algebra and raises the cognitive load for those who have to play with it. Just one poorly selected concept affects the whole.
In a way, what Brooks is suggesting is that design lives in the constraints we impose on the material we work with. This is especially true in software development.
Unlike other forms of human craftsmanship, software has more flexible constraints. For example, when building a bridge, we encounter hard limits imposed by factors like gravity, wind, vibrations, and material strength — all of which must be calculated and accounted for before construction even begins.
Software is, by nature, a very malleable creature, with its hard limits mostly imposed by hardware: the computing power, the volatile and persistent storage, and the capacity of the network connection1.
Another point where the analogy between building software and building things in the physical world is also broken is at how those different creations handle the pass of time and the changes, and the expectations we have about that.
For the things built in the physical world, in general, we expect that those things would be more or less durable and maintain their original characteristics until we finish to used them. No one expects that a bridge automatically gets wider because the traffic that passes over it increases substantially or shrinks when the traffic decreases. That is exactly what we expect from software, we want it to change and adapt automatically. Designing software to show resilience to changes over time is apparently an important feature to consider.
If we build software like we build bridges, we end up with a piece of software very hard to change and doomed to be maintained until someone with the authority (but probably without the knowledge) decides to destroy it and build it again. Any resemblance with reality is purely coincidental.
Designing by Subtraction
Subtracting the superfluous to reveal the essence, or the soul, of a creation is a well-known process in arts.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Saint-Exupéry
Another phrase, attributed to a multi-talented artist primarily known as a sculptor, captures this idea pragmatically.
“I saw the angel in the marble and carved until I set him free.”
Michelangelo Buonarroti
I think that we can follow a similar process for software. While the static nature of sculpture might not be a good analogy for a running program, the idea of revealing a design that’s already present in the problem domain sounds like a good guideline to me. The attitude of unveiling a design instead of trying to impose one on the problem should distance us from the root of all evils in programming.
Premature optimization is the root of all evil (or at least most of it) in programming.
Donald Knuth
To achieve that in software, we should model the problem at hand in a way that no artificial complexity is added to the solution model. Much like a sculptor carving away marble to reveal the form within, we should aim to reduce artificial complexity to a minimum during iterations in software design, refining our solution until the true essence of the problem we’re addressing is revealed.
The Problem of Computing Things
Listing the OrderedCollection class selectors in the accessing category.
Debuggers, inspectors, explorers, and browsers in Smalltalk are built with the language itself, utilizing its extensive reflexivity and metaprogramming capabilities.
Exploring a text editor
Every component accessible to the user should be able to present itself in a meaningful way for observation and manipulation.
Dan Ingalls in Design Principles Behind Smalltalk
What is even more surprising is that this remarkable level of reflectivity and metaprogramming occurs in an open and live object environment. Open means that all the objects constituting the base system are accessible for our inspection and modification; our code operates on the same level as the base system. Live means that we can program, inspect, and modify while the objects are running, freeing us from the conventional edit-compile-run-stop loop.
Smalltalk people call that the meta-system9. The meta-system empowers users to understand and modify the system itself, turning users into creators. Kay envisioned meta-systems as tools to encourage users to not just work with data but to reshape their tools and frameworks as they go. In this view, the user isn’t just operating within a closed system but actively extends, refines, and redefines the system’s boundaries.
“I think one of the things we liked the most about Smalltalk was not what it could do, but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building.”
Alan Kay at OOPSLA 1997
Final Words
Smalltalk is to me one great example of what we can achieve in system building if we actively follow the concept of conceptual integrity.
As we’ve seen, Smalltalk is more than just a programming language — it’s an entire interactive programming environment, grounded in a small, interwoven set of concepts applied recursively across both language and system levels. Even more, Smalltalk offers a unique approach to thinking about computation itself. Its metaphor, everything is an object, is applied uniformly across all areas, reinforcing a powerful and cohesive model of computation.
Smalltalk, as designed by Alan Kay and his team10, aimed to deliver this level of integrity by building a cohesive environment where all components, from the language syntax to the user interface, consistently reflect the object-oriented paradigm.
By conception, Smalltalk is a tool meant to release the creativity of those who use it, a standpoint for bringing the next big set of ideas about system building. In the words of Alan Kay himself:
[Smalltalk is] an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk.
Alan Kay at OOPSLA 1997
Licensed under
SOCIAL SHARE CARD GENERATOR