Archive
Analysis Paralysis Vs. 59 Minutes
“If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions” – Albert Einstein
If they didn’t know that Einstein said the quote above, MBA taught and metrics-obsessed “go-go-go” textbook managers would propose that the person who did say it was a slacker who suffered from “analysis paralysis”. In the Nike age of “just do it” and a culture of “act first and think later” (in order to show immediate progress regardless of downstream consequences), not following Einstein’s sage advice often leads to massive financial or human damage when applied to big, multi-variable hairball problems.
The choice between “act first, think later” (AFTL) and “think first, act later” (TFAL) is not so simple. For small, one dimensional problems where after-the-fact mistakes can be detected quickly and readjustments can be made equally as quickly, AFTL is the best way to go. However, most managers, because they are measured on schedule and cost performance and not on quality (which is notoriously difficult to articulate and quantify), apply the AFTL approach exclusively. They behave this way regardless if the situation cries out for TFAL because that’s the way that hierarchical structured corpo orgs work. Since the long term downstream effects of crappy decisions may not be traceable back to the manager who made them, and he/she will likely be gone when the damage is discovered, everybody else loses – except the manager, of course. Leaders TFAL and managers AFTL.
FAI = Frontal Assault Idiot
Since I already have a post regarding the FAE, why not supplement it with one on the FAI?
The other day, my friend and mentor, Bill Livingston, rightfully and truthfully called me an FAI. The picture says it all. No more words are needed, except for: “poor me, boo hoo”.
Decision Making Stalemate
Joel Spolsky is one of my favorite software philosophers. Joel sticks to fundamental principles no matter what the latest flavor of snake oil is being preached at the moment.
In this blog post, Endless Debate, Joel states:
“A terribly common error is having a debate over how something should be designed, and then never resolving the debate“.
He follows that with:
“In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end. These are the most likely projects to fail.”
In addition to political reasons, I’d also like to add fear. In alpha male dominated corpo cultures, fear drives the non-alpha members of the group. The titled alphas (a.k.a. managers) rule the roost and the non-alphas go silent when an alpha asserts himself – even if the alpha hasn’t got a clue on what the right course of action is.
Yes Master!
I don’t agree with Joel’s assertion that “all decisions are pushed to the end”. Because of schedule pressure and the fear of reprisal if the alpha’s instructions aren’t followed, the programmer(s) quietly implement the alpha’s horrendous decision in either code, design, or architecture.
The downstream ramifications of implementing the wrong decision get worse depending at which level of abstraction they are manifest. When the customer: gets the software, discovers the problem, and demands that it be fixed, the alphas are quick to blame the programmers since it’s often impossible, or not politically correct, to trace the problem back to it’s root cause – the bozo alpha’s poor technical decision.
Who said that life was fair?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 