Archive
A Stone Cold Money Loser
A widespread and unquestioned assumption deeply entrenched within the software industry is:
For large, long-lived, computationally-dense, high-performance systems, this attitude is a stone cold money loser. When the original cast of players has been long departed, and with hundreds of thousands (perhaps millions) of lines of code to scour, how cost-effective and time-effective do you think it is to hurl a bunch of overpaid programmers and domain analysts at a logical or numerical bug nestled deeply within your golden goose. What about an infrastructure latency bug? A throughput bug? A fault-intolerance bug? A timing bug?
Everybody knows the answer, but no one, from the penthouse down to the boiler room wants to do anything about it:
To lessen the pain, note that to be “kind” (shhh! Don’t tell anyone) BD00 used the less offensive “artifacts” word – not the hated “D” word. And no, I don’t mean huge piles of detailed, out-of-synch, paper that would torch your state if ignited. And no, I don’t mean sophisticated-looking, semantic-less garbage spit out by domain-agnostic tools “after” the code is written.
Wah, wah, wah:
- “But it’s impossible to keep the artifacts in synch with the code” – No, it’s not.
- “But no one reads artifacts” – Then make the artifacts readable.
- “But no one knows how to write good artifacts” – Then teach them.
- “But no one wants to write artifacts” – So, what’s your point? This is a business, not a vacation resort.
Under Or Over?
In general, humans suck at estimating. In specific, (without historical data,) software engineers suck at estimating both the size and effort to build a product – a double whammy. Thus, the bard is wrong. The real thought worth pondering is:
To underestimate or overestimate, that is the question.
In “Software Estimation: Demystifying the Black Art“, Steve McConnell boldly answers the question with this graph:
As you can see, the fiscal penalty for underestimation rockets out of control much quicker than the penalty for overestimation. In summary, once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in if they overestimated the effort: more status meetings with execs, apologies, triaging of requirements, fixing bugs from quick-dirty workarounds implemented under schedule duress, postponing demos, pulling out of trade shows, more casual overtime, etc.
So, now that the under/over question has been settled, what question should follow? How about this scintillating selection:
Why do so many orgs shoot themselves in the foot by perpetuating a culture where underestimation is the norm and disappointing schedule/cost performance reigns supreme?
Of course, BD00 has an answer for it (cuz he’s got an answer for everything):
Via the x-ray power of POSIWID, it’s simply what hierarchical command and control social orgs do; and you can’t ask such an org to be what it ain’t.
The Uncertainty Of It All
From my personal perspective, I’ve discovered that one way of inching toward inner peace is to become more and more comfortable with uncertainty. I’m no Buddha (I’m a wanna be!), but learning to accept the fact of uncertainty often ameliorates the coupled feelings of anxiety and loss-of-control.
As an example, take a look at these five unproductive blank entries from my “gym notes” journal:
I don’t recall if something “I thought serious to ME” was dominating my mind at the time and contributing to the writer’s block, but I do remember not getting my knickers in a bunch. I remember thinking: “Oh well, I’m sure I’ll start filling the entries with inane thoughts soon. If not, then so what.”
Soon enough, my unorthodox thought stream reemerged on 8/27/17:
The uncertainty of it all. It’s wonderful, no?
Not Either, But Both?
I recently dug up an old DDS tutorial pitch by distributed system middleware expert extraordinaire, Doug Schmidt. The last slide in the pitch shows a side-by-side, high-level feature comparison of CORBA and DDS:
High performance middleware technologies like CORBA and DDS are big, necessarily complex beasts that have high learning curves. Thus, I’m not so sure I agree with Doug’s assessment that complex software systems (like sensor-based command and control systems) need both. One can build a pub-sub mechanism on top of CORBA (using the notification, event, or messaging services) and one can build a client-server, request-response mechanism on top of DDS (using the TCP/IP-like “reliability” QoS). What do you think about the tradeoff? Fill the holes yourself with a tad of home-grown infrastructure code, or use both and create a two-headed, fire-breathing dragon?
Holding On For Too Long
I’ve always admired Linus Torvalds. Thus, I found this slashdot.org article, “Linus Torvalds Answers Your Questions“, fascinating. Particularly, this Q & A struck a chord in me:
Q: You must of been burned out on Linux kernel development multiple-times over by now… how do you deal with it?
Linus: Oh, I really enjoy what I do. And I actually enjoy arguing too, and while I may swear a lot and appear like a grumpy angry old man at times, I am also pretty good at just letting things go. So I can be very passionate about some things, but at the same time I don’t tend to really hold on to some particular issue for too long, and I think that helps avoid burn-out.
Obsessing about things is important, and things really do matter, but if you can’t let go of them, you’ll end up crazy.
I’ve found that when I can’t let go of something that “shouldn’t be like it is“, the world suddenly stops. I get stuck; immobilized by a stagnating cesspool of circular thoughts and wondering if I’ll ever get unstuck.
The key for me to getting unstuck and moving forward again is to realize that I can’t control or fix everything to “my” liking. As hard as it is to accept, the world doesn’t exist to accommodate “ME“. Thus, when I can remember it (which is a challenge in itself), my favorite prayer is:
BD00, please grant the “other” BD00 the serenity to accept the things he cannot change,
The courage to change the things he can,
And the wisdom to know the difference.
How about you? Do you ever get stuck? What gets you unstuck?
The Experiences Of Others
When you think “differently” about the world than the majority, there’s a tendency to start feeling isolated and alone. Such is the power of authority and peer pressure to impose thought conformance to the prevailing world view.
When you encounter others, either in person or more likely in prose, whose “different” thoughts overlap with yours, a sense of kinship and belonging, which all human beings crave, blossoms.
Whenever you find that you are on the side of the majority, it is time to reform. – Mark Twain
One of the main reasons I read a lot of non-fictions books and articles is because I love to discover and learn through the direct experiences of others. Because of the constraints imposed by the limits of physical space and time, I cannot do and directly experience everything in all the areas that interest and impact me. Thus, I rely on the written expressions of others to feed my thirst for knowledge, understanding, and wisdom. To do otherwise would be to live life in a closed bubble, devoid of richness and variety.
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.
Firefighter Fran
Being anointed as a firefighter in an org that’s constantly battling blazes is one of the highest callings there is for any group member not occupying a coveted slot in the chief’s inner circle. Hell, since you didn’t start the fire and you’re gonna try your best to save the lot from a financial disaster, it’s a can’t-lose situation. If you fail, you’ll be patted on the back with a “nice try soldier; now we’re gonna go find the firestarter and kick his arse to kingdom come”. If you extinguish the blaze, at least you’ll lock in that 2% raise for this fiscal year. You might even get an accompanying $25 Dunkin Donuts gift card to keep your spare tire inflated with dozens of delectable, confectionary delights.
Given the above context, let’s start this heart-warming story off with you in the glorious role of firefighter Fran. You, my dear Fanny, oops, I mean Franny, have been assigned to put out a major blaze in one of your flagship legacy software products before it spreads to one of the nearby money silos and blows it sky high. Time, as always, is of the utmost importance. D’oh!
Since the burning pile of poop’s “agile” architecture and design documentation is a bunch of fluffy camouflage created solely to satisfy some process compliance checklist, you check out the code base and directly fire up vi (IDEs are for new age pussies!) for some serious sleuthing.
After glancing at the source tree‘s folder structure and concluding that it’s an incomprehensible, acronym-laden quagmire, you take the random plunge. With fingers a tremblin’ and fire hose a danglin’, you open up one of the 5000 source code files that’s postfixed with the word “Main“. You then start sequentially reading some hieroglyphics that’s supposed to be source code and you come to an abrupt halt when you see this:
And… that’s it! The story pauses here because BD00’s lizard brain is about to explode and it’s your turn to provide some “collaborative“, creative input.
So, what does our guaranteed-to-be-hero, fireman Fran, do next? Does the fire get doused? Does the pecuniary silo explode? Is the firestarter ever found? Does Fanny get the DD gift card? If so, how many crullers and donut holes does he scarf down?
Who knows, maybe you can become a self-proclaimed l’artiste like BD00 too, no?
Preposterously Unacceptable
Unless they’re cosmetic tweaks, all proposed alternatives to the unassailable and revered Annual Performance Review (APR) will always be auto-stamped as preposterously unacceptable by the powers that be. It has to be that way, cuz expecting the wolf who’s guarding the hen house to voluntarily give up his post is a slam dunk losing proposition. Nevertheless, let’s look at one of these preposterously unacceptable alternatives just for fun.
Sam Culbert, in “Get Rid Of The Performance Review“, proposes deep-sixing the laughable APR ritual and replacing the stinker with the (crappily named) “performance preview” (PP). The first major feature of the PP is that salary actions are severed from the process. They’re independently determined according to a more objective set of criteria (perhaps like how Joel Spolsky does it at Fog Creek Software). Removing the salary sledgehammer from the hand of the formerly omnipotent manager increases the chance that a straight-talking, two-way conversation regarding individual and organizational improvement will occur.
Mr. Culbert’s face-to-face PP, which can be called into being whenever either side “feels” it should happen, is predicated on both sides answering simple questions like these:
- What have I been doing recently that helps you and the organization perform better?
- What have I been doing recently that isn’t working for you and the organization?
- What can I do in the near future to help you and the organization improve?
Notice that thesw are questions to be answered by both sides – as opposed to one way, judgmental assertions made by the boss “on behalf of the borg” to the subordinate. There are also no formal forms or checklists to be signed and squirreled away in Hoover files to be brandished later for compliance coercion.
This blog post barely scratches the surface of Mr. Culbert’s PP process, but hopefully it’ll spur you to buy his book and learn more about this HR anti-christ. On second thought, don’t do it. If you’re a DICkster, it might bum you out since you’ll vividly realize that you’re helpless and you can’t “fight city hall“. If you’re in the hallowed guild of management (especially the unconsciously evil HR echelon), because of its preposterous unacceptability, it might send shivers up your spine and/or piss you off.
Note: Instead of “Performance Preview” (PP), BD00 would’ve called it something like “I Help, You Help” (IHYH).
Be Thankful
In “Abolishing Performance Appraisals“, Coens and Jenkins state:
One study found that 98% of people saw themselves in the top half of all performers. Another study showed that 80% of people saw themselves in the top quarter of all performers. Other research indicates that 59% of workers across a variety of jobs disagreed or strongly disagreed with any rating that was not the highest on the scale.
Now, assume that your in-Human Resources (iHR) department, under the condoning eyes of the C-suite, enforces the standard bell curve rating system on the DICforce to keep operating costs in check and to implement the industry’s most sacred “best practice“. Of course, the ratings are doled out at the beloved Annual Performance Review (APR) ritual along with subjective lists of personal faults that need “improvement” and 2% raises – a brilliant triple punch combo to the psyche. To make things more interesting, assume that all the reviews are given at the same time each year.
Given the information above, the cyclical morale curve below was scientifically developed by BD00 using one of his patented social system algorithms.
The curve shows that the average “system-wide” morale peaks just prior to the APR; and then it takes a nose dive after most of those optimistic DICs get a dose of reality from their supervisors (whose morale also takes a nose dive from being forced by iHR to administer the deflating news). Subsequent to the nadir, the system morale slowly recovers and rises back to its peak – until boom, the next iHR sponsored APR takes place. Whoo hoo! Dontcha just luv rollercoaster rides?
Just think of the lost productivity and sub-quality work performed during the annual dips. The next time you see an iHR group member, don’t fugget to thank him/her for the wonderful APR system his/her group presides over. Uh, on second thought, don’t do it. Nothing of substance is likely to change and you may be perceived as difficult, disrespectful, and disloyal – three more items to tack onto next year’s personal fault list. Plus, these types of things are undiscussable and they’re not within your tiny silo of expertise.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 