Archive
Ain’t Life A Kitsch?
BD00 is proud to present the following post from his third guest blogger: twitter friend Serial Mom. When she submitted her story for “approval“, S&M gave the BD00 editorial staff free license to “bulldozify” her ditty as necessary. W00t!
So, let’s start off with some important definitions:
Kitsch – something of tawdry design, appearance, or content created to appeal to popular or undiscriminating taste (Random House Kernerman Webster’s College Dictionary)
Korpo Kitsch – the employee-facing happy side of corporate greed and bozoness; usually something of tawdry design, appearance, or content – Serial Mom
Now that that’s done, let’s hear Serial Mom’s story; which is still unfolding as we speak. As you’ll soon realize, S&M’s story is simply one real example of korpo kitschenism playing out in many office buildings near you. Here we go…..
At T=1, the C-suites of two online services companies decide the way to go forward is to embrace the wildly successful “too big to fail” strategy and merge into one big korpo hairball. (WTF? AS IF anyone would care about bailing out an online services borg).
At T=2, the more bureaucratic of the two borgs wins the political battles (we just luv our mid-20th century HR!) and the reorg is kicked off. Whoo Hoo!
At T=3, some politically motivated technical decisions are made (using the process of decision-based evidence-making) within the newly merged star chamber .
At T=4, on the IT side of things, an OK working agile shop meets the South Asian waterfall shop.
At T=5, to appease the shareholders, millions of $$ are promised by way of synergy via 2 years of mind-numbing IT migration projects.
At T=6, the potentates in the head shed start wondering why the company is losing customers and innovation momentum – even though it’s obvious they “allocated” 90% of the workforce to work on those mind-numbing, “overhead“, IT migration projects.
At T=7, the C-suite junta wonders why there are loads of (schedule, cost, quality) problems downstream from their (infallible) technical decisions.
At T=8, the proclamation is made: SOMETHING NEEDS TO BE DONE!
At T=9, a superstar “fixer” gains membership to the exclusive C-suite in return for undertaking the dirty work of cleaning up the mess his peers have hatched.
At T=10, the standard MBA text book move is executed: people get laid off. Of course, the unintended consequences of the move manifest themselves soon after: good people leave and whatever is left of any positive corporate culture disappears. Poof!
At T=11, the “agile transformation” mandate is foisted down upon the people (and this includes squeezing the currently agile parts of the company into the new, cargo-cult, agile model).
At T=12, middle managers, who know the transformation won’t work but fear for their (so-called) careers, don’t push back and they each dutifully assume their messenger role.
At T=13, the prelude to the korpo kitsch moment arrives. Everybody in IT is “required” by management (at the behest of the brilliant HR team, of course) to take a standardized test that will “scientifically” determine the training needs for the upcoming agile transformation. The test will consist of a personality section (Myers-Briggs style) and some standard IQ verbal, numerical, and logical crap. (Since they’re by definition they’re infallible, BD00 & S&M bet that the managers don’t have to walk the talk and eat their own dog food).
At T=14, the actual corpo kitsch moment arrives. Whoo Hoo! It is announced that the test results will (supposedly) only be shared between HR, the line manager, and the test taker. They are supposed to provide meaningful, self-awareness.
Actually, T=14 hasn’t arrived yet. Hopefully, S&M will provide a follow up guest post, starting at T=15, where she begins describing her and her colleagues’ newly found meaning and quantum increase in self-awareness. We’ll also hopefully get an update on how the “agile transformation” is coming along.
Note1: BD00.com welcomes guest bloggers. The editorial office is open 24 X7. Like the Korpo Kitsch dude above, we’re here to help you.
Note2: This just in. Serial Mom has promised a sequel guest post at a date to be determined later.
POP! Whoosh! Pfft!
An integral part of my almost-daily gym workout is doing push ups with the aid of a balance ball. The sequence of events progresses as follows:
Well, yesterday things didn’t go as planned. As I was rolling across the top of the ball to get into the push-up-ready position, I heard a loud POP! I then proceeded to crash onto the mat:
The diagram doesn’t do the event justice. It wasn’t a gradual fall from grace. Since the ball was thin-skinned (like BD00), it was a fast crash. As you might surmise, a long and hearty LOL! was shared by all who witnessed the event.
Since the World Gym that I go to is open 24 X 7, it has 8 cameras distributed all around the facility. I’ve asked the owner to please sift through the video coverage and clip out my “ball-busting” segment. If/when she gets the video snippet, I’ll try to post it here so you can get a big LOL! out of it too.
Big, No, And Just Enough
Assume (which is a bad thing to do) that you can characterize a project by three activities: Planning, Designing, and Building. Next, assume (which is still a bad thing to do) that the planning and designing activities can each be sub-characterized by “Big“, “No“, and “Just Enough“.
Forgetting about what “Just Enough” exactly means, check out this methodology-agnostic probability density function:
Do you think the curve is right? You better not. The sample size BD00 used to generate it is zero,
One Or Many
The figure below models the increase in team stress level versus time for waterfall and time-boxed projects. As a project nears a delivery date, the stress levels increase dramatically as the team fixes turds, integrates individually developed features into the whole, and takes care of the boring but important stuff that nobody wanted to do earlier.
One tradeoff between the two types of projects is maximum stress level vs. number of stressful events. The maximum level of experienced stress is much higher for waterfall than any one time-boxed sprint, but it only occurs once as opposed to monthly. Pick your poison: a quick death by guillotine or a slow death by a thousand cuts.
Agilistas would have everyone believe that time-boxed projects impose a constant but very low level of healthy stress on team members while waterfall quagmires impose heart-attack levels of stress on the team. They may be right, because…..
(In case you haven’t noticed, BD00 is feeling the need to use the Einstein pic above more and more in his posts. I wonder why that is.)
Codecharts
The Magical Number 30
In agile processes, especially Scrum, 30 is a magical number. A working product increment should never take more than 30 days to produce. The reasoning, which is sound, is that you’ll know exactly what state the evolving product is in quicker than you normally would under a “traditional” process. You can then decide what to do next before expending more resources.
The trouble I have with this 30 day “law” is that not all requirements/user-stories/function-points/”shalls” are created equal. Getting from a requirement to tested, reviewed, integrated, working code may take much longer – especially for big, distributed systems or algorithmically dense components.
Arbitrarily capping delivery dates to a maximum of 30 days and mandating deliveries to be rigidly periodic is simply a marketing ploy and an executive attention grabber. When managers and executives accustomed to many man-months between deliveries get a whiff of the “30 day” guarantee, they: make a beeline to the nearest agile cathedral; gleefully kneel at the altar; and line up their dixie cups for the next round of kool-aid.
When I Was Born
Last Thursday, I went to the fabulous Oak Hill Country Club in Rochester NY to watch the opening round of the PGA golf championship. In prepping for the trip, I flipped through my considerable collection of gaudy Loudmouth golf shorts to pick out the pattern I would wear. In short order, I decided to to wear my cherry bombs.
As you might guess, I received lots of comments while cruising the course all day among tens of thousands of other people. Most of them were along the lines of “cool shorts” – especially from young kids. One dude asked me if I lost a bet, to which I replied “how did you know?“. Another guy asked me “when did you decide that you just don’t care?“. After a quick LOL, I told him “I don’t know exactly when, but perhaps it was when I was born“.
From Without
There comes into every life a time when the inner self can no longer be reached by things from without, when the soul craves that which it can supply to itself alone. – William Zinsser
What a wonderful quote from “Writing To Learn“, no? It resonates with me because it fits me like a glove. Despite the fact that societies expect their members to want, and actively strive for so-called “success“, I’m so over that.
For a long time, I beat myself up for not being more ambitious and not wanting to prove to the world how great I am. But at some point in my life, and I don’t know when or what triggered the change in behavior, I stopped trying to conform to the societal expectation of attempting to “reach my soul by things from without“. And I’m grateful for that.
How about you, dear reader? Are you constantly attempting to reach your immaterial soul by feeding it with material from without?
Just Say No!
Whoo Hoo! The Dr. “No” movement is upon us!
One currently popular way to carve out a money-making niche for yourself is to simply prefix any popular technology with the word “No“. Take your pick: NoUML, NoSQL, NoWaterfall, NoCMMI, NoBDUF, NoSh*t.
How about NoAgile? Who’s gonna be the brave NoSoul that goes there?
The Current Crop
There are a bazillion books on C++03 out in the wild. However, even though there are lots of pieces of C++11 material available for consumption online, there are (AFAIK) only 6 C++11 books currently available:
Lucky BD00. He has 24 X 7 e-access to all of these tomes through his Safari Books Online membership.
Note that even though he has some C++11/14 training material available for purchase on his web site, none of Scott Meyers‘ “Effective” series of C++ books has been updated yet. Fear not. The first in the series, “Effective C++11/14“, is coming to market in early 2014. The description of Scott’s upcoming GoingNative 2013 session, titled “An Effective C++11/14 Sampler“, reads as follows:
After years of intensive study (first of C++0x, then of C++11, and most recently of C++14), Scott thinks he finally has a clue. About the effective use of C++11, that is (including C++14 revisions). At last year’s Going Native, Herb Sutter predicted that Scott would produce a new version of Effective C++ in the 2013-14 time frame, and Scott’s working on proving him almost right. Rather than revise Effective C++, Scott decided to write a new book that focuses exclusively on C++11/14: on the things the experts almost always do (or almost always avoid doing) to produce clear, efficient, effective code. In this presentation, Scott will present a taste of the Items he expects to include in Effective C++11/14. If all goes as planned, he’ll also solicit your help in choosing a cover for the book.
It’s about time that Scott got a clue. 🙂


















