Archive
Obsolete, Or Timeless?
Waaay back in 1992, before “agile” and before all the glorious CMM incarnations and before the highly esteemed “PSP/TSP”, NASA’s Software Engineering Laboratory issued revision #3 of their “Recommended Approach To Software Development“. As you can see below, the table of contents clearly implies a “waterfall” stank to their analysis.
But wait! In section 10 of this well organized and well written “artifact“, the members of the writing team summarize what they think were the keys to successful on time and on budget software project success:
What do you think about this summary? Is the advice outdated and obsolete and applicable only to “waterfall” framed projects? Is the advice timeless wisdom? Are some recommendations obsolete and others timeless nuggets wisdom?
SOI Sauce
Assume that you’re given a bounded “System Of Interest” (SOI) you desperately want to understand. Cuz it’s a ‘nuther whole can of worms, please suspend “reality” for a moment and fuggedaboud who defined the SOI boundaries and plopped it onto your lap to study.
So, where and how do you start attacking the task at hand? Being a member of a western, logical, science-revering culture, you’ll most likely take the analysis path as depicted in the left side of the figure below. You’d try to discern what the SOI’s elemental parts are (forming your own arbitrary part-boundaries, of course) and how each of the parts behaves independently of the others. After performing due diligence at the parts level, you’d aggregate the fragmented part-behaviors together into one grand theory of operation and voila….. you’re done! Because the reductionist approach doesn’t explore the why of the SOI, you’d most likely be wrong. If one or more of the system “parts” is self-purposeful, uh, like people, you’d most likely be 100% wrong.
A complementary approach to understanding a SOI concerns formulating the why of the system – first. As the right-side path in the above figure conveys, the synthesis approach to understanding starts with the exploration of the super-system that contains the SOI. Upon gaining an understanding of the operational context of the SOI within its parent system (the why), the what and the how of the SOI’s parts can be determined with greater accuracy and insight.
The figure below illustrates side-by-side state machine models of the two approaches toward system understanding. Which one best represents the way you operate?
Apache Style
Check out these dorks….
It’s none other than “shady” BD00 and his best buddy Reno in their slick, new, Apache Corp garb. I know, I know. With decrepit faces like that, no amount of stylin’ or blingin’ can soothe the eyesores, no? But there’s a nice story here….
While down in Nawlins celebrating Margi Gras and shoppin’ for souvenir shirts, we met this terrific couple from Houston: Dona (pronounced as “Dah-nah” – even though there’s only one “n“) and Ken McMinn. When I saw that Ken was wearin’ the best shirt in the house, I said “I want one of those!“. Sure enough, after an exchange of e-mail addresses and the passage of time, Dona and Ken sent us our own very own Apache shirts for $99.99 a piece. Just kiddin’. They were generous enough to send them gratis, along with a pair of matching Apache hats. Who hoo!
Dona and Ken, you guys rock. We’ll see y’all down on Bourbon Street again in oh-twelve. The first round of Hurricanes is on Reno, and the mufalletas are on me.
The Assumption Was Wrong
While performing maintenance on some legacy C++ code, a colleague came across a code fragment that performs a large, buffer-to-buffer byte copy. Instead of using the std::memcpy function to implement the copy, it was written the homegrown way – using a loop over the number of bytes to copy. The reason given for the choice was to “avoid the overhead of a function call“.
As the test code and results below show, the performance of std::memcpy blew away the loop-dee-loop strategy by a factor of 40X. The untested assumption behind the decision to write the loop was that std::memcpy was implemented under the covers as a loop by the compiler writers. An alternative assumption, that the compiler replaces std::memcpy with highly efficient, CPU-architecture-specific, inline code, either wasn’t known or it didn’t come to mind.
It took me about twenty minutes to prove, with objective data, that “the assumption was wrong“.
So, what’s the lesson here? There is none. It’s impractical to challenge and test every single assumption we make as programmers – and as people, no? Perhaps the original programmer was a newbie who hadn’t yet learned the rule of thumb that it’s almost always better to use compiler-supplied library functions and classes over equivalent homegrown code. Perhaps the assumption was so ingrained (like the theory X assumption that “anointed” superiors are smarter, more trustworthy, and more responsible than subordinates) it didn’t occur to the programmer to test it out. Perhaps it did occur to the programmer that he/she should test the assumption but he/she felt immense schedule pressure to plow ahead with blinders on.
Focus And Curiosity
I like using tweets as a source of blog posts. This one by Tom Peters captured my imagination:
Too much vertical focus and there’s no growth or development. Too much horizontal curiosity and there’s no accomplishment. However, the right mix of focus and curiosity provides for both personal growth and accomplishment. As the state transition diagram below illustrates, I always start a new software project in the curious state of “not knowing“. I then transition into the focused state and cycle between the two states until I’m “done“. Don’t ask me how I decide when to transition from one state to the other because I don’t have a good answer. It’s a metaphysical type of thingy.
I start off in the curious state to gain an understanding of the context, scope, and boundaries of my responsibilities and what needs to be done before diving into the focused state. I’ve learned that when I dive right into the focused state without passing through the curious state first, I make a ton of mistakes that always come back to haunt me in the form of unnecessary rework. I make fewer and less serious mistakes when I enter the curious state at “bootup“. How about you?
Since bozo managers in CCH CLORGS are paid to get projects done through others, they implicitly or explicitly assume that there is no need for a curious state and they exert pressure on their people to start right right out in the focused state – and never leave it.
Good managers, of course, don’t do this because they understand the need for the curious state and that dwelling in it from time to time reduces schedule and increases end product quality. Great managers not only are clued into the fact that the curious state is needed at startup and from time to time post-startup, they actually roll up their sleeves and directly help to establish the context, scope, and boundaries of what needs to be done for each and every person on the project. How many of these good and great managers do you know?
“If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions” – Albert Einstein
Don’t you think Mr. Einstein spent a lot of time in the curious state?
Mangineers And Enginanagers
Expert Number 1 sez:
Engineers don’t make good technical project leaders because they lack business acumen. Thus, they’ll blow the budget and schedule.
Expert Number 2 sez:
Generic managers don’t make good technical project leaders because they don’t understand the work. Thus, they’ll blow the budget and schedule.
Non-expert BD00, who likes to make stuff up and fabricate his own truths, sez:
Yeah, that dilemma sux, but assuming that it can be done, it’s less costly in time and dollars to train an engineer in business skills than it is to train a generic manager in engineering skills.
Of course, if you assume that successful engineer-to-manager or manager-to-engineer cross training is unrealistic (and not many “mainstream” people would fault you for thinking that), then you won’t have to dirty your manicured nails or reach into your pocketbook to, as your fellow managers like to say, “get it done“. The result of this irresponsible, hands off approach is that you will continue to get what you deserve: all of your non-routine, technically challenging development (but not production) projects will blow the budget and schedule more than they normally would if you had put a mangineer or enginanager in charge. Whoo Hoo! Way to go Mr. and Mrs. FOSTMA. Stay the course.
A Valiant Try
Google recently re-appointed Larry Page as it’s CEO after a 10 year hiatus. From the following blurb in “The Product Shakeup At Google Begins”, it seems like Google is valiantly trying to return to its roots:
(Larry) Page famously has a low opinion of managers, especially product managers who try to tell engineers what to do. “People don’t want to be managed,” he is quoted in Steven Levy’s new book, In the Plex. Page is a big believer in self-management. At one point early on in the company’s history, he and Brin tried to get rid of all managers.
Even though it is certainly impractical to get rid of all managers once an org grows to a certain size, ya gotta love the irony of anti-management CEOs like Page, Nayar, and Semler, no? With guys like that watching over an org, you can be confident that they’ll be vigilant in keeping the manager-to-worker ratio low and that they’ll make sure managers do more than just plan, watch, control, command, and evaluate others. Of course, this philosophy doesn’t guarantee success, but it sure does make working for a company more enjoyable for the majority of people who work there – not just the management minority.
Saving Face
In CLORGs, the act of saving face by individuals and groups always takes precedence over the health of the organization has a whole. Actually, this behavior defines a CLORG, because without it, the assemblage of people wouldn’t be a freakin’ CLORG. It would be as Charlie Sheen sez: “winning“.
If an org is well led, its leaders will be skilled at detecting, exposing, and squashing face-saving behavior when the long term health of the org is put at risk. Sadly, those same people who should be diligently eradicating selfish, face-saving, behavior from their orgs are the greatest practitioners of it. D’oh!
Formal Review Chain
On big, multi-year, multi-million dollar software development projects, a series of “high-ceremony” formal reviews are almost always required to be held by contract. The figure below shows the typical, sequential, waterfall review lineup for a behemoth project.
The entity below each high ceremony review milestone is “supposedly” the big star of the review. For example, at SDR, the structure and behavior of the system in terms of the set of CSCIs that comprise the “whole” are “supposedly” reviewed and approved by the attendees (most of whom are there for R&R and social schmoozing). It’s been empirically proven that the ratio of those “involved” to those “responsible” at reviews in big projects is typically 5 to 1 and the ratio of those who understand the technical content to those who don’t is 1 to 10. Hasn’t that been the case in your experience?
The figure below shows a more focused view of the growth in system artifacts as the project supposedly progresses forward in the fantasy world of behemoth waterfall disasters, uh, I mean projects. Of course, in psychedelic waterfall-land, the artifacts of any given stage are rigorously traceable back to those that were “designed” in the previous stage. Hasn’t that been the case in your experience?
In big waterfall projects that are planned and executed according to the standard waterfall framework outlined in this post, the outcome of each dog-and-pony review is always deemed a great success by both the contractee and contractor. Backs are patted, high fives are exchanged, and congratulatory e-mails are broadcast across the land. Hasn’t that been the case in your experience?
You Talkin’ Bout Me?
Since the world obviously revolves around me, I’m surprised that there’s no @bulldozer0 in Jeff’s tweet.
Strategy? There’s no strategic planning involved; it comes naturally. But thanks for giving me the benefit of the doubt.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 