Archive
Goal Setting
Given the generic control system model below, how can we improve the performance of an underachieving production system?
One performance improvement idea is to make the goal directly visible to the production system; as opposed to indirectly via the policy/process actions of the actuators.
A meta-improvement on this idea is to allow the production system constituents direct involvement in the goal setting process.
It seems to make naive sense, doesn’t it? Well, it does unless the goal is some arbitrarily set financial target (“increase market share by 10%“, “decrease costs by 5%“, “increase profits by 25%“) pulled out of a hat to temporarily anesthesize Wall Street big-wigs.
Related articles
- Who’s Controlling The Controller? (bulldozer00.com)
- Unobservable, Uncontrollable (bulldozer00.com)
Unobservable, Uncontrollable
Piggybacking on yesterday’s BS post, let’s explore (and make stuff up about) a couple of important control system “ilities“: observability and controllability.
First, let’s look at a fully functional control system:
As long as the (commands -> actions -> CQs -> perceptions) loop of “consciousness” remains intact, the system’s decision maker(s) enjoy the luxury of being able to “control the means of production“. Whether this execution of control is effective or ineffective is in the eye of the beholder.
As the figure below illustrates, the capability of decision-makers to control and/or observe the functioning of the production system can be foiled by slicing through its loop of “consciousness” at numerous points in the system.
From the perspective of the production system, simply ignoring or misinterpreting the non-physical actions imposed on it by the actuators will severely degrade the decision maker’s ability to control the system. By withholding or distorting the state of the important “controlled quantities” crucial for effective decision making, the production system can thwart the ability of the decision maker(s) to observe and assess whether the goal is being sought after.
In systems where the functions of the components are performed by human beings, observability and controllability get compromised all the time. The level at which these “ilities” are purposefully degraded is closely related to how fair and just the decision makers are perceived to be in the minds of the system’s sensors, actuators, and (especially the) producers.
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.
Scrummin’ For The Ilities
Whoo hoo! The product owner has funded our project and we’ve spring-loaded our backlog with user stories. We’re off struttin’ and scrummin’ our way to success:
But wait! Where are the “ilities” and the other non-functional product requirements? They’re not in your backlog?
Uh, we don’t do “ilities“. It’s not agile, it’s BDUF (Big Design Up Front). We no need no stinkin’ arkitects cuz we’re all arkitects. Don’t worry. These “ilities” thingies will gloriously emerge from the future as we implement our user stories and deliver working increments every two weeks – until they stop working.
Consumption AND Creation
Bill Gates is obviously biased, but Bob Lewis is not. What they have in common is the same contrarian opinion as BD00: Windows 8 is better than iOS and Android. OMG! WTF?
The iPad is better done. It’s more polished and has fewer irritations. None of this matters when the subject is getting work done. For that, Windows 8 is the superior tablet OS… When you have to get down to work, even with all the aggravations there’s really no contest. – Bob Lewis
But a lot of those (iOS and Android) users are frustrated, they can’t type, they can’t create documents. They don’t have Office there. So we’re providing them something with the benefits they’ve seen that have made that a big category, but without giving up what they expect in a PC. – Bill Gates
I know, I know. There are equivalents for Microsoft office on iOS and Android. But they don’t stack up very well against Microsoft’s well-integrated, flagship application suite. Android and iOS are touch-centric, which is a boon to consumption, but Win8 embraces touch, the keyboard, and the mouse all as first class citizens. Simply stated, iOS and Android are superior when it comes to consuming content, but Win8 is king at facilitating both consumption and creation.
I have a Kindle Fire HD and an iPhone 5, both of which I love for consumption of content. I don’t own a Win8 tablet or all-in-one PC yet, but being a somewhat creative blog writer and dorky graphics sketcher, I’m gonna get one or the other soon.
In addition to Mr. Lewis and Mr. Gates, Dr. Dobb’s editor Andrew Binstock equivalently states ( “The Ever-Fatter Thin Client”):
But the vision of a tablet cum keyboard as the new model of PC is right on. This is the fat client come to the new form factor. I believe the future is heading in that direction and that the Microsoft Surface leads the way. I’ve been using an Intel-based Surface Pro for several weeks now and very much like the combination of PC and tablet that it provides. The device, while considerably more expensive than the standard tablet, represents a believable next step for the industry — a full PC (with Intel processor, SSD disk, 4GB RAM, 1920×1080 screen) that can be used as a touch-enabled tablet. Only battery life and cost stand in the way of wide acceptance.
Lately, Microsoft’s financial performance has been deteriorating because of the rise of the thin tablet. However, like they always seem to do, I believe the company will recover and come to the forefront once again. The software “thickness” of Win8 and the hardware “thickness” of Intel’s CPUs will eventually win out in the long run because they facilitate both consumption and creation much better than the current bevy of alternatives.
It’s Definitely A Compiler Bug
Previously, I wrote a post about a potential compiler bug with the g++ compiler in the GCC 4.7.2 collection that was driving me nutz: “Uniform Initialization Failure?“. In that post, I flip-flopped between concluding whether the issue I stumbled upon was a bug or just another one of those C++ quirks that cause newbie programmers to flee in droves toward the easier-to-learn programming languages. D’oh!
Since I wrote that post, I’ve purchased and have been studying the fourth edition of Bjarne’s TCPPL. It’s now a slam dunk. The g++ GCC 4.7.2 compiler does indeed have a bug in its implementation of C++11’s uniform initialization feature.
First, consider this Stroustrup code snippet:
Note how Bjarne “uniformly” uses braces to initialize all of class X‘s member variables – including the Club reference member variable, rc.
Next, look at the code I wrote that makes g++ 4.7.2 barf:
Note how the compiler spewed blasphemy when I tried to uniformly use braces to initialize the GccBug class’s foo and bar member variables.
Now, look at what I had to do to make the almighty compiler happy:
As you can see, I had to destroy the elegancy of uniform initialization by employing a mix of braces and old-style parenthesis to initialize the foo and bar member variables.
It’s my understanding that GCC 4.8.2 has been released and it has been deemed C++11 feature-complete. I currently don’t have it installed, but, if one of you dear readers are using it, can you please experiment with it and determine if the bug has been squashed? I have a highly coveted BD00 T-shirt waiting in the warehouse for the first person who reports back with the result.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 