Archive
Faking Rationality
I recently dug up and re-read the classic Parnas/Clement 1986 paper: “A Rational Design Process: How And Why To Fake It“. Despite the tendency of people to want to desperately believe the process of design is “rational“, it never is. The authors know there is no such thing as a sequential, rational design process where:
- There’s always a good reason behind each successive design decision.
- Each step taken can be shown to be the best way to get to a well defined goal.
The culprit that will always doom a rational design process is “learning“:
Many of the details only become known to us as we progress in the implementation (of a design). Some of the things that we learn invalidate our design and we must backtrack (multiple times during the process). The resulting design may be one that would not result from a rational design process. – Parnas/Clements
Since “learning“, in the form of going backwards to repair discovered mistakes, is a punishable offense in social command & control hierarchies where everyone is expected to know everything and constantly march forward, the best strategy is to cover up mistakes and fake a rational design process when the time comes to formally present a “finished” design to other stakeholders.
Even though it’s unobtainable, for some strange reason, Spock-like rationality is revered by most orgs. Thus, everyone in org-land plays the “fake-it” game, whether they know it or not. To expect the world to run on rationality is irrational.
Executives preach “evidence-based decision-making“, but in reality they practice “decision-based evidence-making“.
Four Possible Paths, Eight Possible Outcomes
The graphic below transforms the title of this post into a visual manifestation that can be discussed “rationally” (<— LOL!).
The graphic shows that pursuing any of the four path selections can lead to a “number 2” outcome. It’s just a matter of how much time and money are exhausted before the steaming pile is discovered. D’oh! I hate when that happens.
Obviously, the path to the holy grail is D->1. Simply take whatever info is known about the problem, code up the solution, get paid tons o’ munny, move on to the next problem to be solved, and never look back. Whoo Hoo! I love when that happens.
The C++ Product Roadmap
Fresh from the ISO C++ chairman himself, Herb Sutter, I present you with the C++ product roadmap:
If all goes according to plan, a minor release of the ISO standard will be hatched in 2014. By minor, Herb means that it will be mostly bug fixes to C++11, plus a filesystem library based on Boost.org‘s brilliant work. The networking library, which is big and being developed by a large group of smart people, will be hatched incrementally in a series of Technical Specifications (TS).
The main point that Herb stressed when he hoisted the slide was that “the past is not a good predictor of the future“. If all goes according to plan, the time between major releases of the standard will have been cut from 13 years to 6.
The Org Is The Product
Someone once said something like: “the products an organization produces mirror the type of organization that produces them“. Thus, a highly formal, heavyweight, bureaucratic, title-obsessed, siloed, and rigid org will most likely produce products of the same ilk.
With this in mind, let’s look at the US DoD funded Software Engineering Institute (SEI) and one of its flagship products: the “CMMI® for Development, Version 1.3“. The snippet below was plucked right out of the 482 page technical report that defines the CMMI-DEV:
So, given no other organizational information other than that provided above, what kind of product would you speculate the CMMI-DEV is? Of course, like BD00 always is, you’d be dead wrong if you concluded that the CMMI-DEV is a highly formal, heavyweight, bureaucratic, title-obsessed, siloed, and rigid model for product development.
Courageous Journey
Here’s a dare fer ya:
If your org has a long, illustrious history of product development and you’re just getting started on a new, grand effort that will conquer the world and catapult you and your clan to fame and fortune, ask around for the post-mortem artifacts documenting those past successes.
If by some divine intervention, you actually do discover a stash of post-mortems stored on the 360 KB, 3.5 inch floppy disk that comprises your org’s persistent memory, your next death-defying task is to secure access to the booty.
If by a second act of gawd you’re allowed to access the “data“, then pour through the gobbledygook and look for any non-bogus recommendations for future improvement that may be useful to your impending disaster, err, I mean, project. Finally, ask around to discover if any vaunted org processes/procedures/practices were changed as a result of the “lessons learned” from innocently made bad decisions, mistakes, and errors.
But wait, you’re not 100% done! If you do survive the suicide mission with your bowels in place and title intact, you must report your findings back here. To celebrate your courageous journey through Jurassic Park, there may be a free BD00 T-shirt in the offing. Making stuff up is unacceptable – BD00 requires verifiable data and three confirmatory references. Only BD00 is “approved” to concoct crap, both literally and visually, on this dumbass and reputation-busting blawg.
A Risky Affair
The figure below shows the long term savings potential of a successful Software Product Line (SPL) over a one-off system development strategy. Since 2/3 to 3/4 of the total lifecycle cost of a long-lived software system is incurred during sustainment (and no, I don’t have any references handy), with an SPL infrastructure in place, patience and discipline (if you have them) literally pay off. Even though short term costs and initial delivery times suffer, cost and time savings start to accrue “sometime” downstream. Of course, if your business only produces small, short-lived products, then implementing an SPL approach is not a very smart strategy.
If you think developing a one-off, software-intensive product is a risky affair, then developing an SPL can seem outright suicidal. If your past history indicates that you suck at one-off development (you do track and reflect upon past schedule/cost/quality metrics as your CMMI-compliant process sez you do, right?), then rejecting all SPL proposals is the only sane thing to do…. because this may happen:
The time is gone, the money is gone, and you’ve got nothing to show for it. D’oh! I hate when that happens.
Related Articles
The Odds May Not Be Ever In Your Favor (Bulldozer.com)
Out Of One, Many (Bulldozer.com)
Prune Me, Please
In “Integrating CMMI and Agile Development“, Paul E. McMahon asserts that even though they’d like to, many orgs don’t “prune” their fatty, inefficient, and costly processes because:
..it requires a commitment of the time of key people in the organization who really use the processes. Usually these people are just too busy with direct contract work and the priority doesn’t allow this to happen.
One of BD00’s heroes, the Oracle of Omaha, has a different take on it:
There seems to be some perverse human characteristic that likes to make easy things difficult. – Warren Buffet
Of course, both reasons could apply.
From Complexity To Simplicity
As the graphic below shows, when a system evolves, it tends to accrue more complexity – especially man-made systems. Thus, I was surprised to discover that the Scrum product development framework seems to have evolved in the opposite direction over time – from complexity toward simplicity.
The 1995 Ken Schwaber “Scrum Development Process“ paper describes Scrum as:
Scrum is a management, enhancement, and maintenance methodology for an existing system or production prototype.
However, The 2011 Scrum Guide introduces Scrum as:
Scrum is a framework for developing and sustaining complex products.
Thus, according to its founding fathers, Scrum has transformed from a “methodology” into a “framework“.
Even though most people would probably agree that the term “framework” connotes more generality than the term “methodology“, it’s arguable whether a framework is simpler than a methodology. Nevertheless, as the figure below shows, I think that this is indeed the case for Scrum.
In 1995, Scrum was defined as having two bookend, waterfall-like, events: PSA and Closure. As you can see, the 2011 definition does not include these bookends. For good or bad, Scrum has become simpler by shedding its junk in the trunk, no?
The most reliable part in a system is the one that is not there; because it isn’t needed. (Middle management?)
I think, but am not sure, that the PSA event was truncated from the Scrum definition in order to discourage inefficient BDUF (Big Design Up Front) from dominating a project. I also think, but am not sure, that the Closure event was jettisoned from Scrum to dispel the myth that there is a “100% done” time-point for the class of product developments Scrum targets. What do you think?
Related articles
- Scrum Cheat Sheet (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- Introduction to scrum (slideshare.net)
- Scrum Master, a management position? (scrumguru.wordpress.com)
- Developing, and succeeding, with Scrum (techworld.com.au)
Ultimately And Unsurprisingly
Take a look at the latest, dorky, BD00 diagram below. The process model on the left is derived from the meaty, 482 page CMMI-DEV SEI Technical Report. The model on the right is derived from the lean, 16 page Scrum Guide.
Comparing CMMI-DEV and Scrum may seem like comparing apples to oranges, but it’s my blog and I can write (almost) whatever I want on it, no?
Don’t write what you know, write what you want to know – Jerry Weinberg
The overarching purpose of both process frameworks is to help orgs develop and sustain complex products. As you can deduce, the two approaches for achieving that purpose appear to be radically different.
The CMMI-DEV model is comprised of 22 practice areas, each of which has a number of specific and generic practices. Goodly or badly, note that the word “practice” dominates the CMMI-DEV model.
Unlike the “practice” dominated CMMI-DEV model, the Scrum model elements are diverse. Scrum’s first class citizens are roles (people!), events, artifacts, and the rules of the game that integrate these elements into a coherent socio-technical system. In Scrum, as long as the rules of the game are satisfied, no practice is off limits for inclusion into the framework. However, the genius inclusion of time limits for each of Scrum’s 4 event types implicitly discourages heavyweight practices from being adopted by Scrum implementers and practitioners.
Of course, following either model or some hybrid combo can lead to product quality/time/budget success or failure. Aficionados on both sides of the fence publicly tout their successes and either downplay their failures (“they didn’t understand or really follow the process!“) or they ignore them outright. As everyone knows, there are just too many freakin’ metaphysical factors involved in a complex product development effort. Ultimately and unsurprisingly, success or failure comes down to the quality of the people participating in the game – and a lot of luck. Yawn.
Marginalizing The Middle
Because they unshackle development teams from heavyweight, risk-averse, plan-drenched, control-obsessed processes promoted by little PWCE Hitlers and they increase the degrees of freedom available to development teams, agile methods and mindsets are clearly appealing to the nerds in the trenches. However, in product domains that require the development of safety-critical, real-time systems composed of custom software AND custom hardware components, the risk of agile failure is much greater than traditional IT system development – from which “agile” was born. Thus, a boatload of questions come to mind and my head starts to hurt when I think of the org-wide social issues associated with attempting to apply agile methods in this foreign context:
Will the Quality Assurance and Configuration Management specialty groups, whose whole identity is invested in approving a myriad of documents through complicated submittal protocols and policing compliance to existing heavyweight policies/processes/procedures become fearful obstructionists because of their reduced importance?
Will penny-watching, untrusting executives who are used to scrutinizing planned-vs-actual schedules and costs in massive Microsoft Project and Excel files via EVM (Earned Value Management) feel a loss of importance and control?
Will rigorously trained, PMI-indoctrinated project managers feel marginalized by new, radically different roles like “Scrum Master“?
Note: I have not read the oxymoronic-titled “Integrating CMMI and Agile Development” book yet. If anyone has, does it address these ever so important, deep seated, social issues? Besides successes, does it present any case studies in failure?
… there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer makes enemies of all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order… – Niccolo Machiavelli
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 