Archive

Author Archive

By Default

May 18, 2013 1 comment

Much has been written about the differences between, and similarities across, management and leadership. But unsurprisingly, most managers equate the word “manager” with the word “leader” by default. After all, they’ve been appointed by other “leaders“. Thus, by (their) definition, managers are leaders.

On the other hand, most raw employees equate the word “manager” with “manager” by default.  Err, on second thought, since (as usual) he has no supporting “data“, this BD00 post is prolly full of BS00:

Our old arrogant, egotistical nature (continuously) seeks out sustaining agreement with itself and its distorted opinions. – William Samuel

Default Views

Categories: management Tags: ,

A Danger To Themselves And Others

May 16, 2013 3 comments

“Efficient systems are dangerous to themselves and others” – John Gall

A new system is always established with the goal of outright solving, or at least mitigating, a newly perceived problem that can’t be addressed with an existing system. As long as the nature of the problem doesn’t change, continuously optimizing the system for increased efficiency also joyfully increases its effectiveness.

However, the universe being as it is, the nature of the problem is guaranteed to change and there comes a time where the joy starts morphing into sorrow. That’s because the more efficient a system becomes over time, the more rigid its structure and behavior becomes and the less open to change it becomes. And the more resistant to change it becomes, the more ineffective it becomes at achieving its original goal – which may no longer even be the right goal to strive for!

Eff vs Eff

In the manic drive to make a system more efficient (so that more money can be made with less effort), it’s difficult to detect when the inevitable joy-to-sorrow inflection point manifests. Most managers, being cost-reduction obsessed, never see it coming – and never see that it has swooshed by. Instead of changing the structure and/or behavior of the system to fit the new reality, they continue to tweak the original structure and fine tune the existing behaviors of the system’s elements to minimize the delay from input to output. Then they are confounded when (if?) they detect the decreased effectiveness of their actions. D’oh! I hate when that happens.

Thought Actual

Revolution, Or Malarkey?

May 14, 2013 4 comments

BD00 has been following the development of Ivar Jacobson et al’s SEMAT (Software Engineering Method And Theory) work for a while now. He hasn’t decided whether it’s a revolutionary way of thinking about software development or a bunch of pseudo-academic malarkey designed to add funds to the pecuniary coffers of its creators (like the late Watts Humphrey’s, SEI-backed, PSP/TSP?).

To give you (and BD00!) an introductory understanding of SEMAT basics, he’s decided to write about it in this post. The description that follows is an extracted interpretation of SEMAT from Scott Ambler‘s interview of Ivar:  “The Essence of Software Engineering: An Interview with Ivar Jacobson”.

As the figure below shows, the “kernel” is the key concept upon which SEMAT is founded (note that all the boasts, uh, BD00 means, sentences, in the graphic are from Ivar himself).

In its current incarnation, the SEMAT kernel is comprised of seven, fundamental, widely agreed-on “alphas“. Each alpha has a measurable “state” (determined by checklist) at any time during a development endeavor.

SEMAT Kernel

At the next lower level of detail, SEMAT alphas are decomposed into stateful sub-alphas as necessary:

SEMAT Sub-Alphas

As the diagram below attempts to illustrate, the SEMAT kernel and its seven alphas were derived from the common methods available within many existing methodologies (only a few representative methods are shown).

Agile Over SEMAT

In the eyes of a SEMATian, the vision for the future of software development is that customized methods will be derived from the standardized (via the OMG!) kernel’s alphas, sub-alphas, and a library of modular “practices“. Everyone will evolve to speak the SEMAT lingo and everything will be peachy keen: we’ll get more high quality software developed on time and under budget.

SEMAT Practices

OK, now that he’s done writing about it, BD00 has made an initial assessment of the SEMAT: it is a bunch of well-intended malarkey that smacks of Utopian PSP/TSP bravado. SEMAT has some good ideas and it may enjoy a temporary rise in popularity, but it will fall out of favor when the next big silver bullet surfaces – because it won’t deliver what it promises on a grand scale. Of course, like other methodology proponents, SEMAT’s advocates will tout its successes and remain silent about its failures. “If you’re not succeeding, then you’re doing it wrong and you need to hire me/us to help you out.

But wait! BD00 has been wrong so many times before that he can’t remember the last time he was right. So, do your own research, form an opinion, and please report it back here. What do you think the future holds for SEMAT?

Should, Or Could?

There’s quite a difference between thinking and behaving as if “the world should be better aligned with my wishes!” and “the world could be better aligned with my wishes“. If your psychic disposition is toward the former, you’ll most likely be walking around frustrated and bitchy most of the time. If it’s toward the latter, you’ll most likely be more accepting and graceful.

BD00 seems to think that he’s been experiencing a slow shift over the years from thinking in terms of “should!” to thinking in terms of “could“. But of course, it may be just another one of those self-delusions that are packed wall to wall inside of his crippled mind.

Should Could

Categories: spirituality Tags:

The Evolution Of Thinking

Nassim Taleb nails it with this simple but profound sentence:

Our minds are not quite designed to understand how the world works, but, rather, to get out of trouble rapidly and have progeny. – Nassim Taleb (Fooled By Randomness)

Programmed

We human beings are so full of ourselves. With much hubris, we auto-assume that we are above all other life forms just because we can “think“. We concoct immortal and all-powerful gods in our minds who we “think” are watching over our well-being (but not the well being of those we don’t like). Then, when something terrible happens, we wonder “why” our gods could allow such a tragedy. Instead, maybe we should contemplate “why not?“.

The ability to “think” has unquestioningly made life more comfortable locally for the human race over time. However, it’s questionable whether “thinking” has made human life more comfortable globally. Unlike a “mindless” swarm of locusts that ravish the environment with a vengeance, we “mindful” humans seem to be ravishing our environment and other fellow humans at an increasingly alarming rate as our “thinking” supposedly evolves.

Thinking Evolution

Mind Full, or Mindful?

May 8, 2013 1 comment

Years ago, I watched a televised debate between Deepak Chopra and atheist Sam Harris. Since Deepak came across at times as defensive, I’ve never felt the need to delve into any of Deepak’s books. Nevertheless, since I instantaneously fell in love with this telling picture from the Chopra LinkedIn post “The Conscious Lifestyle: Awareness Skills“, I just had to copy and paste it here:

Attention

They Do Us!

Sensors AND Actuators

Motherbuckers

I love discovering people and companies that buck the current “kool and hip” trends followed religiously by the herd (mooo!). One of these motherbuckers is Evernote Inc. I’m not an Evernote user, but the app is phenomenally successful and has an enthusiastic following.

In “One Reason Everyone Has Outsourced Their Brains To Evernote | Fast Company”,  Evernote CEO Phil Libin says:

We do everything native. That was actually the big decision. Right from the beginning we said, “No common denominator crap.” No HTML5. Just all native on every platform.

You would think that it makes no business sense to maintain a separate, resource-sucking team for each supported platform, but think again:

Yes, it’s really expensive. Yes, it takes a ton of developers. But it works for Evernote: As Libin says, they’ve got independent teams for every platform. They compete to make the best version, steal from each other, and leapfrog one another. Since each platform is different–BlackBerry, for instance, has that keyboard thing–the versions are tailored to them. And each fits. – FastCompany

Evernote

Uncomfortable With Ambiguity

April 30, 2013 6 comments

Uncertain: Not able to be relied on; not known or definite

Ambiguous: Open to more than one interpretation; having a double meaning.

Every spiritual book I’ve ever read advises its readers to learn to become comfortable with “uncertainty”  because “uncertainty is all there is“. BD00 agrees with this sage advice because fighting with reality is not good for the psyche.

pema chodron

Ambiguity, on the other hand, is a related but different animal. It’s not open-ended like its uncertainty parent. Ambiguity is the next step down from uncertainty and it consists of a finite number of choices; one of which is usually the best choice in a given context. The perplexing dilemma is that the best choice in one context may be the worst choice in a different context. D’oh!

Vengeance

Many smart people that I admire say things like “learn to be comfortable with ambiguity“, but BD00 is not onboard with that approach. He’s not comfortable with ambiguity. Whenever he encounters it in his work or (especially) in the work of others that his work depends on for progressing forward, he doggedly tries to resolve it – with whatever means available.

The main reason behind BD00’s antagonistic stance toward ambiguity is that ambiguity doesn’t compile – but the code must compile for progress to occur. Thus, if ambiguity isn’t consciously resolved between the ambiguity creator (ambiguator) and the ambiguity implementer (ambiguatee) before slinging code, it will be unconsciously resolved somehow. To avoid friction and perhaps confrontation between ambiguator and ambiguatee (because of differences in stature on the totem pole?), an arbitrary and “undisclosed” decision will be made by the implementer to get the code to compile and progress to occur- most likely leading to functionally incorrect code and painful downstream debugging.

So, BD00’s stance is to be comfortable with uncertainty but uncomfortable with ambiguity. Whenever you encounter the ambiguity beast, consciously attack it with a vengeance and publicly resolve it ASAP with all applicable stakeholders.

Ambig