Importance of Conceptual Integrity in System Design(wiki.c2.com) |
Importance of Conceptual Integrity in System Design(wiki.c2.com) |
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.
A city is not a tree http://www.bp.ntu.edu.tw/wp-content/uploads/2011/12/06-Alexa...
Conversely do you think there have been any failed and therefore short-lived complex systems that did have conceptual integrity?
More importantly, the perceived conceptual integrity of the human body is rather philosophical was put to question by Roger Penrose in his JRE episode where he talks about why the distribution of motor functions makes no sense ("the foot and walking are over here", "running is all the way over there", to paraphrase) all and we likely need a new physics model to explain consciousness as it arises in the physical brain.
Biology moved on from such an Aristotelian perspective for good reason, to slightly alter something Spinoza once said, we don't know what a cell can do. Our physical being is a radical aggregate that we don't even fully understand yet.
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.
In the real world, software engineering is some what more loosely defined and encompasse s things like programming, system design and so on.
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.
It's also talent that is hard to recognize and can be valued very differently from one organization to the next. I've been in the room with developers and management looking cross-eyed at me as I walk them through a top down business/problem decomposition and system design questioning the value of the entire exercise. Not surprising, these are organizations which have extremely brittle systems full of overlapping and "hard to reason about" abstractions.
(this is related imo to your post: https://brooker.co.za/blog/2020/10/19/big-changes.html - )
On a related tangent, I've been re-reading "The Open Hand - Essays on Le Corbusier". Specifically, the "Le Corbusier at Pessac - Professional and Client Responsibilities" essay by Brian Brace Taylor.
https://www.worldcat.org/title/open-hand-essays-on-le-corbus...
Pessac: https://www.archdaily.com/940878/le-corbusiers-cite-fruges-l...
That project basically failed its intended purpose. The client, M. Frugès, was apparently an enlightened capitalist, willing to invest in the vision of the young architect, even when incurring financial losses, because of Pessac. Corbu also learned, on the job, how to, and how not to, build his modernist vision. The whole thing was a fiasco on many levels. But it was a necessary project for progress in the field.
Which is the point: architectural innovation is costly and even great architects leave a trail of failed early projects. Yes, Corbu went on to master his field, and he did deliver (opinions of course vary) on the program of modern, afforadable, mass housing for the urban working class:
https://en.wikipedia.org/wiki/Unit%C3%A9_d%27habitation
But then:
"You know, it is life that is right and the architect who is wrong." - Le Corbusier (!)
https://libquotes.com/le-corbusier/quote/lbz6x3v
It's a problematic vocation (bricks or bytes). Love it or leave it.
Maybe you assume that random developers will speak up, point out an inconsistency, and everybody agrees to make it consistent from now on. In a small team it might work that way, but "system design" implies a larger community to me. Consensus is hard.
The whole point of responsibility is that blame and praise is focused. A focus on everyone is no focus at all.
Well, we do have traffic police and courts and lawyers.
Yes, everyone should follow the rules. But the point of having an individual responsible for conceptual integrity does not mean, no one else should care and do whatever they want, but that there is, if needed, "police and judges" in place...
But there is another point: the fewer people the easier it is to have a consensus about what the conceptual integrity entails. If you have a single judge, you are more likely to expect consistent rulings, so to speak.
"But the body isn't homogeneous! It's just mostly homogenous" is a splitting hair argument even if I'd believed you'd kept the plot.
The fact that you even acknowledge it is splitting hairs indicates that you are aware that your analogy is flawed as you can't really think of the body as just cells and that is in direct contrast to systems we discuss in which everything, not mostly, are a certain way. Your body is not mostly cells in the strictest of senses. It is lot of non living material that is a mix or organically made structures as well as various gases, liquids and solids.
But yeah, the analogy isn't perfect. And the academic nature of the metaphor's subject was obviously going to invite some rube to point out how it's not 100% spot on and how that's well worth talking about.
You're just arguing my greater point anyway: Your chosen level of perspective with these metaphors (and real issues) will invert the design philosophy. At one level, everything is different and using different means for the same goal, at another level, everything is the same and using the same means for different goals. If it's not organs, then its cells, then its "extracellular material and are dead cells different from live cells!?", then its atoms and then quarks.
But please, go ahead and educate me on how atoms aren't all the same and how that too is a critical point to be made in this conversation.
The second, which speaks directly to the concepts talked about, is the idea that "everything in the body is a cell" is a poor analogy to use to try to articulate your idea either supporting or not supporting the original posts concept, and you got salty when called out on it rather than have people simply agree with your "amazing insight".
PS I love this game.