Archive
Can’t And May
Well Architected
The UML component diagram below attempts to model the concept and characteristics of a well architected software-intensive system.
What other attributes of well architected/designed systems are there?
Without a sketched out blueprint like this, if you start designing and/or coding and cobbling together components randomly selected out of the blue and with no concept of layering/balancing, the chance that you end up will a well architected system is nil. You may get it “working” and have a nice GUI pasted on top of the beast, but under the covers it will be fragile and costly to extend/maintain/debug – unless a miracle has occurred.
If you or your management don’t know or care or are “allowed” to expose, capture, and continuously iterate on that architecture/design dwelling in your faulty and severely limited mind and memory, then you deserve what you get. Sadly, even though they don’t deserve it, every other stakeholder gets it too: your company, your customers, your fellow downstream maintainers, etc….
Transparency, Meritocracy, and Collaboration
When Red Hat Inc. went public with much fanfare 12 years ago, I thought there was no way the company would make money on the Linux open source operating system. As usual, BD00 was outright wrong. This MIX article by Red Hat VP Jackie Yeaney, “Democratizing the Corporate Strategy Process at Red Hat”, may explain one reason why.
In her article, Ms. Yeaney shares all the details of the company’s strategic development process along with some performance metrics that demonstrate its effectiveness. Here are some snippets that I found refreshingly interesting.
“When I first started working with Red Hat at the beginning of 2008, it was readily apparent that the traditional corporate strategy development process would simply not work in an open source company where transparency, meritocracy, and collaboration were prized elements of the culture.”
“While many might view it is as a disadvantage or a time sink to systematically gather feedback from across the company, at Red Hat it’s a core part of our competitive advantage.”
“We built an internal wiki that leaders of each exploration team used to organize their thoughts and ideas out in the open where any employee could make comments or suggestions. Anyone who was particularly interested could read about the progress, and add their ideas or volunteer to help (and many did).”
“This information-gathering dialog lasted about 5 months. We communicated our progress along the way through regular updates at company meetings, through email, and on the Intranet. The strategy team leaders posted status updates to the wiki and replied to comments on their team’s internal blog. Jim hosted a company-wide online chat session where associates could ask him any question they wanted to about the strategy process (or anything else that was on their minds), and team leads communicated key updates through company-wide announcements and discussions.”
The likelihood that you have any clue of how business strategy is created in your org is low. The likelihood that you’re given the chance to actively participate in the process is even lower, dontcha think? Instead of being “engaged with” you’re simply “communicated to“, no?
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.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 