If We Had Started Coding Already ...
Many predators hunt based on movement. In fact, even with their keen eyesight, they cannot really "see" unless the prey itself moves. Consequently, many hunted animals are programmed literally to "freeze with fear." Not a bad move if it tends to save your life.
Recently, I had the chance to review a major-league mess at a large organization that didn't "freeze with fear." I won't go into all the details, but let's just say they got on with the coding phase of a large project way too early. The wounds are deep, and one way or another, the company will ooze red ink, its very lifeblood. Where did it go wrong? The usual no architecture, no business rules, no top-down business model.
On the software side, the company was sold a bill of goods. It was promised that a breakthrough software product could replace their legacy systems in four months. (Yes, they should have known better.) To go with that was a spiral "methodology" based on the mantra, "analyze a little, design a little, code a little, test a little." The company learned the hard way what that actually means in practice-rewrite a lot, for a very long time.
Projects out of control, and belief in the fairy godmother-these are nothing new. I know this has been said many times, but let me say it yet again. There are simply no silver bullets. You need to do a business model before you do your system design, and you need to do your system design before you start your coding. That is, unless you can afford to spend the rest of your life in rewrites and "maintenance."
So, what does "analysis paralysis" really indicate? Maybe that...
The business problem itself is hard. Do you believe that thinking about it in a coding language (or in IT system models) will make it easier?
You don't really know what the business problem is. In that case, the cure may prove a lot worse than the disease.
You can't get the right answers from the right people. Then what exactly are your chances of success?
You have significant differences of opinion about the business itself. Do you think programmers will make better choices?
The future is hard to predict. Do designers and programmers have better crystal balls?
You don't really know what is needed. So rolling the dice is the right answer?
There's actually no answer to the business problem as posed. Better rethink the business problem up front!
You're simply not smart enough to solve it. I doubt that, not if you get the right people together.
You don't have the right approach. That's the most likely one. Think architecture, business rules, and a top-down business model, and you'll be O.K.
So the next time you hear anyone say watch out for "analysis paralysis," I hope you will take pause. Just freeze-it may save your life. Somewhere close by there's probably a programmer poised to pounce on a keyboard.
© 1999, Ronald G. Ross.
About our Contributor:
BRSolutions Professional Training Suite
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Semantics of Business Vocabulary and Business Rules