ContentsApplication DesignAvoiding "Analysis Paralysis"

Previous: Advantages of loosely-coupled design | Next: Better Tools

These are a lot of things to think about, aren't they? They are daunting when you combine them with the issues I haven't talked about... OO design patterns, the nuances of the Java language, interactions with the end users, maintenance of existing systems, the standards and policies of your employer, etc.

How does one ever actually get to the point of writing code? There are truly enough different things to conscientiously be concerned about that many people avoid committing anything to code. They become continual theorists. They cannot be productive because they are concerned with all of the things they need to think about.

Know anyone like that? I do. I am. It takes a deliberate effort on my part to draw the line and admit that I don't know enough to do all of what needs to be done; but that I'll have to get something working before I can improve on it.

The cure for "Analysis Paralysis" is to build a prototype. Build a mockup of the system with the intent to throw it away. It will be good for you, because you will learn what to do and what not to do. It will be good for your end users because they can see something and take direction from your interpretation of their needs. It will be good for the life of the application because the production version will be much more mature - since you will have adopted a workable design before starting it's development.

Building a prototype sounds like a waste of effort to some managers. You may need to sell the point, because some software engineering texts stress design perfection (which doesn't exclude prototypes, but implies that they aren't necessary). If confronted with a manager who takes this position, remind them that the Apollo 11 lunar landing was preceded by many years of missions that were admittedly prototypes - including all of the Mercury and Gemini space flights. NASA wasn't sure about how to do everything, so they had to make prototypes. If it weren't for those "wasted" missions, Apollo 11 would very likely have ended in disaster - regardless how well it was planned and executed.

Look into "Extreme Programming" - it will make your projects more successful.

ContentsApplication DesignAvoiding "Analysis Paralysis"

Previous: Advantages of loosely-coupled design | Next: Better Tools