Archive
Grateful For Gratitude
For today’s post, I felt the need to lock BD00 away for just a bit and share this twitversation with y’all. I may have to delete it when the bastard breaks the lock and sees what I’ve done to his blasphemous blog. D’oh!
The title of this post somehow reminds me of the old cereal commercial: “Cuckoo For Cocoa Puffs!“.
Left And Right
The Manifesto for Agile Software Development is rightly credited with launching the agile revolution and catalyzing the birth of methodologies like XP, DSDM, and Scrum. The following four major tenets supposedly underpin every single agile methodology.
In theory, not many people (with the exception of a pure bred bureaucrat) could argue effectively against preferring the soft left side over the hard right side of the table.
In practice, the situation is often much different than the theory. While espousing the need to operate in accordance with the left side, many so-called leaders stick to their 20th century guns behind the rhetoric. They demand process and tool compliance, dumpsters full of useless forms/documents/metrics, formal, penalty-laden contracts, and preposterously huge, upfront project plans.
BD00 posits that the reasons managers and executives demand conformance to the tenets on the right while espousing the ones on the left are one or more of the following:
- They don’t sincerely believe that the stuff on the left can possibly lead to higher quality products and faster delivery times than the stuff on the right.
- They can’t shed their personal fears of loss of control and loss in stature if they switch operating modes from the right to the left.
- They have no idea how to ignite the shift to the left (other than rhetoric).
- Their hands are tied because big customers (like the government and Fortune 500 companies) demand all the hulking, time-consuming, and expensive stuff on the right.
- They’ve made tons of money operating in accordance with the principles on the right both before and (many years) after the introduction of the agile manifesto.
Maybe that’s why I chuckle every time this quote comes to mind:
Everybody’s doing agile these days, even those who aren’t. – Scott Ambler
What do you think, dear reader? Are there any other reasons that should be added to the list? Do you think that the ratio of fake-to-real agile orgs is high or low? Is it increasing or decreasing with time?
All Forked Up
I dunno who said it, but paraphrasing whoever did:
Science progresses as a succession of funerals.
Even though more accurate and realistic models that characterize the behavior of mass and energy are continuously being discovered, the only way the older physics models die out is when their adherents kick the bucket.
The same dictum holds true for software development methodologies. In the beginning, there was the Traditional (a.k.a waterfall) methodology and its formally codified variations (RUP, MIL-STD-498, CMMI-DEV, your org’s process, etc). Next, came the Agile fork as a revolutionary backlash against the inhumanity inherent to the traditional way of doing things.
The most recent fork in the methodology march is the cerebral SEMAT (Software Engineering Method And Theory) movement. SEMAT can be interpreted (perhaps wrongly) as a counter-revolution against the success of Agile by scorned, closet traditionalists looking to regain power from the agilistas.
On the other hand, perhaps the Agile and SEMAT camps will form an alliance and put the final nail in the coffin of the old traditional way of doing things before its adherents kick the bucket.
SEMAT co-creator Ivar Jacobson seems to think that hitching SEMAT to the Agile gravy train holds promise for better and faster software development techniques.
Who knows what the future holds? Is another, or should I say, “the next“, fork in the offing?
Management Idiots And Programming Idioms
In TC++PL, Bjarne Stroustrup introduces the concept of a class hierarchy with this simple business world example:
Temporary and Employee base class “objects” get paid by the company to do work that directly creates value. Manager objects inherit an Employee’s responsibilities and encapsulate new, manager-specific, behaviors; like monitoring/commanding/reprimanding non-manager Employees, Temps, and Assistants. Proceeding down the inheritance tree on the right, a Director object inherits the behaviors of both the Manager and Employee classes while adding new “directorial” behaviors.
When BD00 saw Bjarne’s inheritance tree example, he said to himself “Dude, you got it wrong. If you wanted to model the real world, here’s what you shoulda presented“:
It woulda added a touch of edgy humor to the book, dontcha think?
When I write my first programming book, I’m gonna have diagrams like that and code fragments like this in it:
I’m thinking of hatching a kickstarter.com project and titling the hybrid book something like “Management Idiots And Programming Idioms“. What would you name it, and would you buy it?
Mistrust Over Teamwork
Because I’ve stumbled upon several rave reviews of the book, I started reading “Team Geek“.
Right off the bat, the authors present this brilliant endlessorigami.com graphic:
D’oh! Maybe that’s why it’s so hard to become a good “team player“.
But why do group projects tend to teach mistrust instead of teamwork? Could it be because the ancient hierarchical structures and individual-centric reward policies baked into the vast majority of institutions demand an “it’s all about me” attitude?
Of course not. When someone is castigated by HR for not being a “rah-rah” team player, it’s because of personal failure – not because of dysfunctional organizational structures and policies, right?
No Runtime Overhead
Since I have the privilege of using C++11/14 on my current project, I’ve been using the new language idioms as fast as I can discover and learn them. For example, instead of writing risky, exception-unsafe, naked “new“, code like this:
I’ve been writing code like this instead:
By using std::unique_ptr instead of a naked pointer, I don’t have to veer away from the local code I’m writing to write matching delete statements in destructors or in catch() exception clauses to prevent inadvertent memory leaks.
I could’ve used a std::shared_ptr (which can be copied instead of “moved“) in place of the std::unique_ptr, but std::shared_ptr is required to maintain a fatter internal state in the form of strong and weak owner counters. Unless I really need shared ownership of a dynamically allocated object, which I haven’t so far, I stick to the slimmer and more performant std::unique_ptr.
When I first wrote the std::unique_ptr code above, I was concerned that using the std::move() function to transfer encapsulated memory ownership into the safeTgtList vector would add some runtime overhead to the code (relative to the C++98/03 style of simply copying the naked pointer into the scaryTgtList vector). It is, after all, a function, so I thought it must insert some code into my own code.
However, after digging a little deeper into my concern, I discovered (via Stroustrup, Sutter, and Meyers) that std::move() adds zero runtime overhead to the code. Its use is equivalent to performing a static_cast on its argument – which is evaluated at compile time.
As Scott Meyers stated at GoingNative13, std::move() doesn’t really move anything. It simply prepares for a subsequent real move by casting its argument from an lvalue to an rvalue – which is required for movement of an object’s innards. In the previous code, the move is actually performed within the std::vector::emplace_back() function.
Quoting Scott Meyers: “think of std::move() as an rvalue_cast“. I’m not sure why the ISO C++ committee didn’t define a new rvalue_cast keyword instead of std::move() to drive home the point that no runtime overhead is imposed, but I’d speculate that the issue was debated. Perhaps they thought rvalue_cast was too technical a term for most users?
Update 10/25/13
As I said early in the post, the code example is “like” the code I’ve been writing. The real code that triggered this post is as shown here:
Since each “entry” CfarDetState object must be uniquely intialized form it’s associated CfarCrossing object, I can’t simply insert estd::make_unique<CfarDetState>() into the emplace_back() function. All of the members of each “entry” must be initialized first. Regardless of whether I use emplace_back() or push_back(), std::move(entry) must be used as the argument of the chosen function.
Another One Bites The Dust
Another one bites the dust. Another one bites the dust. And another one gone, and another one gone… – Queen
Companies that have a superficial dual career ladder love to delude themselves into thinking they have a real one. The alternative, which is “unacceptable!” because it would trigger an unsettling feeling of cognitive dissonance and undermine a self-image of infallibility, is to simply own up to the inconsistency and stop lying to themselves and their constituents.
It’s always a sad affair to watch brilliant engineers jump from the dead-end technical ladder to the golden management ladder because it’s the only way they can do more for themselves and their families.
Sometimes the “promotion” works out fine for both the org and the newly minted manager. But sometimes it achieves a double loss. The engineer morphs into a crappy manager with poor people skills, a propensity to obsess over schedules, and a bent toward micro-managing technical details. Plus (or should I say minus?), the org’s product development group loses precious technical expertise. D’oh! I hate when that double whammy happens.
Photobomb!
With teammate Corey P.’s wedding date looming on Saturday, we broke out the old ball-and-chain and cuffed him to it for the day. If you haven’t guessed, the name of his fiancee is Katrina.
And yes, that’s the inimitable BD00 in the background doing what he does best – mucking up the worx like a juvenile delinquent .
So Much More
If you haven’t seen the following hilarious and entertaining “I Quit” youtube video, then you’ve been living in a cave for too long. It’s gone viral with over 14 million hits as of this writing.
The fact that so many people tuned in says a lot about how organizations operate in the 21st century. Sure, there’s been some progress in injecting more humanity into the workplace since the dawn of the 2oth century, but there’s so much more that can be done.
Sadly, the dudes who have the power to get it done don’t want it to get done. It’s all about ego, loss of control, loss of stature, yada, yada, yada. Take your pick.
It is difficult to get a man to understand something, when his salary depends upon his not understanding it. – Upton Sinclair
PLAN MORE!
Check out this 20th century retro banner that BD00 stumbled upon whilst being given a tour of a friend’s new workplace:
OMG! The smug agilista community would be outraged at such a bold, blasphemous stunt! But you know what? BD00’s friend’s org is alive and well. It’s making money, the future looks bright for the business, and the people who work there seem to be content. Put that in your pipe and stoke it up.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 