Chapter 4. Aristocracy, Democracy, and System Design
4.1 ''Conceptual integrity is the most important consideration in system design."
What is conceptual integrity? is it consistency? is it simplicity? Is it understandability by others? The locution is pretty empty, meaning anything you want that is something like 'really good stuff', or some other self-supporting, empty phrase.The more I try to pin down its meaning, the more fluid it gets. I think I have a vague idea of what it should mean with respect to software, but any rational definition of it just never seems fully right.
4.2 ''The ratio of function to conceptual complexity is the ultimate test of system design," not just the richness of function. (This ratio is a measure of ease of use, valid over both simple and difficult uses.)
I'll just continue to harp on the undefined nature...how can one have a ratio when the dividend and divisor aren't well defined. What does 'function' mean? Number of features? Define 'feature'? This is all too vague.
4.3 To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.
Totally consistent with chapter 3. Simply a repetition (given that we accept 'conceptual integrity' to be general 'software goodness')
4.4 ''Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects." (Small ones, too.)
Now -this- is an important strategy for design and is actually substantive (where many less vague concepts than 'conceptual integrity' can be assessed, like 'time' to implement', or run-time efficiency of code (this latter idea is probably made worse, but that's for another comment, which will come soon enough)). And it is entirely abstract. Works for anything. It essentially says design is recursive. you can design a single entity by splitting it into parts (however you split) and each of those parts can be also designed. the 'separation' is essentially the structured programming/OOP concept of encapsulation/modularity/black box/hidden data, all of which are aids to memory and knowledge. That design the whole so that you need to know and remember as little as possible about the insides of the parts.
4.5 ''If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology."
Authoritarian certainly. This doesn't particularly show well with open-source projects, where (naively?) there -is- no designer or master control. But this has
This sounds like Russell's admonition that a good notation helps with the math (that is some structure as opposed to total freedom, helps)...OK I looked for it. The quote is very relevant:4.6 Discipline is good for art. The external provision of an architecture enhances not cramps, the creative style of an implementing group.
...a good notation has a subtlety and suggestiveness
which at times make it seem almost like a live teacher.
(from Russell's introduction to Wittgenstein's Tractatus)
4.7 A conceptually integrated system is faster to build and to test.
A -modular- (let's take that as the intended meaning; not a straw man, and not really what one one thinks of immediately system certainly is -easier- and then, I guess, faster to test, but not necessarily more efficient. For comparison's sake let's say the alternative to modularity is ...I'm searching for the word...something to do with 'monolithic'...how about 'monolithicity'? 'monolithicness'? 'unity'? Anyway, a monolithic system has large communication/use degree between internal implicit concepts and features, and therefore, much shorter dependency paths than a modular system,and so is more likely to have greater executional efficiencies. BUt to support Brooks's statement, if one is being modular, then each module has a much smaller and cohoerent test range and so test can be tested more easily The monolithic system -has- to be developed/designed as one entity with all element in a designers mind at once, much more likely to overload that human's ability to manipulate the design mentally.
4.8 Much of software architecture, implementation, and realization can proceed in parallel. (Hardware and software design can likewise proceed in parallel.)
If modularity in followed and specifications of interaction between the pieces is done well, then yes.
No comments:
Post a Comment