Archive
FOSTMA And NASHMA
Whoo Hoo! I thought of a positive complement to my negative FOSTMA acronym. It’s, it’s, it’s….. NASHMA = Nayar, Semler, Hsieh MAnagement:
Of course, in order to prevent chaos, NASHMA orgs still have hierarchical structures, but they’re not run as stratified caste system CCHs. In NASHMA orgs, there’s real, two way accountability; and symmetric relationships exist up and down all levels. Most managers in NASHMA groups are PHORs and not STSJs who spend all their “valuable” time planning, watching, controlling, and evaluating.
Now mind you, to avoid the trap of dualistic thinking, an org shouldn’t be judged as fully belonging to one class or the other. There can be pockets of FOSTMA groups in a NASHMA org and vice versa. Nevertheless, my scientifically collected and analyzed data revealed this current distribution of institutions along the FOSTMA-NASHMA continuum:
Over time, hopefully the threshold will move to the left – increasing the currently miniscule NASHMA to FOSTMA ratio. However, there will always be powerful and scary psychological forces opposing the movement.
Double Loop Learning
Chris Aryris is a giant in the field of organizational development. LinkedIn e-colleague Gene Bellinger recently posted this classic Argyris article, “Teaching Smart People How To Learn“, to his “Systems Thinking” group. In the missive, Mr. Argyris gives a great example of double loop learning:
I have coined the terms ‘‘single loop’’ and ‘‘double loop’’ learning…. To give a simple analogy: a thermostat that automatically turns on the heat whenever the temperature in a room drops below 68 degrees is a good example of single-loop learning. A thermostat that could ask, ‘‘Why am I set at 68 degrees?’’ and then explore whether or not some other temperature might more economically achieve the goal of heating the room would be engaging in double-loop learning.
Because of the Law Of Impermanence (LOI), it’s inevitable that what worked in the past won’t work at some unknowable time in the future. The top half of the figger below illustrates the LOI in action. On the left, we have a successful org or individual happily humming along. The successful “entity” repeatedly performs actions that lead to success. As long as the external environment doesn’t change, this self-reinforcing loop of success can be sustained for quite a long time. However, since the LOI is constantly and relentlessly operating in the background, insanely doing the same thing over and over again will eventually guarantee failure. The failure may occur instantaneously like a broken axle while driving on the freeway, or it may manifest gradually like an excruciating death by a thousand cuts. Bummer.
Possibly the only way of keeping the LOI at bay is to institute double loop learning. The figger below shows the painful, transformational process of adding a second action-result-reflection loop to the system. By adding the skill of reflection, deteriorating results can be detected and action can be periodically tuned to accommodate a changing world.
Just because “deteriorating results can be detected and action can be tuned” doesn’t mean they will be. The forces against truthful org and individual reflection on poor results are formidable. Denial, angst, and fear, which are all dysfunctions of the individual and collective human ego, conspire against improving system robustness and viability via change. Reorgs, appointing the same people to funky new titles, bumping up compensation/perks, cutting costs, and attempting to apply all other textbook management tools amount to wrapping bandaids around a massive hemorrhage. Double bummer.
The hardest aspect of getting a double learning loop into operation is connecting the “Reflection” node back to the “Action” node so that actions can be changed. As I know too well, it’s relatively easy to reflect on one’s actions while exhibiting the same insane behavior over and over and over and over………..
“Without deviation from the norm, progress is not possible.” – Frank Zappa
Performance Playground
Since I work on real-time software projects where tens of thousands of data samples per second must be filtered, manipulated, and transformed into higher level decision-support information, performance in the main processing pipeline is important. If the software can’t keep up with the unrelenting onslaught of data streaming in from the “real world“, internal buffers/queues will overflow at best and the system will crash at worst. D’oh!
Because of the elevated importance of efficiency in real-time systems, I always keep a simple (one source code file) project named “performance_playground” open in my Eclipse IDE for algorithm/idiom/pattern prototyping and performance measurement. I use it to measure and optimize the performance of “chunks” of critical logic and to pit two or more candidates against each other in performance death matches. For each experiment I “branch” off of the project trunk and then I tag and commit the instantiation to archive the results.
The source code for the performance_playground project is shown below. The program’s sole external dependency is on the boost.date_time library for its platform-independent timestamping. Surely, you have the boost library set installed on all your development platforms, right?
How about you? Do you have something similar? Do you assume that all performance testing and algorithm vetting falls into the dreaded, time-wasting, “premature optimization” anti-pattern?
Avoiding The Big Ball Of Mud
Like other industries, the software industry is rife with funny and quirky language terms. One of my favorites is “Big Ball of Mud“, or BBoM. A BBoM is a mess of a software system that starts off soft and malleable but turns brittle and unstable over time. Inevitably, it hardens like a ball of mud baking in the sun; ready to crumble and wreak havoc on the stakeholder community when disturbed. D’oh!
“And they looked upon the SW and saw that it was good. But they just had to add one more feature…”
Joseph Yoder, one of the co-creators of “BBoM” along with Brian Foote, recently gave a talk titled “Big Balls of Mud in Agile Development: Can We Avoid Them?“. Out of curiosity and the desire to learn more, I watched a video of the talk at InfoQ. In his talk, Mr. Yoder listed these agile tenets as “possible” BBoM promoters:
- Lack of upfront design (i.e. BDUF)
- Embrace late changes to requirements
- Continuous evolving architecture
- Piecemeal growth
- Focus on (agile) process instead of architecture
- Working code is the one true measure of success
For big software systems, steadfastly adhering to these process principles can hatch a BBoM just as skillfully as following a sequential and prescriptive waterfall process. It’ll just get you to the state of poverty that always accompanies a BBoM much quicker.
Unlike application layer code, infrastructure code should not be expected to change often. Even small architectural changes can have far reaching negative effects on all the value-added application code that relies on the structure and general functionality provided under the covers. If you look hard at Joe’s list, any one of his bullets can insidiously steer a team off the success profile below – and lead the team straight to BBoM hell.
Loki Is Not Loco
Never heard of “Loki”? Check it out here: The Loki Library.
The Loki team has developed the best philosophy for programming library design that I’ve ever seen. It’s not so abstract that you can’t figure out what they mean, and they know that the real bang for the buck comes from disciplined dependency management and small, flat components. Judge for yourself:
How about you? Have you seen better?
Happressed
Ray (the “singularity” dude) Kurzweil‘s web site has summarized Science magazine‘s breakthrough of the year: the world’s first quantum machine. The gizmo is a tiny, but visible to the naked eye, metal “paddle” whose vibrational frequency can be controlled.
No big thing right? Well, here’s what some rocket scientists from UC Santa Barbara achieved:
First, they cooled the paddle until it reached its “ground state,” or the lowest energy state permitted by the laws of quantum mechanics (a goal long-sought by physicists). Then they raised the widget’s energy by a single quantum to produce a purely quantum-mechanical state of motion. They even managed to put the gadget in both states at once, so that it literally vibrated a little and a lot at the same time—a bizarre phenomenon allowed by the weird rules of quantum mechanics.
Wild and exciting stuff, no? A macro object composed of a collection of atoms (not just some singular, invisible, sub-atomic particle) operating in two supposedly mutually exclusive states at once. Just think of any point of reference on the paddle. The scientists proved (<- this is a key word as you’ll see below) that they could force it appear in two places at once. It’s sort of like being both ecstatically happy and depressed at the same time?
When I read about this breakthrough, I frantically searched the web for a video of the event. Hell, I want to actually see and experience what it looks like. Sadly, I was disappointed. I found this clip from Gizmodo that explains the absence of any visual evidence:
“It’s important to realize that they didn’t actually observe it in a superposition. All they said was that the paddle is large enough that it could be observed by the naked eye, but not while it is in a superposition state.”
D’oh! Upon reflection, this makes sense to me based on my layman’s knowledge of quantum physics. Prior to observation by, uh, an observer, so-called reality exists as a superposition of an infinite set of continuous matter waves that can be modeled by Erwin Schrodinger‘s unassailable wave equation. At the moment of observation, poof!, an observer “collapses” the wavefunction into a singularity – in effect creating his/her own reality. The mysterious question to me is: “Why do most people seem to see essentially the same reality when they observe an object at the same point in space and time?“. After all, what are the chances that my collapsed wavefunction will coincide with yours?
Dilbert Disservice
Merry Christmas and Ho, Ho, Ho! Dear reader, if you don’t want to be negatively influenced today, then please move on and don’t read any further.
Before Dilbert and Scott Adams rocketed to fame and fortune by speaking about the unspeakable, DICsters toiling down in the boiler room at least had hope that the grass was greener on the other side. However, the Dilbert strip has unveiled what many didn’t know prior to its public emergence: the grass most likely isn’t greener “over there“.
Every day, Dilbert and his cohorts drive home the point that dysfunctional corpricracies are as ubiquitous and pervasive as the weeds in your garden. The strip has actually helped CCFs by demotivating DICsters from leaving toxic environments – because now they think that “it’s the same everywhere“. D’oh!
Money, Tools, Materials, Know-How, Products
Since you’ve stopped by, check out the company-centered, system loop diagram below. The model is composed of three interdependent parts: the company, the customers, and the suppliers. In equilibrium, when all is well:
- The company produces products that are paid for, and consumed by, customers.
- The company purchases tools and materials from suppliers.
- The company uses the tools, materials, and the knowledge of its workforce to create the products that sustain the viability of the company.
- The company’s cash inflow exceeds it’s cash outflow
Note that if any of the links in the system get severed, the company collapses. If the products stop flowing out of the company, the life-giving cash stops flowing in. If the cash stops flowing in, the products stop flowing out. If the tools and materials stop flowing in, the products stop flowing out. From the company’s perspective, products lead to cash and cash leads to more products in a positive, self-reinforcing, feedback loop.
Using the diagram below, let’s look in more depth at the company’s cash inflows and outflows. In stable, steady-state operation, the cash inflow is managed competently by the executive team. After taking their cut of the action, the executives push some cash downward through the patriarchy to keep the operation humming and they approve of all outflows to suppliers.
What the picture doesn’t show, is the indirect source of the customer cash – the company’s product set. Lets augment the diagram above and close the loops:
There are a bazillion external, and especially, internal threats to system viability. Externally, customers can run out of cash and suppliers can go bust. Internally, bureaucratic little Hitlers, byzantine processes, lack of investments in tools and people, inequities in status and pay, silo-to-silo infighting, and poor hiring practices are among the myriad of threats that can contribute to corpo implosion. Of course, the purpose of management is to gracefully overcome the threats. But hey, regardless of whether executives and their management appointees are the cause of success or failure, they still have the right to high status and high compensation because…. well, just because.
The Curiously Recurring Scramble Pattern
It’s funny to watch software development teams hack away for months building a just barely working patch-quilt monster that they can hardly understand themselves – and then scramble at the last minute generating design documents for some big upcoming management design review or “independent” auditor dog and pony show (woof woof!).
In this Curiously Recurring Scramble Pattern (CRSP), a successful attempt to avoid the labor of thinking is made as developers frantically sprinkle Doxygen annotations throughout the code and/or load the beast into a reverse engineering tool that mechanistically generates UML diagrams to model the as-built mess. It goes without saying that the tool’s “verbose” mode is selected in order to obscure meaning and promote the illusion of high falutin’ sophistication. Of course, all of this is a waste of time (= $$$$) because the dudes doing the reviewing (self-important managers and bureaucratic auditors) don’t want to understand a thing.
When the review or audit does take place; a couple of cream puff questions and comments are bantered about, check boxes are ticked off, a couple of superficial “action items” are generated, and the whole lovefest is rubber-stamped as a great success. Whoo Hoo, we rock!
Without a doubt, you and I have never been culturally forced to participate in an instantiation of the CRSP. We are above that nonsense, right? We do something like this.
“A meeting is a refuge from the dreariness of labor and the loneliness of thought.” – Bernard Baruch
void Manager::pitchInWhereNeeded(const Work& w){}
Unless you’re a C++ programmer, you probably won’t understand the title of this post. It’s the definition of the “pitchInWhereNeeded” member function of a “Manager” class. If you look around your immediate vicinity with open eyes, that member function is most likely missing from your Manager class definition. If you’re a programmer, oops, I mean a software engineer, it’s probably also missing from your derived “SoftwareLead“, “SoftwareProjectManager“, and “SoftwareArchitect” classes too.
As the UML-annotated figure below shows, in the early twentieth century the “pitchInWhereNeeded” function was present and publicly accessible by other org objects. On revision number 1 of the “system”, as signaled by the change from “+” to “-“, its access type was changed to private. This seemingly minor change broke all existing “system” code and required all former users of the class to redesign and retest their code. D’oh!
On the second revision of the Manager class, this critical, system-trust-building member function mysteriously disappeared completely. WTF?. This rev 2 version of the code didn’t break the system, but the system’s responsiveness decreased since private self -calls by manager objects to the “pitchInWhereNeeded” function were deleted and more work was pushed back into the “other” system objects. Bummer.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 