Do you suffer from Analysis Paralysis Syndrome?
Analysis Paralysis is an anti-pattern that not only slows you down, but may also prevent you from finishing or even starting the project! It is when you or others think too much about the design. There are too many detailed options available, which makes decision-making hard.
During my professional experience, I’ve observed the failure of projects with heavy upfront design and lots of supporting documentation. I’ve seen projects that cost a few million dollars with nothing to show for it except a few hundred pages of UML diagrams! I’ve seen designers try to model the “universe,” not the domain model of the application. If you’re building an application for a school to keep records on teachers, students and classes, that should be your focus. The fact that one of the teachers is a musician outside the school, has four children and his shoe size is 10 should not be of concern for your application! I’ve seen many designers try to abstract everything because they think that’s the way to develop software that can easily be changed. Yes, that is correct in theory, but it is not pragmatic!
Good design is not about changes. It’s about providing a good solution to a problem that can be implemented at a reasonable cost within a reasonable time frame. Let’s say you have three months to launch an application. You can choose to come up with a simple design that fulfills the needs of the application or spend six months building a super-duper design that predicts every change in the future. What would you do in this situation? I personally have done both! So speaking from experience, I’m telling you it’s much better to come up with something simple and practical that can give value to the world than some super-duper magical design that may potentially solve everybody’s problems but fails to make it to production! Leonardo Da Vinci said, “Simplicity is the ultimate sophistication.” I couldn’t agree more!
Real World Example
A few years ago I worked on a project to design a notification system that could potentially send out messages via SMS, pager, email and so on. At first I was very proud of my design and I thought it was very flexible! But after the website was launched, due to lack of budget for marketing, it never really took off. So we never used any kind of notification other than email. All the time I had spent on designing this super-duper notification system was wasted! And guess what? I was the one paying for this project! It was my own project. So I was wasted my own time and money!
Sometimes programmers focus so much on technicality and coding that they forget the other side is about business and money. Whoever you work for has a limited budget and it’s best to keep them happy by producing something practical and useful that can bring them more money. If you make your boss or client successful, you’ll be more successful yourself. You’ll most likely get a pay raise, a better position and more credits on your resume.
The KISS Principle
Keep it simple and straightforward. Aim for simplicity and avoid unnecessary complexity. Add features only when they are required. Don’t try to predict every change in the future. I’ll tell you something now and I want you to remember it forever: You can NEVER EVER EVER predict every change! Any change in the future is heavily dependent on the business side of the software you’re working on. It depends on the market, competition, politics, and finance. As a software developer, you cannot predict all that!