Archive
The Mythical Dual Ladder
The figure below shows a typical skill development timeline. At “t=0” ignorance reigns and learning begins. After a period of learning/applying/practicing, which varies widely from person to person, the status of “Novice” is achieved. After yet another period of learning/applying/practicing, the transition from novice to amateur occurs – and so on up to the level of master and beyond.
The key attribute to focus on in the timeline is the change in length of time required to transition from one level of competence to the next. It doesn’t stay the same or get smaller, it gets longer. Thus, with exceptions of course, the time required to transition from expert to master is greater than the time to transition from amateur to expert.
To remain viable, every product development company requires a critical mass of expertise in the core technologies that comprise the soul of its product portfolio. World class companies actively “nourish and catalyze” the novice-to-expert pipeline via continuous investments in targeted training and conference attendance. Average companies neither nourish or catalyze the pipeline, they “hope for the best” in that their employees will keep up with technology advancements on their own time. In the extreme, CLORGS and DYSCOs unconsciously “toxify and inhibit” the pipeline – if one is even recognized at all. They do this by implicitly encouraging experts to move out of technology and into management via higher compensation and stature for those experts/masters who jump from the mythical technical ladder to the coveted management ladder.
Well Known And Well Practiced
It’s always instructive to reflect on project failures so that the same costly mistakes don’t get repeated in the future. But because of ego-defense, it’s difficult to step back and semi-objectively analyze one’s own mistakes. Hell, it’s hard to even acknowledge them, let alone to reflect on, and to learn from them. Learning from one’s own mistake’s is effortful, and it often hurts. It’s much easier to glean knowledge and learning from the faux pas of others.
With that in mind, let’s look at one of the “others“: Hewlitt Packard. HP’s 2010 $1.2B purchase of Palm Inc. to seize control of its crown jewel WebOS mobile operating system turned out to be a huge technical and financial and social debacle. As chronicled in this New York Times article, “H.P.’s TouchPad, Some Say, Was Built on Flawed Software“, here are some of the reasons given (by a sampling of inside sources) for the biggest technology flop of 2011:
- The attempted productization of cutting edge, but immature (freeze ups, random reboots) and slooow technology (WebKit).
- Underestimation of the effort to fix the known technical problems with the OS.
- The failure to get 3rd party application developers (surrogate customers) excited about the OS.
- The failure to build a holistic platform infused with conceptual integrity (lack of a benevolent dictator or unapologetic aristocrat).
- The loss of talent in the acquisition and the imposition of the wrong people in the wrong positions.
Hmm, on second thought, maybe there is nothing much to learn here. These failure factors have been known and publicized for decades, yet they continue to be well practiced across the software-intensive systems industry.
Obviously, people don’t embark on ambitious software development projects in order to fail downstream. It’s just that even while performing continuous due diligence during the effort, it’s still extremely hard to detect these interdependent project killers until it’s too late to nip them in the bud. Adding salt to the wound, history has inarguably and repeatedly shown that in most orgs, those who actually do detect and report these types of problematiques are either ignored (the boy who cried wolf syndrome) or ostracized into submission (the threat of excommunication syndrome). Note that several sources in the HP article wanted to “remain anonymous“.
Related articles
- Sluggish code and HP power plays blamed for webOS’ failure (slashgear.com)
- Leaks: webOS struggled with poor staff, fundamental design (electronista.com)
- Why WebOS Failed (technologizer.com)
Care-full
Check out this tweet from Stefan Stern:
21st century leaders “get” this recipe for building two way trust and respect. 20th century leaders demand that followers (willing or coerced) unconditionally care about what the leader wants. To them, establishing and nurturing a symmetrical, two-way caring relationship is not in the cards.
Quid pro quo Clarisse…. Quid pro quo – Hannibal Lecter
Amity and Enmity I
If you’re looking to tax your mind to the fullest and explore a novel and rigorous approach to sociological science, check out Dr. Rudolf Starkermann’s new web site, “Amity and Enmity”. The site was recently placed online by e-colleague Byron Davies and the wonderful story behind the site’s creation deserves its own separate, forthcoming blog post (Amity and Enmity II).
By syntegrating social concepts (e.g. willpower, consciousness, attitude, the unconscious, goal-seeking) with the concepts and mathematics from the engineering discipline of automatic control theory (e.g. amplification, error signal, feedback, transfer functions, stability, homeostasis, PID control), Dr. Starkermann models a living social “unit” as a self-realization seeking loop that is influenced by other social units via conscious observations/actions and subconscious “attitudes“. A social unit can represent a person, group, institution, or even a nation.
The first figure below shows a simplified first order model of the Starkermann social dualism. The second figure exposes the model’s intricately dense complexity. If you painstakingly trace out and count the number of loops in the socially coupled system, you’ll find that there are 12 of them. D’oh!
Did you have trouble finding the loops in the dualism? Well, don’t fret because here they are:
Double D’oh!
Even if you’re not an engineer who’s taken a course in automatic controls theory, you may get something out of “Amity And Enmity“. Dr. Starkermann valiantly tries to make his work accessible to the non-mathematical layman via many careful and empathic explanations throughout the treatise.
By fixing some parameters and varying others, Rudy has “calculated the behavior” of the dualism in a multitude of scenarios in order to discover what his models reveal about amity and enmity. Here’s a sample list of his “stark” conclusions:
- Nature favors enmity and sets amity second.
- Hostility is fast, consent is slow.
- The faster a “unit” thinks, acts, the larger its willpower can be before it runs into instability and the better and faster it reaches its goal.
- The probability is almost non-existent that a hate-relation changes into a friendship.
- Hostility is solid. Friendship is fragile.
While sloowly making my way through the dense thicket that is “Amity And Enmity“, the following quote keeps coming to mind:
All models are wrong, but some are useful – George Box
Finish Line
Phew, I think I did it! I think I wrote and published 365 ridiculous blog posts in 2011. I successfully conquered the wordpress.com “post a day 2011” challenge. Woot!
Alas, it wasn’t really that hard; I never shut up, I’m a hopeless ruminator, and I’m so full of crap that the words and dorky pictures seem to flow effortlessly out of nowhere and onto the e-canvas.
So, since I’m sure that I’m the only one who accomplished this great feat of daring, where is my freakin’ ONE……….. MILLION……………….. DOLLARS?
As a note of thanks, I gotta give a huge-uh shout out to the brilliant and caring people at automattic who created and constantly innovate on the wordpress web site platform. It’s a joy to work with your product because it virtually disappears into the background when I’m concocting my dorky posts. I hope the profits are rollin’ in, and keep up the great work!
BMs Of The Year
Since BD00 is a bombastic and boisterous blasphemer of the “B” word, I just HAD to meta-blog about this infoworld blog post after I stumbled upon it: “The tech industry’s biggest bozos of 2011”.
And the winners are…..
- Léo Apotheker: former HP CEO
- Mark Zuckerberg: current Facebook CEO
- Reed Hastings: current Netflix CEO
- Jim Basillie & Mike Lazardis: current co-CEOs of RIM
Because Netflix is one of the companies on my faves list (and I’m a stockholder!), I’m really bummed about the Hastings-Netflix fiasco. Since I think Mr. Hastings and Netflix will recover from the faux pas, I’m keeping them on the list.
Graphics, Text, And Source Code
On the left, we have words of wisdom from Grady Booch and friends. On the right, we have sage advice hatched from the “gang of four“. So, who’s right?
Why, both groups are “right“. If all you care about is “recording the design in source code“, then you’re “wrong“…
If you’re a software “anything” (e.g. architect, engineer, lead, manager, developer, programmer, analyst) and you haven’t read these two classics, then either read them or contemplate seeking out a new career.
But wait! All may not be lost. If you think object orientation is obsolete and functional programming is the way of the future, then forget (almost) everything that was presented in this post.
What Would You Do?
Assume that you’re working on a software system comprised of a set of core and peripheral application components. Also assume that these components rest on top of a layered set of common system libraries.
Next, assume that you remove some functionality from a system library that you thought none of the app components are using. Finally, assume that your change broke multiple peripheral apps, and, after finding out, the apps writer asked you nicely to please restore the functionality.
What would you do?
Capers And Salmon
I like capers with my salmon. In general, I also like the work of long time software quality guru Capers Jones. In this Dr. Dobb’s article, “Do You Inspect?”, the caped one extols the virtues of formal inspection. He (rightly) states that formal, Fagan type, inspections can catch defects early in the product development process – before they bury and camouflage themselves deep inside the product until they spring forth way downstream in the customer’s hands. (I hate when that happens!)
The pair of figures below (snipped from the article) graphically show what Capers means. Note that the timeline implies a long, sequential, one-shot, waterfall development process (D’oh!).
That’s all well and dandy, but as usual with mechanistic, waterfall-oriented thinking, the human aspects of doing formal inspections “wrong” aren’t addressed. Because formal inspections are labor-intensive (read as costly), doing artifact and code inspections “wrong” causes internal team strife, late delivery, and unnecessary budget drain. (I hate when that happens!)
An agile-oriented alternative to boring and morale busting “Fagan-inspections-done-wrong” is shown below. The short, incremental delivery time frames get the product into the hands of internal and external non-developers early and often. As the system grows in functionality and value, users and independent testers can bang on the system, acquire knowledge/experience/insight, and expose bugs before they intertwine themselves deep into the organs of the product. Working hands-on with a product is more exhilarating and motivating than paging through documents and power points in zombie or contentious meetings, no?
Of course, it doesn’t have to be all or nothing. A hybrid approach can be embraced: “targeted, lightweight inspections plus incremental deliveries with hands-on usage”.
PPPP Invention
In “Engineering A Safer World“, Nancy Leveson uses the autopilot example below to illustrate the extra step of complexity that was introduced into the product development process with the integration of computers and software into electro-mechanical system designs.
In the worst case, as illustrated below, the inter-role communication problem can be exacerbated. Although the “gap of misunderstanding” from language mismatch is always greatest between the Domain Expert and the Software Architect, as more roles get added to the project, more errors/defects are injected into the process.
But wait! It can get worse, or should I say, “more challenging“. Each person in the chain of cacophony can be a member of a potentially different group with conflicting goals.
But wait, it can get worser! By consciously or unconsciously adding multiple managers and executives to the mix, you can put the finishing touch on your very own Proprietary Poop Producing Process (PPPP).
So, how can you try to inhibit inventing your very own PPPP? Two techniques come to mind:
- Frequent, sustained, proactive, inter-language education (to close the gaps of misunderstanding).
- Minimization of the number of meddling managers (and especially, pseudo-manager wannabes) allowed anywhere near the project.
Got any other ideas?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 