Archive
The New G-Spot
Before reading any further, please contemplate this Box cutter:
Essentially, all models are wrong, but some are useful- George Box
Now, let’s start with a pair of “model” problem-system and control-system templates:
Next, let’s hypothesize a new composite system that you designed, built, and deployed to “solve a vexing socio-technical problem“. You diligently employed the dorky BD00 templates, your brain, and your positional power to form a “semi–effective” marriage between your specific problem (indicated by the blue, scoped boundary) and your specific controller (indicated by non-white components):
Although your new system may appear to be alleviating (or least containing) the problem, looks can be (and usually are) deceiving. Before you pat yourself on the back for being a “problem solver“, please contemplate these Gall-isms:
New systems generate new problems – John Gall
Systems Develop Goals Of Their Own The Instant They Come Into Being – John Gall
Intra-system Goals Come First – John Gall
Thus, according to the Gallster, the a-priori and noble “G” you designed into your fabulous controller subsystem will eventually be usurped (sooner rather than later) by the emergent “G” of the new composite system entity. Sometimes the new “G” totally obscures the original “G” so thoroughly that, given enough time, nobody can even remember what the original “G” was. D’oh!
And what might this new system “G-Spot” be? Could it be to perpetuate and maybe even exacerbate the original problem so that the new system (especially the controller subsystem) can grow and thrive? After all, if the problem gets solved, then there will be no more need for the controller subsystem. In effect, the new system would be devouring itself as it solved the problem. But wait! That can’t happen because it would be a fruitless attempt to violate this Gall-Shirky pair:
Systems Tend To Grow, And As They Grow, They Encroach – John Gall
Institutions Tend To Preserve The Problem To Which They Are The Solution – Clay Shirky
An alternative BD00 quote rip-off is:
Systems, like people, tend not to consume themselves as food.
Can you concoct another alternative rip-off quote?
It’s What We Do
Error correction is what we are doing every instant of our lives – John Gall (The Systems Bible, P84)
OMG! Mr. Gall’s wisdom is spot on with William T. Powers‘ PCT, which in effect states that:
We are a mysterious stacked aggregate of thousands of little control systems acting continuously on our environment in a manner which corrects errors between what we desire and what is. (BD00 via William Powers)
Need some dorky picture to visualize the undecipherable message? For context, try this one first:
Next try this model of “us” (actually, anything that’s alive):
When we go to sleep, our conscious mental control system building blocks temporarily go dormant. However, those at the periphery of the stack which directly penetrate the physical “us/environment” boundary never sleep – because the environment never sleeps. These unsung workhorse heroes at the bottom of the hierarchy symphonically collaborate to keep our blood pressure, temperature, breathing, heart beat, etc, within some preset genetic limits so that we can wake up the next morning! And the little buggers do this by…. continuously correcting for errors between what the bazillion “controlled variables” are and what they should be. Error correction is what we do.
Note that without nature’s loving cooperation in keeping the variations in the environment within the controllable limits of our little friends, we wouldn’t be here now – we wouldn’t have even “begun“. What a joyous and miraculous dance of life, no?
So, the next time someone asks you what you do for a living, tell them that you correct errors.
Related articles
- Command Vs. Control (bulldozer00.com)
- Bankrupt Models (bulldozer00.com)
- From The Ground Up (bulldozer00.com)
- Cross-Disciplinary Pariahs (bulldozer00.com)
- Normal, Slave, Almost Dead, Wimp, Unstable (bulldozer00.com)
- Extrapolation, Abstraction, Modeling (bulldozer00.com)
- Nine Plus Levels (bulldozer00.com)
Tainted Themes
In “The Collapse of Complex Societies“, Joseph Tainter defines “complexity” as:
Complexity is generally understood to refer to such things as the size of a society, the number and distinctiveness of its parts, the variety of specialized social roles that it incorporates, the number of distinct social personalities present, and the variety of mechanisms for organizing these into a coherent, functioning whole. – Joseph Tainter.
Joseph then defines “collapse” as:
A society has collapsed when it displays a rapid, significant loss of an established level of sociopolitical complexity. Collapse then is not a fall to some primordial chaos, but a return to the normal human condition of lower complexity. – Joseph Tainter
Mr. Tainter then surveys the landscape of historic, archaeological, and anthropological literature explaining the collapse of societies like the western Roman empire, the Mayans, the Hittites, the Mycenaeans, etc. He groups the theories of collapse into 11 “tainted” themes:
Joseph then skillfully makes a case that all these specialized themes can be subsumed under his simple and universal theory of collapse:
His theory goes something like this. As a society grows, it necessarily becomes more complex. Exceedingly more and more investment in complexity (infrastructure, basic services, defense, food production control, public tributes to the elite to maintain their legitimacy in the minds of the non-elites) is then required to hold the society together. However, as the graphic below shows, at some point in time, the marginal return on the investments in complexity reaches a tipping point at which the society becomes vulnerable to collapse from one or more of the subsumed themes.
To illustrate further, BD00 presents the dorky growth-to-collapse scenario below:
As shown, societal growth begets a larger and more internally diverse production subsystem. That same growth requires investment in more and varied control (Ashby’s law of requisite variety) over production so that “the center can hold” and the society can “retain its identity as a whole“. In this runaway positive feedback system, the growing army of controller layers siphons off more and more of the production outputs for itself – starving the production subsystem in the process.
To prevent the production subsystem from dispersing (or revolting) and keep the whole system growing, more and more investment is poured into production control (compliance and efficiency) in an attempt to increase output and keep both the production and control subsystems viable. However, as the control subsystem growth outpaces production subsystem growth and a caste system emerges, the control subsystem requires a larger and larger share of the production subsystem outputs for itself – which further weakens and constrains and alienates the production subsystem. Hence, the “declining marginal return on investment in complexity” machine is kicked into overdrive and the vulnerability to collapse appears on the horizon. D’oh!
In your growing “society“, is the controller subsystem growing faster than the production subsystem? Are more specialized controller/administration layers being added faster than producers? Is the caste system becoming more stratified and prejudiced? Are more and more processes/rules/policies being imposed on the production subsystem for increased compliance and efficiency? Is the army of growing controllers siphoning off more and more of the production system outputs for themselves? If so, then maybe your society is vulnerable to sudden collapse. But then again, it may not. Tainter’s thesis is simply a bland and drama-less, economically based theory. It might be tainted itself.
Say it taint so, shoeless Joe! – unknown kid
It’s Systems As Such
BD00 is tickled pink to have discovered the work of systems guru John Gall through Ruth Malan and thinkpurpose (muchos gracias Ruth and TP!). Behold the wisdom of the man:
If you’re an anointed leader (a.k.a dictator) and/or so-called change agent, you better freakin’ paste these galling truisms on your wall and consult them before designing your next system or mandating a change “from above” to an existing system. Actually, fuggedaboud it. It doesn’t matter. You’re hosed no matter what; even if you think you aint.
The problem isn’t THE system, it’s systems as such – John Gall
LSD… Far Out Man
Alright, before we go on, let’s first get something out of the way so that we can start from the same context. This post is not about Small Scale Development (SSD) projects. As the following figure shows, on SDD projects one can successfully write code directly from a list of requirements (with some iterative back-and-forth of course) or set of use cases or (hopefully not) both.
Now that we’ve gotten that out of the way, let’s talk about the real subject of this post: Large Scale Development (LSD <- appropriate acronym, no?) projects. On hallucinogenic LSD efforts, one or possibly two additional activities are required to secure any chance at timely success. As the next figure shows, these two activities are “System Design” and “Software Design“.
So, what’s the difference between “system design” and “software design“? Well, if you’re developing software-intensive products for a specialized business domain (e.g. avionics, radar, sonar, medical, taxes), then you’re gonna need domain experts to bridge the GOHI (Gulf Of Human Intellect) between the higher level requirements and the lower level software design…..
Most specialized domain experts don’t know enough about general software design (object-oriented, structured, functional) and most software experts don’t know enough about domain-specific design to allow for successfully skipping the system design phase/stage. But that hasn’t stopped orgs from doing this….
The Gall Of That Man!
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall (1975, p.71)
This law is essentially an argument in favour of underspecification: it can be used to explain the success of systems like the World Wide Web and Blogosphere, which grew from simple to complex systems incrementally, and the failure of systems like CORBA, which began with complex specifications. – Wikipedia
We can add the Strategic Defense Initiative (Star Wars), the FBI’s Virtual Case File System (VCS), JTRS, FCS, and prolly a boatload of other high falutin’ defense projects to the list of wreckage triggered by violations of Gall’s law. Do you have any other majestic violations you’d like to share? Can you cite any counter-examples that attempt to refute the law….
One of the great tragedies of life is the murder of a beautiful theory by a gang of brutal facts – Benjamin Franklin
C++, which started out simply as “C With Classes“, is a successful complex “system“. Java, which started out as a simple and pure object-oriented system, has evolved into a successful complex system that now includes a mix of functional and generic programming features. Linux, which started out as a simple college operating system project, has evolved into a monstrously successful complex system. DDS, which started out as a convergence of two similar, field-tested, pub-sub messaging implementations from Thales Inc. and RTI Inc., has evolved into a successful complex system (in spite of being backed by the OMG). Do you have any other law abiding citizens you’d like to share?
Gall’s law sounds like a, or thee, platform for Fred Brooks‘ “plan to throw one away” admonition and Grady Booch‘s “evolution through a series of stable intermediate forms” advice.
Here are two questions to ponder: Is your org in the process of trying to define/develop a grand system design from scratch? Scanning your project portfolio, can you definitively know if you’re about to, or currently are, attempting a frontal assault on Gall’s galling law – and would it matter if you did know?
Motorcycle And Software Maintenance
Robert Pirsig’s “Zen And The Art Of Motorcycle Maintenance” is one of my fave books of all time. I have a soft cover copy that I bought in the nineties. Because of its infinite depth and immersive pull, I’ve read it at least three times over the years. Thus, when Amazon.com sent me a recommendation for the kindle version of it for $2.99, I jumped at the chance to e-read it and capture some personally meaningful notes from it.
(Published in 1974) the book sold 5 million copies worldwide. It was originally rejected by 121 publishers, more than any other bestselling book, according to the Guinness Book of Records. – Wikipedia
In a nutshell, ZATAOMM is about a college professor (Pirsig himself) who ends up going insane over his obsession with trying to objectively define what the metaphysical concept of “quality” means.
Quality…you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about. But if you can’t say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn’t exist at all.
During my fourth read of ZATAOMM, I started noticing how much of the wisdom Mr. Pirsig proffers up applies to the “art” of software development/maintenance:
When you want to hurry something, that means you no longer care about it and want to get on to other things.
This comes up all the time in
mechanicalsoftware work. A hang-up. You just sit and stare and think, and search randomly for new information, and go away and come back again, and after a while the unseen factors start to emerge.Sometimes just the act of writing down the problems straightens out your head as to what they really are.
The craftsman isn’t ever following a single line of instruction. He’s making decisions as he goes along. For that reason he’ll be absorbed and attentive to what he’s doing even though he doesn’t deliberately contrive this. He isn’t following any set of written instructions because the nature of the material at hand determines his thoughts and motions, which simultaneously change the nature of the material at hand.
Any effort that has self-glorification as its final endpoint is bound to end in disaster.
Stuck. No answer. Honked. Kaput. It’s a miserable experience emotionally. You’re losing time. You’re incompetent. You don’t know what you’re doing. You should be ashamed of yourself.
This gumption trap of anxiety, which results from overmotivation, can lead to all kinds of errors of excessive fussiness. You fix things that don’t need fixing, and chase after imaginary ailments. You jump to wild conclusions and build all kinds of errors into the machine because of your own nervousness.
Impatience is close to boredom but always results from one cause: an underestimation of the amount of time the job will take. You never really know what will come up and very few jobs get done as quickly as planned. Impatience is the first reaction against a setback and can soon turn to anger if you’re not careful.
Impatience, stuckness, underestimation, anxiety, and carelessness. These are just a subset of the feelings and behaviors that pervade dysfunctionally soulless organizations whose sole focus is on “following prescribed process and meeting schedule“.
Hand In Hand
Me thinks that these two quotes go together hand in hand, and in the order presented:
“At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success.” – C. A. Hoare
“The bitterness of poor system performance remains long after the sweetness of low prices and prompt delivery are forgotten.” – Jerry Lim
Have you ever participated on a project that made it out the door but caused financial and social “problems” sometime downstream? Lucky for him, BD00 hasn’t.
What’s The Diff?
One of the problems I’ve always had with the word “agile” is that it’s so overloaded (like “system“) that anyone can claim “agility“:
Everyone is doing agile these days – even those who aren’t – Scott Ambler
Along this vein, check out this slide from a unnamed agile expert:
Now tell me, how is this advice different from the unconscionable and anti-agile:
To define tests, you have to have some understanding of the requirements to test against in your cranium, no? It’s just that, in agile-land, you’ll be excommunicated from the cult if you formally write them down before slinging code. WTF?
Like “agile” was a backlash against “waterfall” in the past, maybe “waterfall” will be a circular backlash against “agile” in the future?
Likewise, instead of creating an emergent Frankensteinian design with revered “TDD“, why not hop off the bandwagon and create emergent tests with “DDT“?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 