Archive
Bedeviled
I don’t know about you, but this quote seems magical to me:
So, in the midst of the relentless erosion of integrity of all matter over time, how in the hell does anything ever get organized in the first freakin’ place? While something is being created in real-time, be it you or me or our own creations, the 2nd law of thermo is magically suspended from doing its damage.
It takes “work” to create something. As soon as the entropy-defying work stops, the disintegration of that something begins.
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.
Behind One’s Back
Most reasonable people think that “talking behind one’s back” is a dishonorable and disrespectful thing to do. But aren’t many corpo performance evaluation systems designed, perhaps inadvertently, to do just that?
In some so-called performance evaluation systems, an “authorized” evaluator (manager) talks to an evaluatee’s peers to get the “real scoop” on the behavior, oops, I mean the “performance” of the evaluatee. But can’t that be interpreted (by unreasonable people, of course) as a sanctioned form of talking behind one’s back?
In these ubiquitously pervasive and taken-for-granted performance evaluation systems, when the covert, behind-the-back, intelligence gathering is complete and an “objective” judgment is concocted, it’s bestowed upon the evaluatee at the yearly, formal, face-to-face get together.
Wouldn’t it be more open, transparent, and noble to require face-to-face, peer-to-peer reviews before the dreaded “sitdown” with Don Corleone? Even better, wouldn’t it be cool if the evaluatee was authorized by the head shed to evaluate the evaluator?
“Mr. Corleone, just about every action you took last year slowed me down, dampened my intrinsic motivation, and delayed my progess. Hence, you sucked and you need to improve your performance over the next year.“
But alas, hierarchies aren’t designed for equity. Besides, quid pro quo collaboration takes too much time and we all know time is money. Chop, chop, get back to work!
To make the situation more inequitable and more “undiscussable“, some orgs institute two performance evaluation systems: the formal one described above for the brain dead DICsters down in the bilge room; and the undocumented, unpublicized, and supposedly unknown one for elite insiders.
If you work in an org that has a patronizing, behind-your-back performance evaluation system, don’t even think of broaching the subject to those who have the power to change the system. As Chris Argyris has stated many times, discussing undiscussables is undiscussable.
But wait! Snap out of that psychedelic funk you may have found yourself drifting into after reading the above blasphemy. Remember whose freakin’ blog you’re reading. It’s BD00’s blog – the self-proclaimed, mad, l’artiste.
Dependence Over Autonomy
Matthew Gill’s “Accountant’s Truth” provides a fascinating analysis and expose of the attitudes and culture of the accounting industry through a series of in-depth interviews with practicing accountants. As I’m reading the book, I’m using the Kindle’s marvelous “share” feature to tweet snippets like this one out into the ether:
Now, compare this excerpt with the following pair of tweets from one of my fave spiritual teachers, Byron Katie:
Interesting, don’t you think?
Proprietary Extensions
When using a tool or technology that implements a universal standard, beware of inadvertently using non-standard extensions that “lock” you into the vendor’s revenue stream.
The graphic below shows a screenshot from Artisan Real-time Studio version 7.2. Even though the tool implements the UML 2.0 standard, notice that there are several “non-UML” diagrams that you can create: “Constraint Diagram“, “General Flow Diagram“, etc. If you choose to create and use these proprietary extensions, then you’re sh*t out of luck if you get pissed off at Atego and want to port your model over to a different UML tool vendor with a better and/or less expensive solution. D’oh! I hate when that happens.
I’m not trying to single out Atego here. Every commercial vendor, especially of expensive tools, bakes-in a few proprietary extensions to give them an edge over the competition. The sneakier ones don’t annotate or make obvious which features are proprietary – so beware.
Monopolistic Providers
In search of economies of scale, centrally planned and controlled economies in nations and corporations tend to create monopolistic providers of goods and services. For example, in corporations, accounting, personnel, and R&D departments are usually deliberately organized as subsidized monopolies. They are subsidized in the sense that the users of their products or services do not pay for them directly; the supplying units are supported financially by funds that are allocated to them from above. The pool from which these funds are drawn is filled by a “tax” allocated from above to the units served. Monopolistic units that are subsidized are generally insensitive and unresponsive to the users of their services, but they are sensitive and responsive to the desires of the higher-level units that subsidize them. These higher level units are even more removed from the units served than the serving units. As a result, they are often unaware of, or unresponsive to, the needs and desires of the internal users of monopolistically provided goods and services. – Russell Ackoff (Ackoff’s Best: His Classic Writings on Management)
OK, time to practice my “bent” UML modeling skills and test your understanding with the class and sequence diagram pair below. The class diagram provides a structural view of a fictional Ackoffian system. The sequence diagram steps through an amalgam of behaviors in a world where monopolies rule. Any questions, comments, critiques, accolades, WTFs?
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)
Rules Of Thumb
Look what I dug up in my archives:
Hopefully, this list may provide some aid to at least one poor, struggling soul out in the ether.
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.
Four Reasons
When I don’t do something that I’m “supposed” to do, it comes down to one of two reasons:
- I don’t know how to do it because of a lack of expertise/experience (ability).
- I don’t believe it adds any, or enough, value (motivation).
But wait, I lied! There are also two more potential, but publicly undiscussable reasons. They’re elegantly put into words by Mr. Alexander Hamilton:
Men often oppose a thing merely because they have had no agency in planning it, or because it may have been planned by those whom they dislike. – Alexander Hamilton
How about you? When you don’t do something expected of you, why don’t you do it?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 