Archive
In Memory Of “Chainsaw” Al
ASSume that you’re a member of the infallible leadership team of an impeccable and squeaky clean kingdom like the one shown below. It’s interesting how your “who supervises who” stovepipe chart looks yawningly the same as everyone else’s and yields no clue as to how your borg operates on a day to day basis, no?
Next, assume that everything is cruising along splendidly. The dough is rolling in, everyone feels productive and happy (well, at least you and your cohorts feel that way), and you believe your own rhetoric until — BAM, the fit hits the shan. D’oh!
Of course, being a member of the elite and unquestionably infallible team in the penthouse, the crisis was certainly thrust upon you by forces beyond your control. The world suddenly, instantaneously, turned against you in a perfect storm of destruction. Unlike the good times, in which you naturally look in the mirror for the cause of success, in the bad times you conveniently look out the window for the cause of failure.
So, what creative solution do you conjure up to dissolve the crisis? Well, duh, you don your “Chainsaw” Al mask and start hacking away at the roots of your borg while leaving the branches that prop you up into the sky intact….
Whoo hoo, crisis solved! Err…. was it? Can the last remaining method of simplification and a pack of golden parachutes be in the offing?
Hostile, Cruel, And Wasteful
From an interview with C++ creator Bjarne Stroustrup, I give you this:
Corporate practices can be directly hostile to individuals with exceptional skills and initiative in technical matters. I consider such management of technical people cruel and wasteful. – Bjarne Stroustrup
I think this may be the main reason why brilliant technical startup companies are born. In an ironically altruistic twist, the unconsciously idiotic ways in which DYSCO SCOLs treat their best human “resources” (sic) hurt themselves while simultaneously benefiting the world.
Dissin’ Boost
To support my yearning for learning, I continuously scan and probe all kinds of forums, books, articles, and blogs for deeper insights into, and mastery of, the C++ programming language. In all my external travels, I’ve never come across anyone in the C++ community that has ever trashed the boost libraries. Au contraire, every single reference that I’ve ever seen has praised boost as a world class open source organization that produces world class, highly efficient code for reuse. Here’s just one example of praise from Scott Meyers‘ classic “Effective C++: 55 Specific Ways To Improve Your Programs And Designs“:
Notice that in the first paragraph, I wrote the word external in bold. Internal, which means “at work” where politics is always involved, is another story. Sooooo, let me tell you one.
Years ago, a smart, highly productive, and dedicated developer who I respect started building a distributed “framework” on top of the ACE library set (not as a formal project – on his own time). There’s no doubt that ACE is a very powerful, robust, and battle-tested platform. However, because it was designed back in the days when C++ compiler technology was immature, I think its API is, let’s say “frumpy“, unconventional, and (dare I say) “obsolete” compared to the more modern Boost APIs. Boost-based code looks like natural C++, whereas ACE-based code looks like a macro derived dialect. In the functional areas where ACE and Boost overlap (which IMHO is large), I think that Boost is head over heels easier to learn and use. But that’s just me, and if you’re a long-time ACE advocate you might be mad at me now because you’re blinded by your bias – just like I am blinded by mine.
Fast forward to the present moment after other groups in the company (essentially, having no choice) have built their one-off applications on top of the homegrown, ACE-based, framework. Of course, you know through experience that “homegrown” means:
- the framework API is poorly documented,
- the build process is poorly documented,
- forks have been spawned because of the lack of a formally funded maintenance team and change process,
- the boundary between user and library code is jagged/blurry,
- example code tutorials are non-existent.
- it is most likely to cost less to build your own, lighter weight framework from scratch than to scale the learning curve by studying tens of 1,000s of lines of framework code to separate the API from the implementation and figure out how to use the dang thing.
Despite the time-proven assertions above, the framework author and a couple of “other” promoters who’ve never even tried to extract/build the framework, let alone learn the basics of the “jagged” API and write a simple sample distributed app on top of it, have naturally auto-assumed that reusing the framework in all new projects will save the company time and money.
Along comes a new project in which the evil Bulldozer00 (BD00) is a team member. Being suspicious of the internal marketing hype, and in response to the “indirect pressure and unspoken coercion” to architect, design, and build on top of the one and only homegrown framework, BD00 investigates the “product“. After spending the better part of a week browsing the code base and frustratingly trying to build the framework so that he could write a little distributed test app, BD00 gives up and concludes that the bulleted list definition above has withstood the test of time….. yet again.
When other members of BD00’s team, including one member who directly used the ACE-based framework on a previous project, investigate the qualities of the framework, they come to the same conclusion: thank you, but for our project, we’ll roll our own lighter weight, more targeted, and more “modern” framework on top of Boost. But of course, BD00 is the only politically incorrect and blatantly over-the-top rejector of the intended one-size-fits-all framework. In predictable cause-effect fashion, the homegrown framework advocates dig their heels in against BD00’s technical criticisms and step up their “cost and time savings” rhetoric – including a diss against Boost in their internal marketing materials. Hmmm.
Since application infrastructure is not a company core competence and certainly not a revenue generator, BD00 “cleverly” suggests releasing the framework into the open source community to test its viability and ability to attract an external following. The suggestion falls on deaf ears – of course. Even though BD00 (who’s deliberately evil foot-in-mouth approach to conflict-handling almost always triggers the classic auto-reject response in others) made the helpful(?) suggestion, the odds are that it would be ignored regardless of who had made it. Based on your personal experience, do you agree?
Note 1: If interested, check out this ACE vs Boost vs Poco libraries discussion on StackOverflow.com.
Note2: There’s a whole ‘nother sensitive socio-technical dimension to this story that may trigger yet another blog post in the future. If you’ve followed this blog, I’ve hinted about this bone of contention in several past posts. The diagram below gives a further hint as to its nature.
Product Team
How can a software project have more managers and pseudo-managers “working” on it than developers – you know, those fungible people who write, debug, and test the product code that is the source of the borg’s income. You would think that this comically dysfunctional practice would stick out like a sore thumb and somebody upstairs would put the kabosh on it, no?
Tested And Untested
Being the e-klepto that I am, I stole this kool graphic from Humphrey and Over’s book “Leadership, Teamwork, And Trust“:
It represents the tested-to-untested (TU) region ratio of a generic, big software system. Humphrey/Over use it to prove that the ubiquitous, test-centric approach to quality doesn’t work very well and that by focusing on defect prevention via upfront review/inspection before testing, one can dramatically decrease the risk for any given TU ratio. Hard to argue with that, right?
The point I’d like to make, which is different than the one Humphrey/Over focus on in their book (to sell their heavyweight PSP/TSP methodology, of course), is that when a software system is released into the wild, it most likely hasn’t been tested in the wacky configurations and states that can cause massive financial loss and/or personal injury. You know, those “stressful” system states on the edge of chaos where transient input overloads occur, or hardware failures occur, or corrupted data enters the system. I think building the test infrastructure that can duplicate these doomsday scenarios – and then actually testing how the system responds in these rare but possible environments is far more effective than just adding political dog-and-pony reviews/inspections to one’s approach to quality. Instead of decreasing the risk for a fixed TU ratio, which reviews/inspections can achieve (if (and it’s a big if) they’re done right), it increases the TU ratio itself. However, since system-specific test tools are unglamorous and perceived as unnecessary costs by scrooge managers more concerned about their image than other stakeholders, scarily untested software is foisted upon the populace at an increasing rate. D’oh!
Note: The dorky hand made drawing above is the first one that I created with the $14.99 “Paper Tablet” app for my Livescribe Echo smartpen. “Paper Tablet” turns a notebook page into a surrogate computer tablet. When I run an “ink aware” app like Microsoft Visio, and then physically draw on a notebook page, the output goes directly to the computer app and it shows up on the screen – in addition to being stored in the pen. Thus, as I was drawing this putrid picture with my pen, it was being simultaneously regenerated on a visio page in real-time (see clip below). Kool, eh? Maybe with some practice……
Court Jester
Sally Bibb, in her deliciously subversive book, “The Stone Age Company“, states that the executives at British Airways formally appointed a “court jester” to keep their heads out of the clouds and so that they wouldn’t fall victim to their own rhetoric. Kudos to the leadership team at BA.
Sally’s book was published in 2005 (do ya think it sold well?). I wonder if the BA court jester position still exists today and how effective it is/was. I’d love to inteview the CJ(s).
Most Days, Some Days
On most days, the daily view statistics box for this blog looks something like this:
On some days, it looks like this:
It’s the trend in stats snapshots like this latter one that thrills me – not the total number of views. When I see one and two hits on a bunch of posts, as opposed to a bunch of hits on one or two posts, it indicates that I may have actually connected with someone on some level. What it doesn’t indicate, is whether it was a positive or negative connection.
How about you and your blog? What, you don’t write down and share at least some of your experiences, thoughts, ideas, and/or opinions? Why not?
Do one thing everyday that scares you. – Baz Luhrmann
Firing Up The Eclipse Erlide Plugin
To help me learn and practice writing source code in Erlang, I downloaded and installed the “Erlide” plugin for the Eclipse-Helios IDE. The figure below displays a snapshot of Eclipse with the default Erlang perspective opened up. The set of Erlang specific views that are displayed within the default perspective are: the editor, navigator, process list, and live expressions views. Each Erlang specific view is annotated with this kool little Erlide logo:
As you can see, the editor is showing the content of the “hello.erl” source code file, which contains the definition of the “hello/0” function. The console view at the bottom of the screen shows the result of manually typing in “hello:hello().“, which runs the program on the version 5.8.2 Erlang virtual machine (VM). Upon completion, the VM did what it was told. It printed, duh, : “Hello World!”.
The complete list of Erlide views available to aspiring Erlang programmers is shown below. Since I’m a newbie to the land of Erlang, I have no freakin’ idea what they do yet.
With the aid of the supplied eclipse Erlide help module (see below), I was easily able to configure and link the IDE to my previously downloaded and installed distribution of the Erlang VM.
The snapshot below shows the configurability options offered up by Erlide via the eclipse “Preferences” window. I won’t go into the details here, but the “Installed runtimes” option is where you connect up Erlide with your installed Erlang VM(s).
So, C++ programmers, what are you waiting for? Download the latest Erlang distro, the Erlide eclipse plugin (you do use eclipse, right?), buy a good Erlang book, and start exploring this powerful and relatively weird programming language.
Oh, and thanks to the great programmers who designed, wrote, and tested the Erlide Eclipse plugin – most likely on their own time. You guys and gals rock!
Norm And Dick
Since the main activity of some management chains seems to be preventing deviations from the norm, I propose that all managers change their names to “Norm“. It would complement “DICk” nicely, no?
Without deviation from the “Norm“, there can be no progress – Frank Zappa
Team Formation
Assuming all other things equal, which method of forming problem solving teams will produce the best results? Method A, of course. Why? Because Method B has never been tried. Why? Because…. that’s just the way it is – Method A only. Why? Cuz everyone knows, the boss is the smartest dude in the room. Why? Well, just because – dammit!
The led must not be compelled, they must be able to choose their own leader – Albert Einstein
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 