Archive
Who’s Controlling The Controller?
The figure below models a centralized control system in accordance with Bill Powers’ Perceptual Control Theory (PCT).
Given 1: a goal to achieve, and 2: the current perceived state of the production system, the decision-making apparatus issues commands it presumes will (in a timely fashion) narrow the gap between the desired goal and the current system state.
But wait! Where does the goal come from, or, in cybernetics lingo, “who’s controlling the controller?” After all, the entity’s perceptions, commands, actions, and controlled quantity signals all have identifiable sources in the model. Why doesn’t the goal have a source? Why is it left dangling in an otherwise complete model?
Abstraction is selective ignorance – Andrew Koenig
Well, as Bill Clinton would say, “it depends“. In the case of an isolated system (if there actually is such a thing), the goal source is the same as the goal target: the decision-maker itself. Ahhhh, such freedom.
On the other hand, if our little autonomous control system is embedded within a larger hierarchical control system, then the goal of the parent system decision maker takes precedence over the goal of the child decision maker. In the eyes of its parent, the child decision maker is the parent’s very own virtual production subsystem be-otch.
To the extent that the parent and child decision maker’s goals align, the “real” production system at the bottom of the hierarchy will attempt to achieve the goal set by the parent decision maker. If they are misaligned, then unless the parent interfaces some of its own actuator and sensor resources directly to the real production system, the production system will continue to do the child decision maker’s bidding. The other option the parent system has is to evict its child decision maker subsystem from the premises and take direct control of the production system. D’oh! I hate when that happens.
Effective, Incompetent, Coercive, Klueless
In any control system design, the accuracy of its input sensors, the force of its output actuators, the ability of its controllers to decide whether the system’s goals are being met, and the responsiveness (time lag) of all three of its parts determine its performance.
However, that’s not enough. All of the control system’s sensors and actuators must be actually interfaced to the controlled system in order for the controller + controllee supra-system to have any chance at meeting the goal supplied to (or by) the controller.
The Hodgepodge Myth
There are two kinds of languages. Those that everyone complains about and those that nobody uses. – Bjarne Stroustrup
I’ve seen C++ described as a thoughtless hodgepodge of features and approaches that were carelessly slapped together and foist upon the programming community. However, if any of those detractors read “The Design And Evolution Of C++” and dive deeply into the language’s technical details, they might change their minds and marvel at the essential complexity baked into C++.
As a systems programming language whose target niche is infrastructure and constrained-resource (CPU speed and memory) applications, C++ is all about achieving efficient abstraction (as opposed to increasing programmer productivity). For efficiency, its constructs must not move too far away from how computing hardware actually stores and manipulates data (linear arrays, pointers, stack-based variables). Otherwise, a “hidden” layer of translational code must be inserted between what the programmer actually writes and the code that actually runs on the hardware. To write large, domain-specific programs, C++ must also provide abstraction facilities for implementing domain concepts and inter-concept relationships directly in code (classes, inheritance, friendship, templates, namespaces, exceptions, meta-programming).
Comparatively speaking, no other high level language comes close to achieving the blend of abstraction and efficiency that C++ attains. Sure, there are many newer languages that increase programmer productivity by decreasing verbosity, increasing levels of abstraction, and insulating the programmer from details, but the price paid for this productivity gain is a loss in runtime performance, a shallow understanding of what goes on underneath the covers, and long stretches of optimization/tuning efforts to meet performance requirements.
Once an engineer forms a string opinion on a technical tool or methodology, she is unlikely to change it – no matter what evidence is placed in front of her. As regular readers of this ball-busting blog know, BD00 chronically suffers from this “fan boy” malady all too well. And this post is a prime example of that behavioral trait.
The Same Old Wine
Investment is to Goldman Sachs as management is to McKinsey & Co. These two prestigious institutions can do no wrong in the eyes of the rich and powerful. Elite investors and executives bow down and pay homage to Goldman McKinsey like indoctrinated North Koreans do to Kimbo Jongo Numero Uno.
As the following snippet from Art Kleiner’s “Who Really Matters” illustrates, McKinsey & Co, being chock full of MBAs from the most expensive and exclusionary business schools in the USA, is all about top-down management control systems:
…says McKinsey partner Richard Foster, author of Creative Destruction. If you ask companies how many control systems they have, they don’t know. If you ask them how much they’re spending on control, they say, ‘We don’t add it up like that.’ If you ask them to rank their control systems from most to least cost-effective, then cut out the twenty percent at the bottom, they can’t.” (And this from a partner at McKinsey, the firm whose advice has launched a thousand measurement and control systems.)
A dear reader recently clued BD00 into this papal release from a trio of McKinsey principals: “Enhancing the efficiency and effectiveness of application development”. BD00 doesn’t know fer sure (when does he ever?), but he’ll speculate (when does he never?) that none of the authors has ever been within binoculars distance of a software development project.
Yet, they laughingly introduce a…
..viable means of measuring the output of application-development projects.
Their highly recommended application development control system is based on, drum roll please…. “Use Cases” (UC) and “Use Case Points” (UCP).
Knowing that their elite, money-hoarding, efficiency-obsessed, readers most probably have no freakin’ idea what a UC is, they painstakingly spend two paragraphs explaining the twenty year old concept (easily looked up on the web); concluding that…
..both business leaders and application developers find UCs easy to understand.
Well, yeah. Done “right“, UCs can be a boon to development – just like doing “agile” right. But how often have you ever seen these formal atrocities ever done right? Oh, I forgot. All that’s needed is “training” in how to write high quality UCs. Bingo, problem solved – except that training costs money.
Next up, the authors introduce their crown jewel output measurement metric, the “UCP“:
UCP calculations represent a count of the number of transactions performed by an application and the number of actors that interact with the application in question. UCPs, because they are simple to calculate, can also be easily rolled out across an organization.
So, how is an easily rolled out UCP substantively different than the other well known metric: the “Function Point” (FP)?
Another approach that’s often talked about for measuring output is Function Points. I have a little more sympathy for them, but am still unconvinced. This hasn’t been helped by stories I’ve heard of that talk about a single system getting counts that varied by a factor of three from different function point counters using the same system. – Martin Fowler
I guess that UCPs are superior to FPs because it is implied that given X human UCP calculators, they’ll all tally the same result. Uh, OK.
Not content to simply define and describe how to employ the winning UC + UCP metrics pair to increase productivity, the McKinseyians go on to provide one source of confirmation that their earth-shattering, dual-metric, control system works. Via an impressive looking chart with 12 project data points from that one single source (perhaps a good ole boy McKinsey alum?), they confidently proclaim:
Analysis therefore supports the conclusion that UCPs’ have predictive power.
Ooh, the words “analysis” and “predictive” and “power” all in one sentence. Simply brilliant; spoken directly in the language that their elite target audience drools over.
The article gets even more laughable (cry-able?) as the authors go on to describe the linear, step-by-step “transformation” process required to put the winning UC + UCP system in place and how to overcome the resistance “from below” that will inevitably arise from such a large-scale change effort. Easy as pie, no problemo. Just follow their instructions and call them for a $$$$$$ consultation when obstacles emerge.
So, can someone tell BD00 how the McKinsey UC + UCP dynamic duo is any different than the “shall” + Function Point duo? Does it sound like the same old wine in a less old bottle to you too?
Uncle Fester
I just finished browsing through some of the 130 draft posts I have stashed down in the catacombs of my WordPress site.
Most of these zombies, seeded with partially formed ideas rooted in a mix of direct personal experiences and wild speculations (exactly like my published posts), won’t ever see the light of day. Unlike my published posts, I couldn’t close the deal on these pesky little drafts – even after circling back to them sometimes 3-4 times.
Since I have drafts that date way back to 2009, I should prolly sh*tcan at least the dinosaurs hatched before 2010.
Maybe I will indeed go on a draft killing spree, but maybe not. I just may let my little draftlings continue to fester down in the dungeons a bit longer. Who knows, the next time I go mining for ideas for my next world-changing post, one of these fugly ducklings may convince me to finish what I started and bring it to life.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
