Importance of Conceptual Integrity in System Design (opens in new tab)

However, I really think that the immediate examples given by the author are actually not great examples of conceptual integrity, because the author too quickly conflates "conceptual integrity" with "consistency" (note the repeated use of "everything is a" in the examples given):

  Smalltalk ("everything is an object", and the small set of other accompanying principles)
  SQL ("all data is in tables", with keys and constraints)
  Lisp ("everything is a list")

I would even go as far to say that an over-emphasis on simplistic consistency speaks more to the lack of a genuine concept, or as the classic quote has it: "consistency is the last refuge of the unimaginative".

And committees love consistency because it's a cheap sell.

On the other hand, conceptual integrity just means staying true to the concept, however that is defined, so that conceptual integrity could well mean a break from simplistic consistency where the concept demands it.

If I can give it a shot, I would say that the human body is a better example of conceptual integrity in system design: not everything is a head or a hand, not everything is a foot or a finger, not all fingers are the same size, and yet everything works together. The conceptual integrity lies more in the overall symmetry of the human body, its purpose, its functions, its senses, motion, perception, thoughts, speech, actions, and especially in its interdependent relationship to others in community, as well as everything else in the world.

If you’re lucky, the result of that redesign might turn out to be close enough to what you currently have[1]. What’s dangerous is skipping that taxing redesign process altogether, or losing sight of the new target while you strive to maintain software built on the now-outdated conceptual model in order to address users’ current needs faster. Keeping in mind the updated model and evolving the whole system towards it while continuing to provide functional software to existing users at all times is probably the most difficult aspect of building software for the end user.

That said, I agree that originating from a single person (or indeed very few “agreeing resonant minds”) might be a pre-requisite for cohesive design, and I think “conceptual integrity” is a very fitting term.

[0] This might sound drastic, but this is my belief so far. Slightly expanded on it in https://news.ycombinator.com/item?id=25408650.

[1] I am tempted to say that the “tighter” the design (the more tailored the solution is to the problem), the more likely a small change in requirements is to affect the product in a major way once you rethink it.

Take that, all y'all whipper-snappers!

That notion of resonant minds seems very important

One person's system designs can lack conceptual integrity as easily as someone can make a plausible logical argument which lacks conceptual integrity.

If a design is to maintain conceptual integrity, the people who maintain it are responsible for it. That means everyone.

That said, I've definitely worked at some pretty successful places that seem more like organized chaos. I think it's just easier and more fulfilling to work on products and at companies that have that conceptual integrity.

Companies are very hierarchical so of course it makes sense for managers that most things should ideally come from one mind or a few agreeing minds. Then the average developer just have to do the grunt work.

So why is the book popular among developers? Because there is an elite cadre of developers in Brooks model which do have autonomy. I guess that cadre might also be known by other names.

[1] And the big man-month lesson of the book should be much more obvious now than it might have been back then: as you add more cooks you also have to take into account the communication overhead among all the new nodes.

Yeah, and 'the bird(s) must be wingless'. Whoever wrote this is not an architect, nor has ever met any real architects worthy of the label. Architects are driven by an overwhelming imperative to 'order' everything around them.

Also there is a reason we have "egoes". It's not a useless function of the psyche. The problem is with problematic egoes, fragile egoes, over-reaching egoes, etc. A strong, healthy, ego servers a respectable purpose.

Everybody considers themselves a designer, but it is baseless optimism that is supported by little data or precedent. Good designers are unique. Design ability is a 'talent'. Being able to conceive a complex system that maintains "conceptual integrity" is not an ability that everyone has, nor is it show (yet) that is even teachable!

Now an "egoless manager". That is a topic worth discussing. That species was never intended to take to the skies. /g (Bad managers let their egoes get in the way of actual talent, again and again. They should just manage the process and leave technical design for the architect. :-)

Also, yes it's true, you don't always need an architect. Most systems are an instance of a handful of widely repeated system patterns. What most teams need is a bit of maturity to distinguish and select the appropriate ready-made blueprint for their project. It is highly unlikely that your project requires a 'conceptual' breakthrough or innovation.