"Analysis Paralysis" often has a root cause: incompetence. A pal of mine was a consultant for a logistics company serving a large country that's north of the

"Analysis Paralysis" often has a root cause: incompetence. A pal of mine was a consultant for a logistics company serving a large country that's north of the U.S. This company was developing a package tracking system in Java, back around 2000 or so, when "Java" was often a synonym for "Project Failure." Now, when the whole thing started, I told him that I could knock off a prototype in a week in PHP. Nope, these guys decided to spend five months developing a framework for their application, and then they were going to spend the next month developing the actual app. Well, six months later, I hear that the predictable outcome had happened: management was shocked to discover that the application took 30 seconds to serve up a page view. My pal sent me a copy of the app and it was an absolute rat's nest: the kind of project where you use 1500 lines of code to say what you could say in 15. The sheer bulk of the code made it difficult to maintain: and it had poor performance written into it's DNA. The real problem was that this wan an IBM shop that was developing its first webapp, developing its first Java app and... nobody knew what they were doing. ----- Don't get me wrong. There's nothing wrong with front-loading your design and analysis work... IF YOU KNOW WHAT YOU ARE DOING! In the hands of people who have a holistic view of the application and toolset it's based on, front-loading is a beautiful tool that can make implementation and testing a breeze. However, because it delays feedback, prolonged analysis doesn't (necessarily) test the ideas behind a design. Bad ideas can get in, and stay in -- nothing challenges the arrogance of the uninformed. If, on the other hand, you are humble, and "know what you don't know", a rapid prototype can be a powerful way to get some experience, test your ideas, and, who knows, maybe even ship something.