Archive
Same Old, Same Old
After stumbling across this announcement, “Navy orders Raytheon to stop work on next-gen radar“, I just had to laugh. It’s the same old, same old “iterative” process:
- The Department of Defense issues a request for proposals.
- The usual suspects (Lockheed Martin, Raytheon, Northrup Grumman, etc) submit bids.
- A winner is selected – Yay!
- The sore loser(s) protest the decision.
- By law, the decision must be revisited and re-evaluated.
- The decision is either upheld, or a new winner is selected.
- If a new winner is selected, the previous winner protests.
I’ve worked in the aerospace and defense industry for 30+ years and I’ve seen this dysfunctional, time and money wasting, game play over and over like clockwork. Tick tock, tick tock.
Sometimes the bid-win-protest cycle goes on for years and it takes longer for the hundreds of bureaucrats, lobbyists, committees, and politicians to resolve the dilemma than for the eventual winner to actually build the system. In addition, after all the political shenanigans have played out and the ultimate winner starts the ball rolling, the contract is sometimes cancelled in midstream after millions of dollars and engineering hours have been spent.
Despite repeated calls for procurement/acquisition process reform, the system is so big and there are so many intertwined players that any substantive change is virtually impossible. But hey, it’s taxpayer money. No problemo.
The System Always Fights Back – John Gall
A Danger To Themselves And Others
“Efficient systems are dangerous to themselves and others” – John Gall
A new system is always established with the goal of outright solving, or at least mitigating, a newly perceived problem that can’t be addressed with an existing system. As long as the nature of the problem doesn’t change, continuously optimizing the system for increased efficiency also joyfully increases its effectiveness.
However, the universe being as it is, the nature of the problem is guaranteed to change and there comes a time where the joy starts morphing into sorrow. That’s because the more efficient a system becomes over time, the more rigid its structure and behavior becomes and the less open to change it becomes. And the more resistant to change it becomes, the more ineffective it becomes at achieving its original goal – which may no longer even be the right goal to strive for!
In the manic drive to make a system more efficient (so that more money can be made with less effort), it’s difficult to detect when the inevitable joy-to-sorrow inflection point manifests. Most managers, being cost-reduction obsessed, never see it coming – and never see that it has swooshed by. Instead of changing the structure and/or behavior of the system to fit the new reality, they continue to tweak the original structure and fine tune the existing behaviors of the system’s elements to minimize the delay from input to output. Then they are confounded when (if?) they detect the decreased effectiveness of their actions. D’oh! I hate when that happens.
Sensors AND Actuators
Encroach And Dominate
Systems tend to grow, and as they grow, they encroach – John Gall (The Systems Bible)
Complex societies, once established, tend to expand and dominate – Joseph Tainter (The Collapse Of Complex Societies)
Related articles
- The Gall Of That Man! (bulldozer00.com)
- It’s Systems As Such (bulldozer00.com)
How Can We Make This Simpler?
The biggest threat to success in software development is the Escalation of Unessential Complexity (EUC). Like stress is to humans, EUC is a silent project/product killer lurking in the shadows – ready to pounce. If your team isn’t constantly asking “how can we make this simpler?” as time ticks by and money gets burned, then your project and product will probably get hosed somewhere downstream.
But wait! It’s even worse than you think. Asking “how can we make this simpler?” applies to all levels and areas of a project: requirements, architecture, design, code, tools, and process. Simply applying continuous inquiry to one or two areas might delay armageddon, but you’ll still probably get hosed.
If you dwell in a culture that reveres or is ignorant of EUC, then you most likely won’t ever hear the question “how can we make this simpler?” getting asked.
But no need to fret. All ya gotta do to calm your mind is embrace this Gallism :
In complex systems, malfunction and even total malfunction may not be detectable for long periods, if ever – John Gall
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?
Come To Papa!
I recently listened to a fascinating podcast interview of Valve Inc‘s “economist-in-residence“, Yanis Varoufakis. According to Yanis, the company is still organizationally flat after 17 years of existence.
The thought early on at Valve was that the maximum limit to flatness would be around 50-60 people. Above that, in order to keep the wheels from falling off, some form of hierarchy would be required for concerted coordination. However, currently at 300+ employees, Valve has managed to blow through that artificial barrier and remain flat. Mind you, this is not a company solely made up of like-thinking engineers. There are also artists, animators, writers, and accountants running around like a herd of cats inefficiently doing the shit that brings in $1B in revenue each year.
According to Yanis, in order to maintain their egalitarian culture, Valve can’t afford to grow too quickly. That’s because they have to deprogram people who are hired in from hierarchical borgs as former bosses who expect others to work for them, and former workers who expect to be “directed” by a boss. If Valve didn’t do this, their culture would get eaten alive by the pervasive and mighty command-and-control mindset. The spontaneity, creativity, and togetherness that power their revenue machine would be lost forever.
Nevertheless, Valve is pragmatic with respect to hierarchy:
“Valve is not averse to all organizational structure—it crops up in many forms all the time, temporarily. But problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers.” – The Valve employee handbook
Whether Valve knows it or not, their success is due to their respect of some of Gall’s system laws:
- Systems develop goals of their own as soon as they come into existence – and intra-system goals come first.
- Loose systems last longer and work better. Efficient systems are dangerous to themselves and others.
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)
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
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 