Archive
Context Switching
“There is time enough for everything in the course of the day, if you do but one thing at once, but there is not time enough in the year, if you will do two things at a time.” – Lord Chesterfield (1740)
Study after study after study have shown that, due to the natural imperfections built into human memory, multitasking is inefficient and unproductive compared to single-tasking. The bottom line is that humans suck at multitasking. Unlike computers, when humans switch from doing one thought-intensive task to another, the clearing out of memory content from the current task and the restoration of memory content from the previous task greatly increases the chances of errors and mistakes being made.
So why do managers multitask all the time, and why do unenlightened companies put “multitasking prowess” on their performance review forms? Ironically, they do it to reinforce an illusion that multitasking is a key contributor of great productivity and accomplishment. When a “performance reviewer” sees the impressive list of superficial accomplishments that a multitasker has achieved and compares it to a measly list of one or two deep accomplishments from a single-tasker, an illusion of great productivity is cemented in the mind of the ignorant reviewer. Most managers, huge multitaskers themselves, and clueless to the detrimental effects of the malady on performance, tend to reward fellow multitaskers more than non-multitasking “slackers“. Bummer for all involved; especially the org as a whole.
The Rise Of The “ilities”
The title of this post should have been “The Rise Of Non-Functional Requirements“, but that sounds so much more gauche than the chosen title.
As software-centric systems get larger and necessarily more complex, they take commensurately more time to develop and build. Making poor up front architectural decisions on how to satisfy the cross-cutting non-functional requirements (scalability, distribute-ability, response-ability (latency), availability, usability, maintainability, evolvability, portability, secure-ability, etc.) imposed on the system is way more costly downstream than making bad up front decisions regarding localized, domain-specific functionality. To exacerbate the problem, the unglamorous “ilities” have been traditionally neglected and they’re typically hard to quantify and measure until the system is almost completely built. Adding fuel to the fire, many of the “ilities” conflict with each other (e.g. latency vs maintainability, usability vs. security). Optimizing one often marginalizes one or more others.
When a failure to meet one or more non-functional requirements is discovered, correcting the mistake(s) can, at best, consume a lot of time and money, and at worst, cause the project to crash and burn (the money’s gone, the time’s gone, and the damn thang don’t work). That’s because the mechanisms and structures used to meet the “ilities” requirements cut globally across the entire system and they’re pervasively weaved into the fabric of the product.
If you’re a software engineer trying to grow past the coding and design patterns phases of your profession, self-educating yourself on the techniques, methods, and COTS technologies (stay away from homegrown crap – including your own) that effectively tackle the highest priority “ilities” in your product domain and industry should be high on your list of priorities.
Because of the ubiquitous propensity of managers to obsess on short term results and avoid changing their mindsets while simultaneously calling for everyone else to change theirs, it’s highly likely that your employer doesn’t understand and appreciate the far reaching effects of hosing up the “ilities” during the front end design effort (the new age agile crowd doesn’t help very much here either). It’s equally likely that your employer ain’t gonna train you to learn how to confront the growing “ilities” menace.
Just The Facts Ma’am
The other day, I had a confrontation with an anointed leader. (Being the insensitive and self-righteous jerk that I am, and supposedly incapable of being a leader myself, that happens a lot). After I made some normally “undiscussable” assertions as to the poor leadership behavior (more like NO leadership behavior) being exhibited by my confrontee, he/she accused me of not having all the facts. My counter was, “You’re absolutely right, but when does anyone have ALL the facts before they make a judgment regarding a FUBAR situation or a person’s behavior?“.
How does one know when ALL the facts have been discovered? Is there such a thing as ALL the facts? Even if ALL the facts can be unearthed, is it a foregone conclusion that every fact will always interpreted the same way by all people? Can words or, for the fellow engineers in the house, equations convey any universal truth, or are they just approximations?
Obfuscators And Complexifiers
Since I’m pretty unsuccessful at it, one of my pet peeves is having to deal with obfuscators and complexifiers (OAC). People who chronically exhibit these behaviors serve as formidable obstacles to progress by preventing the right info from getting to the right people at the right time. “They” do so either because they’re innocently ignorant or because they’re purposefully trying to camouflage their lack of understanding on the topic of discussion for fear of “looking bad”. I have compassion for the former, but great disdain for the latter – blech!
The condundrum is, in CCH corpocracies, there’s an unwritten law that says DICs aren’t “allowed” to publicly expose purposeful OACs if the perpetrators are above a certain untouchable rank in the infallible corpo command chain. In extremely dysfunctional mediocracies, no one is allowed to call any purposeful OAC out onto the mat, regardless of where the dolt is located in the tribal caste system. In either case, retribution for the blasphemous transgression is always swift, effective, and everlasting. Bummer.
Unscalable Orgs
My friend Byron Davies sent me a link to this 3 minute MIT Media Lab video in which associate Media Lab Director Andy Lippman challenges us to recognize four common flaws plaguing all of our institutions. Obtaining a new awareness and understanding of the plague is the first step toward meaningful redesign.
According to Lippman, the top four reasons for organizational decline are:
- They’re out of scale – they’ve grown too big to perform in accordance with their original design
- They’re monocultures – they all act the same
- They’re opaque – nobody from within or without understands how they freakin’ work
- They’ve lost their original mission – A summation of the previous three reasons.
Because of the pervasive institutional obsession for growth, Lippman seems to think that solving the scaling problem through the development of nested communities is the most promising strategy for halting the decline.
Staffing Profiles
The figure below shows the classic smooth and continuous staffing profile of a successful large scale software system development project. At the beginning, a small cadre of technical experts sets the context and content for downstream activity and the group makes all the critical, far reaching architectural decisions. These decisions are documented in a set of lightweight, easily accessible, and changeable “artifacts” (I try to stay away from the word “documentation” since it triggers massive angst in most developers).
If the definitions of context and content for the particular product are done right, the major incremental development process steps that need to be executed will emerge naturally as byproducts of the effort. An initial, reasonable schedule and staffing profile can then be constructed and a project manager (hopefully not a BM) can be brought on-board to serve as the PHOR and STSJ.
Sadly, most big system developments don’t trace the smooth profiling path outlined above. They are “planned” (if you can actually call it planning) and executed in accordance with the figure below. No real and substantive planning is done upfront. The standard corpo big bang WBS (Work Breakdown Structure) template of analysis/SRR/design/PDR/CDR/coding/test is hastily filled in to satisfy the QA police force and a full, BM led team is blasted at the project. Since dysfunctional corpocracies have no capacity to remember or learn, the cycle of mediocre (at best) performance is repeated over and over and over. Bummer.
Nested Bureaucracies
By definition, ineffective bureaucracies (are there any effective ones?) consume more resources than they produce in equivalent value to their users/consumers. According to Russell Ackoff, the only way an ineffective bureaucracy can remain in place is by external subsidization that is totally disconnected with its performance. In other words, bureaucracies rely on clueless sugar daddies supplying them with operating budgets without regard to whether they are contributing more to “the whole” than they are withdrawing. Unchecked growth of internal bureaucracies siphons off profits and it can, like a cancer, kill the hosting org.
The figure below shows a simplistic bird’s eye view of an American economic system dominated by CCH bureaucracies. The irony in this situation is that even though the Corpo Granite Heads (CGH) in charge of the CCHs are staunch supporters of the distributed free market model which rewards value creation and punishes under-performance, they run their own orgs like the old Soviet Union. Ala GM and most huge government departments, they operate as centralized, nested bureaucracies where the sloth at the top trickles money down to the mini-bureaucracies below – without regard to value produced.
Bureaucracies, being what they are and seeking to survive at all costs, jump through all kinds of hoops to camouflage their worthlessness and keep the money flowing down from the heavens. Since the cabal at the top is too ignorant to recognize that it’s a bureaucracy in its own right, it’s an expert camouflage spinner to the corpocracy’s stakeholders (who gobble up the putrid camouflage with nary a whimper) and it sucks much more out of the corpo coffers than it adds value without being “discovered and held accountable”. In the worst nested bureaucracies, none of the groups in the hierarchy, from the top layer all the way down the tree to the bottom layer, produce enough value to offset their ravenous appetite for resources. They collapse under the weight of their own incompetence and then wonder WTF happened. From excellence to bankruptcy in 24 hours.
The really sad part is that before a bureaucracy auto-snaps into place, it wasn’t a bureaucracy in the first place. Everybody in the “startup” contributed more than they withdrew from the whole, and the excess value translated into external sales and internal profits. Like the boiled frog story, the transformation into a bureaucracy was slooow and undetectable to the CGHs in charge. Bummer.
The answer to this cycle of woe, according to Ackoff, is for the leaders in an org to operate the whole (including themselves) as a system of nested free markets, where each internal consumer of services gets to choose whether it will purchase needed services from internal groups, or external groups. Each internal group, including the formerly untouchable head shed, must operate as a measurable profit and loss center. Mr. Ackoff describes all the details of nested free market operation, including responses to many of the “it can’t work because of……” elite whiners, in his insightful book: Ackoff’s Best. Check it out, if you dare.
Zero Cost Risk Mitigation
Why do managers and executives require project technical leaders to develop comprehensive “risk mitigation plans” while at the same time fully expecting the plans to cost nothing (no people, no time, no money). Formal and rigorously filled out risk registers (with no cost column) make it look like due diligence is being performed, but it’s all a ruse to sustain the illusion that management is “in control”. WTF?
Both Ends Of The Spectrum
Why does it seem that both the best engineers and the worst engineers always gravitate towards becoming managers? Because of a lack of training in the art of humanistic influence and true leadership skills, they usually (but not always) end up turning into STSJ BMs. The real tragedy is the continuous loss of the best engineers into the ranks of corpo elitism. Why? Because the revenue generating products and services they leave in the dust for fame and fortune suffer the consequences of their departure. Thus, the whole company suffers. Bummer.
A Unique Core Value
Unless they’ve been cleverly camouflaging their sinister ways from the world’s prying eyes, the people at Zappos.com truly do live and breathe their corporate values every day. My favorite, and perhaps most unique Zappos core value is number three: “Create Fun and a Little Weirdness“. Here’s how the Zappos team describes this precious gem from the viewpoint of their “Core Values Frog” (CVF):
Our CVF has a sense of humor; he knows that it’s good to laugh at yourself every once in a while. Work shouldn’t be synonymous with drudgery; CVF can find fun and weirdness even when the rubber meets the road and we’re getting lots done. Being a little weird requires being a little innovative, and CVF is always looking for a chance to fully engage in his work and bring out the fun and weird side of it.
In tribute to CV #3, the people at Zappos have held impromptu parades, hula hoop contests, head shavings, and all kinds of other weird events both on and off the company’s premises.
Of course, Zappos is just a lowly $1B retail shoe company and your business is much more different, respectful, and prestigious. Thus, it’s patently obvious that Zappos core value #3 can’t possibly work in your corpo palace. Right?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 