Archive
Your Operational Configuration
Which system configuration do you prefer? Which system configuration is most prevalent in nature? In the “civilized” world? What’s your operating configuration, and do you have just one?
Idealized Design
Russell Ackoff describes the process of “Idealized Design” as follows:
In this process those who formulate the vision begin by assuming that the system being redesigned was completely destroyed last night, but its environment remains exactly as it was. Then they try to design that system with which they would replace the existing system right now if they were free to replace it with any system they wanted.
The basis for this process lies in the answer to two questions. First, if one does not know what one would do if one could do whatever one wanted without constraint, how can one possibly know what to do when there are constraints? Second, if one does not know what one wants right now how can one possibly know what they will want in the future?
An idealized redesign is subject to two constraints and one design principle: technological feasibility and operational viability, and it is required to be able to learn and adapt rapidly and effectively.
So, are you ready to blow up your system? Nah, tis better to keep the unfathomable, inefficient, ineffective beast (under continuous assault from the second law of thermo) alive and unwell. It’s easier and less risky and requires no work. And hey, we can still have fun complaining about it.
Quid Pro Quo
Forget about the superficial, ceremonial, “empoyee survey” that is often ignored and quickly forgotten. Wouldn’t it be a great quid-pro-quo move to “allow” each employee in an org to formally judge his/her organization’s behavior, I mean performance, once a year? The content of the review form could be similar to the one in which the employee him/herself is evaluated. After filling out a set of multiple choice questions and allowing for free-form input to justify the selections, an overall behavioral rating could close the review. The rating could be selected from an enumerated list similar to this:
- Exceeds Expectations
- Meets Expectations
- Needs Improvement
- Unacceptable
Based on the final rating, instead of giving the org a merit increase, the employee would communicate the level of commitment that he/she will really provide in the coming year:
- Total Commitment
- Half-assed Commitment
- Feigned Total Commitment
Of course, much like parents and teachers are expected by “the entrenched social system” to evaluate their children, but not vice-versa, this idea doesn’t have a chance of making it into the mainstream. Nevertheless, BD00 speculates that the practice is done somewhere as part of a continuous improvement initiative?
Pragmatic?
Still Applicable Today
Note: This graphic was clipped out of Bill Livingston’s D4P4D.
Two Plus Months
Race conditions are one of the worst plagues of concurrent code: They can cause disastrous effects all the way up to undefined behavior and random code execution, yet they’re hard to discover reliably during testing, hard to reproduce when they do occur, and the icing on the cake is that we have immature and inadequate race detection and prevention tool support available today. – Herb Sutter (DrDobbs.com)
With this opening paragraph in mind, observe the figure below. If you don’t lock-protect a stateful object that’s accessed by more than one thread, you’re guaranteed to fall into the dastardly trap that Herb describes. D’oh!
Now, look at the two object figure below. Unless you protect each of the two objects in the execution path with a lock, you’re hosed!
To improve performance at the expense of higher risk, you can use one lock for the two object example like on the left side of this graphic:
Alas, if you do choose to use one lock in a two object configuration like the example above, you better be sure that you don’t come in through the side with another thread to use the thread-unsafe object2. You also better be sure that a future maintainer of your code doesn’t do the same. But wait… How can you ensure that a maintainer won’t do that? You can’t. So stick with the more conservative, lower performance, one-lock-per-object approach.
Don’t ask me why I wrote this post cuz I ain’t answering. Well, Ok, ask. I wrote this post because I was burned by the left-hand side of the second graphic in this post. It took quite awhile, actually two plus months, to finally localize and squash the bugger in production code. As usual, Herb was right.
And please, don’t tell me that lock-free programming is the answer:
…replacing locks wholesale by writing your own lock-free code is not the answer. Lock-free code has two major drawbacks. First, it’s not broadly useful for solving typical problems—lots of basic data structures, even doubly linked lists, still have no known lock-free implementations. Second, it’s hard even for experts. It’s easy to write lock-free code that appears to work, but it’s very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction. – Herb Sutter (Dr. Dobbs).
21st Century Buddha
I’ve changed my mind. Instead of a “System Thinker“, I wanna become the…..
How about you? What do you wanna be?
Watch And Learn
Vineet Nayar (HCL Technologies), Jim Goodnight (SAS Institute), Ricardo Semler (Semco), Terri Kelly (W. L. Gore), Tony Hsieh (Zappos.com), and John Mackey (Whole Foods Market). I try to follow and listen to what these CEOs say because they’re different, refreshing, authentic, and most importantly, eminently tweetable.
I’m happy to announce that I’ve just added Red Hat’s Jim Whitehurst to my CEO “watch and learn” list:
The quotes were plucked from “Management Tips From Red Hat’s Crazy Culture Every Company Should Steal”.
No Lessons Learned II
Since my post on the JTRS fiasco generated more blog traffic than usual, this post is based on the same theme – the failure of a big, multi-techonology, socio-technical project. Today’s topic is the termination of the Army’s massive Future Combat Systems (FCS) program in 2009 after 6 years of development and gobs of spent taxpayer money. Actually, some face-saving was achieved on this boondoggle since the monolithic FCS program was replaced by several smaller, fragmented programs.
From a slew of pages I bookmarked on Delicious.com over the years, I pieced together the following timeline of events for the FCS program.
1) The FCS program is formally kicked off in 2003, with much fanfare, of course.
2) In August 2005, the program met 100% of the criteria in its most important milestone to date, Systems of Systems Functional Review. (Whoo Hoo, the “paper” docs were perfect!)
3) January 24, 2008. Congressional investigators express “concern” that the lines of code have nearly doubled since development began in 2003. And they question the Army’s oversight of a far-flung project involving more than 2,000 developers and dozens of contractors working across the nation. The Government Accountability Office, Congress’s watchdog, says the Army underestimated the undertaking. When the software project began, investigators say the Army estimated it needed 33.7 million lines of code; it’s now 63.8 million — about three times the number for the Joint Strike Fighter aircraft program. The software program “started prematurely. They didn’t have a solid knowledge base,” said Bill Graveline, a GAO official involved in the government’s ongoing review. “They didn’t really understand the requirements.”
4) Mar 18, 2008. Setbacks in the Army’s development of its software requirements for FCS due to the immaturity of the program and the aggressive pace of the Army’s development schedule, however, have led to delays, errors and omissions in the development of essential software packages for the program, while flaws in those packages have in turn delayed or threatened other development efforts, GAO said. Developers for five major software packages, for example, said that the high-level requirements they received from the Army were poorly defined, late or missing during the development process, GAO said.
5) June 13, 2008. Possible budget cuts, a change of administration and the Pentagon’s focus on supporting operations in Iraq and Afghanistan have ratcheted up pressure on the program just when it is showing tangible signs of progress after five years of work and almost $15 billion in taxpayer money invested.
6) Mar 02, 2009 The systems integrators heading the Army’s Future Combat Systems program have confirmed that development of the hardware and software required for the program’s vehicles and weapons systems is proceeding as planned. (Boeing Co. and Science Applications International Corp. are the lead systems integrators for the $87 billion FCS program.)
7) June 23, 2009. The memorandum issued confirms the recommendations made earlier this year by Defense Secretary Robert Gates to replace the single, giant program with a number of smaller modernization efforts.
FCS, particularly the manned combat vehicle portion, did not reflect the anti-insurgency lessons learned in Iraq and Afghanistan. – Robert Gates
So, let’s see what went wrong: ambiguous and inconsistent and misunderstood requirements, gross underestimation of effort, immature technologies, “aggressive” schedules. Sound familiar? Yawn. Same old, same old.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 