Archive
Unjustifiable Precision
In “Object-Oriented Analysis and Design with Applications“, Grady Booch bluntly states:
Unjustifiable precision—in requirements or plans—has proven to be a substantial yet subtle recurring obstacle to success. Most of the time, early precision is just plain dishonest and serves to provide a façade for more progress of more quality than actually exists. – Grady Booch
Pretty harsh, but wise, words, no? So, why do managers, directors, and executives repeatedly demand micro-granularized schedules and commitments from knowledge workers from day one throughout the life of a project?
- Because “that’s the way it has always been done“
- To maintain the illusion of control
- To flex their muscles and “hold people accountable” each time a micro-commitment is broken
A Bunch Of STIFs
In “Object-Oriented Analysis and Design with Applications“, Grady Booch argues that a successful software architecture is layered, object-oriented, and evolves over time as a series of STIFs – STable Intermediate Forms. The smart and well liked BD00 agrees; and he adds that unsuccessful architectures devolve over time as a series of unacknowledged UBOMs (pronounced as “You Bombs“).
UBOMs are subtle creatures that, without caring stewardship, can unknowingly sneak up on you. Your first release or two may start out as a successful STIF or a small and unobtrusive UBOM. But then, since you’ve stepped into UBOM-land, it can grow into an unusable, resource-sucking abomination. Be careful, very careful….
“Who advocates for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks
“Dear Fred, when the primary thought held steadfast in everybody’s mind is “schedule is king” instead of “product is king“, of course no one will often advocate for the product.” – BD00
Premature Optimization And Simplification
Premature optimization is the root of all evil – Donald Knuth
Most, if not all software developers will nod their heads in agreement with this technical proverb. However, as you may have personally experienced, one man’s premature optimization is another man’s simplification. Some people, especially BMs and BMWs shackled from above with a “schedule is king; what is quality?” mindset, will use that unspoken mantra as a powerful weapon (from a well stocked arsenal) to resist any change – all the while espousing “we’re agile and we embrace change“. Lemme give you a hypothetical example.
Assume that you’re working on a project and you discover that you can remove some domain layer code with no impact on the logical correctness of the system’s output. Furthermore, you discover that removal of the code, since it is used many times throughout the BBoM code base, will increase throughput and reduce latency. A win-win situation, right?
The most reliable part in a system is the one that’s not there – because it’s not needed. – Unknown
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery
OK, so:
- you disclose your discovery to the domain “experts”,
- they whole-heartedly agree and thank you,
- you remove the code, and all is well.
Well, think again. Here’s what may happen:
- you disclose your discovery to the domain “experts”,
- you receive silence (because you’re not a member of the domain layer “experts” guild),
- you persist like a gnat until the silence cannot be maintained,
- you’re “told” that your proposal is a pre-mature optimization,
- you say “WTF?” to yourself, you fire a verbal cruise missile at the domain experts’ bunker, and you move on.
Movement And Progress
In collaboration with a colleague, I’m currently designing, writing, and testing a multi-threaded, soft-real-time application component for a distributed, embedded sensor system. The graph below shows several metrics that characterize our creation.
The numbers associated with the most recent 9/22/11 time point are:
Of course, the pretty graph and its associated “numbers” don’t give any clue as to the usefulness or stability of our component, but “movement” is progressing forward. Err, is it?
Don’t confuse movement with progress – Tom Peters
What’s your current status?
Illusion, Not Amplification
The job of the product development team is to engineer the illusion of simplicity, not to amplify the perception of complexity.
Software guru Grady Booch said the first part of this quote, but BD00 added the tail end. Apple Inc.’s product development org is the best example I can think of for the Booch part of the quote, and the zillions of mediocre orgs “out there” are a testament to the BD00 part.
According to Warren Buffet, the situation is even worse:
There seems to be some perverse human characteristic that likes to make easy things difficult. – Warren Buffet
Translated to BD00-lingo:
Engineers like to make make easy things difficult, and difficult things incomprehensible.
Why do they do it? Because:
A lot of people mistake unnecessary complexity for sophistication. – Dan Ward
Conclusion:
The quickest routes to financial ruin are: wine, women, gambling….. and engineers
Ubiquitous Dishonorability
While reading the delightful “Object-Oriented Analysis and Design with Applications“, Grady Booch et al extol the virtues of object-oriented analysis over the venerable, but passe, structured analysis approach to front end system composition. As they assert below, one of the benefits of OOA is that it’s easier and more natural to avoid mixing concrete design details with abstract analysis results.
Out of curiosity (which killed the cat), I scrolled down to see what note [4] meant:
WTF? Do they mean “because that’s the way the boss sez it must be done!” and “because that’s the way we’ve always done it!” aren’t honorable reasons for maintaining the status quo? If so, then dishonorable behavior runs rampant within the halls of most software shops the world over. But you already knew that, no?
Unavailability II
The availability of a software-intensive, electro-mechanical system can be expressed in equation form as:
With the complexity of modern day (and future) systems growing exponentially, calculating and measuring the MTBF of an aggregate of hardware and (especially) software components is virtually impossible.
Theoretically, the MTBF for an aggregate of hardware parts can be predicted if the MTBF of each individual part and how the parts are wired together, are “known“. However, the derivation becomes untenable as the number of parts skyrockets. On the software side, it’s patently impossible to predict, via mathematical derivation, the MTBF of each “part“. Who knows how many bugs are ready to rear their fugly heads during runtime?
From the availability equation, it can be seen that as MTTR goes to zero, system availability goes to 100%. Thus, minimizing the MTTR, which can be measured relatively easily compared to the MTBF ogre, is one effective strategy for increasing system availability.
The “Time To Repair” is simply equal to the “Time To Detect A Failure” + “The Time To Recover From The Failure“. But to detect a failure, some sort of “smart” monitoring device (with its own MTBF value) must be added to the system – increasing the system’s complexity further. By smart, I mean that it has to have built-in knowledge of what all the system-specific failure states are. It also has to continually sample system internals and externals in order to evaluate whether the system has entered one of those failures states. Lastly, upon detection of a failure, it has to either inform an external agent (like a human being) of the failure, or somehow automatically repair the failure itself by quickly switching in a “good” redundant part(s) for the failed part(s). Piece of cake, no?
Unavailable For Business
The availability of a system is usually specified in terms of the “number of nines” it provides. For example, a system with an availability specification of 99.99 provides “two nines” of availability. As the figure below shows, a service that is required to provide five nines of availability can only be unavailable 5.3 minutes per year!
Like most of the “ilities” attributes, the availability of any non-trivial system composed of thousands of different hardware and software components is notoriously difficult and expensive to predict or verify before the system is placed into operation. Thus, systems are deployed and fingers crossed in the hope that the availability it provides meets the specification. D’oh!
One way of supposedly increasing the availability of a system is to add redundancy to its design (see the figure below). But redundancy adds more complex parts and behavior to an already complex system. The hope is that the increase in the system’s unavailability and cost and development time caused by the addition of redundant components is offset by the overall availability of the system. Redundancy is expensive.
As you might surmise, the switch in the redundant system above must be “smart“. During operation, it must continuously monitor the health of both output channels and automatically switch outputs when it detects a failure in the currently active channel.
The state transition diagram below models the behavior required of the smart switch. When a switchover occurs due to a detected failure in the active channel, the system may become temporarily unavailable unless the redundant subsystem is operating as a hot standby (vs. cold standby where output is unavailable until it’s booted up from scratch). But operating the redundant channel as a hot standby stresses its parts and decreases overall system availability compared to the cold spare approach. D’oh!
Another big issue with adding redundancy to increase system availability is, of course, the BBoM software. If the BBoM running in the redundant channel is an exact copy of the active channel’s software and the failure is due to a software design or implementation defect (divide by zero, rogue memory reference, logical error, etc), that defect is present in both channels. Thus, when the switch dutifully does its job and switches over to the backup channel, it’s output may be hosed too. Double D’oh! To ameliorate the problem, a “software 2” component can be developed by an independent team to decrease the probability that the same defect is inserted at the same place. Talk about expensive?
Achieving availability goals is both expensive and difficult. As systems become more complex and human dependence on their services increases, designing, testing, and delivering highly available systems is becoming more and more important. As the demand for high availability continues to ooze into mainstream applications, those orgs that have a proven track record and deep expertise in delivering highly available systems will own a huge competitive advantage over those that don’t.
Growing Wings On The Way
If you don’t have wings and you jump off a cliff, you better hope to grow a pair before you go splat. With this lame ass intro, I introduce you to the title of the latest systems thinking book that I finished reading: “Growing Wings On The Way“.
GWOTW is yet another terrific systems thinking book from small British publishing house “Triarchy Press“. The book defines and explains a myriad of tools/techniques for coming to grips with, understanding, and improving, socio-technical “messes“. Through numerous examples, including a very personal one, Rosalind Armson develops the thought processes and methods of inquiry that can allow you to generate rich pictures, influence diagrams, system maps, multiple-cause diagrams, and human activity system diagrams for addressing your “messes“. If you want a solid and usable intro to soft systems thinking, then this may be your book.
Home Grounds
In Barry Boehm and Richard Turner‘s book, “Balancing Agility And Discipline“, they present the concept of the “home ground“. Agile and plan-driven (a.k.a. waterfall) software development methodologies each have their own turf where one is superior to the other for getting the job done within time, budget, and quality constraints.
As the figure below shows, the Boehm/Turner definition of “home ground” is based on 5 dimensions: personnel (experience/expertise), criticality, dynamism, size, culture.
At the origin of the 5 dimensional chart, where dynamism is high, culture is liberally open, project size is small, criticality of application is low, and the majority of the project staff is highly competent, agile approaches are more effective and efficient and efficacious. At the extremes of the 5 axes, plan-driven approaches are more effective and efficient and efficacious.
Do you think Boehm and Turner have got it right? Are there any dimensions missing from their model; like level of management humility, quality of management-knowledge worker relationships, quality of tools, quality of physical work environment?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
