Archive
A Costly Mistake?
Assume the following:
- Your flagship software-intensive product has had a long and successful 10 year run in the marketplace. The revenue it has generated has fueled your company’s continued growth over that time span.
- In order to expand your market penetration and keep up with new customer demands, you have no choice but to re-architect the hundreds of thousands of lines of source code in your application layer to increase the product’s scalability.
- Since you have to make a large leap anyway, you decide to replace your homegrown, non-portable, non-value adding but essential, middleware layer.
- You’ve diligently tracked your maintenance costs on the legacy system and you know that it currently costs close to $2M per year to maintain (bug fixes, new feature additions) the product.
- Since your old and tired home grown middleware has been through the wringer over the 10 year run, most of your yearly maintenance cost is consumed in the application layer.
The figure below illustrates one “view” of the situation described above.
Now, assume that the picture below models where you want to be in a reasonable amount of time (not too “aggressive”) lest you kludge together a less maintainable beast than the old veteran you have now.
Cost and time-wise, the graph below shows your target date, T1, and your maintenance cost savings bogey, $75K per month. For the example below, if the development of the new product incarnation takes 2 years and $2.25 M, your savings will start accruing at 2.5 years after the “switchover” date T1.
Now comes the fun part of this essay. Assume that:
- Some other product development group in your company is 2 years into the development of a new middleware “candidate” that may or may not satisfy all of your top four prioritized goals (as listed in the second figure up the page).
- This new middleware layer is larger than your current middleware layer and complicated with many new (yet at the same time old) technologies with relatively steep learning curves.
- Even after two years of consumed resources, the middleware is (surprise!) poorly documented.
- Except for a handful of fragmented and scattered powerpoint files, programming and design artifacts are non-existent – showing a lack of empathy for those who would want to consider leveraging the 2 year company investment.
- The development process that the middleware team is using is fairly unstructured and unsupervised – as evidenced by the lack of project and technical documentation.
- Since they’re heavily invested in their baby, the members of the development team tend to get defensive when others attempt to probe into the depths of the middleware to determine if the solution is the right fit for your impending product upgrade.
How would you mitigate the risk that your maintenance costs would go up instead of down if you switched over to the new middleware solution? Would you take the middleware development team’s word for it? What if someone proposed prototyping and exploring an alternative solution that he/she thinks would better satisfy your product upgrade goals? In summary, how would you decrease the chance of making a costly mistake?
Open Kimono
I continue to be enamored and awed by the way the leadership at zappos.com operates the company. I’m convinced that they’re the real deal. They’ve obtained a level of business nirvana that balances altruism with profitability which is perhaps unmatched by any other company on earth – except for maybe Semco.
Sadly, even though Zappos continuously and willingly opens its kimono to all those who care to learn about how they nurture and sustain their success, the Zappos operational model probably won’t go very far. The endless sea of power-obsessed dinosaurs that rule the corpo roost are too clever (cleverness is how they got into the protected nest in the first place).
The most common refrain for rejecting any attempt to emulate Zappos “best practices” will be: “none of that stuff will work here because our business is totally different“. These will be the words of wisdom uttered from the same moo-herd potty mouths that repetitively proclaim “customers are number one and our employees are our most valuable asset“. Blah, blah, blah. Yawn, yawn, yawn. BS, BS, BS.
Cog Diss
If interested, check out Mary Jo Foley‘s hindsight blog post regarding Microsoft CEO Steve Ballmer‘s screw-up on the Vista fiasco: Feedback Failure. Mary laments:
“As a result, I’m left wondering about Vista, as many are/were about the current financial crisis: Why didn’t anyone inform us sooner of the impending meltdown? Weren’t there warning signs? Where was everybody?”
Surely Mary, you’re joking, right? You’re wondering where everybody was and why nobody informed us? In short, at least some Microsoft DICS who weren’t deeply and personally invested in the Vista project either:
- knew about the impending doom but were afraid to speak up,
- did have the courage to speak up but were “ignored” or slapped down,
- “disconnected and distanced” themselves from the project because they didn’t give a chit about it (apathy)
Those who were fully ensconced in the quagmire were blinded by the light. They suffered from the common and pervasive human malady called “cognitive dissonance“. Cog Diss is where you convince yourself that you’re looking at a pile of gold when in reality you’re staring at a pile of poop. However, deep down, you sense the mismatch and experience uneasy feelings as a result.
All the dysfunctional behaviors described above are caused by living life too long within the confines of an unchanging and soul-busting CCH bureaucracy.
Stunning, But Not Surprising
Suppose you had an innately complex product to sell. Now suppose that a potential customer comes up to you and asks for a user’s starter guide to help him/her understand your product for the purpose of making a buy decision. Would you tell that customer “We’re short-handed and have schedules to meet, so write It yourself!“? WTF!
For people who work in CCH bureaucracies but don’t know it (or who do know it, but conveniently ignore it and don’t do squat to dissolve it), this behavior between internal groups is ubiquitous, systemic, and so pervasive that it’s taken for granted. It’s stunning, but not surprising.
Incremental Watts
I don’t know which name I like better, Watts Wacker or Soupy Sales, but this post is about Watts. Watts Wacker is a CEO and futurist who uttered one of my favorite quotes:
You can’t increment your way into the future – Watts Wacker
I think this quote is directed toward leaders of cushy, static, and stanky CCH companies who are so afraid of the future that they move by inches at a time in passive response to external changes. The only way to leapfrog your competitors, since they’re just as afraid as you and are inching along like molassess running up hill, is to make a disruptive leap into the future.
It takes revolutionaries to trigger disruptive leaps into the unknown. Someone (actually, two people) with an innocent but assuredly incremental mindset recently said to me: “Revolutionaries are usually lined up in front of a wall and shot“. My response was “that’s why there are so few of them“. Bummer.
My OSEE Experience
Intro
A colleague at work recently pointed out the existence of the Eclipse org’s Open System Engineering Environment (OSEE) project to me. Since I love and use the Eclipse IDE regularly for C++ software development, I decided to explore what the project has to offer and what state it is in.
The OSEE is in the “incubation” stage of development, which means that it is not very mature and it may require a lot more work before it has a chance of being accepted by a critical mass of users. On the project’s main page, the following sentences briefly describe what the OSEE is:
The Open System Engineering Environment (OSEE) project provides a tightly integrated environment supporting lean principles across a product’s full life-cycle in the context of an overall systems engineering approach. The system captures project data into a common user-defined data model providing bidirectional traceability, project health reporting, status, and metrics which seamlessly combine to form a coherent, accurate view of a project in real-time.
The feature list is as follows:
- End-to-end traceability
- Variant configuration management
- Integrated workflows and processes
- A Comprehensive issue tracking system
- Deliverable document generation
- Real-time project tracking and reporting
- Validation and verification of mission software
I don’t know about you, but the OSEE sounds more like an integrated project management tool than a system engineering toolset that facilitates requirements development and system design. Promoting the product ambiguously may be intended to draw in both system engineers and program managers?
The OSEE is not a design-by-committee, fragmented quagmire, it’s a derivation of a real system engineering environment employed for many years by Boeing during the development of a military helicopter for the US government. Like IBM was to the Eclipse framework, Boeing is to the OSEE.
“Standardization without experience is abhorrent.” – Bjarne Stroustrup
Download, Install, Use
The figure below shows a simple model of the OSEE architecture. The first thing I did was download and install the (19) Eclipse OSEE plugins and I had no problem with that. Next, I tried to install and configure the required PostgresQL database and OSEE application and OSEE arbitration servers. After multiple frustrating tries, and several re-reads of the crappy install documentation, I said WTF! and gave up. I did however, open and explore various OSEE related Eclipse perspectives and views to try and get a better feel for what the product can do.
As shown in the figure below, the OSEE currently renders four user-selectable Eclipse perspectives and thirteen views. Of course, whenever I opened a perspective (or a view within a perspective) I was greeted with all kinds of errors because the OSEE back end kludge was not installed correctly. Thus, I couldn’t create or manipulate any hypothetical “system engineering” artifacts to store in the project database.
Conclusion
As you’ve probably deduced, I didn’t get much out of my experience of trying to play around with the OSEE. Since it’s still in the “incubation” stage of development and it’s free, I shouldn’t be too harsh on it. I may revisit it in the future, but after looking at the OSEE perspective/view names above and speculating about their purposes, I’ve pre-judged the OSEE to be a heavyweight bureaucrat’s dream and not really useful to a team of engineers. Bummer.
Surprise! GM Is Still Hosed
In a followup to my first post on GM’s initial BS attempt to dismantle their horrendous do-nothing-but-line-management’s-pocket-with-dough Command And Control Hierarchy (CCH), I submit this freshly minted AP article. It describes yet another management shake up at post-bankruptcy, taxpayer-money-sucking GM. The “new” (LOL!) leadership continues to pray that the feeble and well worn tradition of sloganeering and cajoling will stave off annihilation. Geeze, these elite hierarchs are really doing quite a job earning their seven figure paychecks, dontcha think?
In announcing a sudden management overhaul yesterday, GM chairman and acting CEO Ed Whitacre Jr. was speaking Lutz’s words when he told employees that the bureaucracy needs to end and they can take reasonable risks without fear of being fired.
“We want you to step up. We don’t want any bureaucracy,’’ Whitacre said to about 800 GM workers. “We’re not going to make it if you won’t take a risk,’’ he said in the address, which was broadcast to employees worldwide on the Internet.
Uh, yes massa CEO, we’ll do whatever you say, dear leader. We sincerely believe that you’re a man of high integrity and impeccable credentials who speaks the truth and will lead us to the promised land. We’ll gladly storm the machine gun nests that guard the status quo for you. Blech.
Whitacre, 68, who has been frustrated with the pace of change, appointed the 77-year-old Lutz as a top adviser, creating an alliance of hard-charging veteran executives to lead the troubled company.
Yeah, that’ll do it. A 145 year duo of machine age, assembly line thinkers who probably don’t know WTF “WTF” means. Social intra-networking? Corpo-wide sharing of accessible and findable information? Sincere collaboration within and between layers of rank and status? Transparency, Authenticity, and Openness? Sorry to be so negative, but not a chance.
Sadly, I await the next big GM makeover and press release.
“Overburdened”
Are any words needed to elaborate on the blasphemous message that I’m trying to convey in the dorky graphic below? If so, gimme a shout out.
Committee Performance Metrics
A favorite and frequent activity undertaken by corpocrats everywhere is the formation of committees and special task forces to “aggressively” tackle and solve pressing org problems that are negatively affecting the performance of the corpocracy’s DICforce. The typical cycle of events is as follows:
- 1) The committee of elites is formed to “help” the DICforce do their jobs better.
- 2) After: a) several months of meetings with half-assed attendance, b) infinite BS sessions where nothin’ of substance is produced or propagated downward, c) there’s no detectable performance improvement from those dwelling in the cellar, and d) gobs of money have been consumed, the committee sponsor (a.k.a. the money supplier) asks for measures of performance to judge whether his/her investment is paying off.
- 3) The committee conjures up some BS “camouflage” metrics that feign problem solving prowess and progress (see the figure below for examples).
- 4) The sponsor buys into the BS set of metrics and the resource drain continues.
- 5) Go to step 2).
You’d think that a meaningful metric could be obtained by periodically polling the people that the elite committee is supposed to be helping – the DICforce. Do you think many committees, councils, task forces, centers of excellence, yada-yada-yada, do this? If not, why do you think that is the case?
Almost Anything Can Work, BUT….
Almost any well known management technique/process for improving corpo performance (e.g. six-sigma, BPR, MBO, task forces, brainstorming, core competencies, SWOT analysis, etc) that was mildly successful in a handful of cases can work. BUT, it takes real leadership to make them work; and that’s why they don’t work.
So WTF is real leadership? I make stuff up and I’m not fit to lead anyone or anything, so don’t ask me :^)
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 