Design and the Importance of.

It is very good practice to design any applications well and thouroughly before commencing work on them. Here is the process that I prefer to take (and have taken in all recent projects):

1. Harvest as many customer requirements as possible.
2. Try to understand the way that your customers think, and write a small document listing the requirements as you understand them, trying to fit them into what the customers are trying to tell you.
3. Hand the document to co-workers and benevolent customers, asking them for as much feedback as possible.
4. Think seriously about the feedback, do not be offended to matter how scathing some of it may be. Try to put as much feedback back into the document as possible.
5. Create a preliminary specification covering as many points in the requirements as possible. Leave placeholders where you are unsure.
6. Hand this document to the same people to be checked again. Repeat the process until you are satisfied.
7. Design a structural specification. Define how different modules in your application are going to plug in to each other, and how they will communicate.
8. Hand the structural specification to your co-workers (after first proof-reading it), and correct any fallacies that they may find.
9. Test your concepts. Write several small applications to test certain ideas in the structural specification where you do not have experience. DO NOT use any of this code in the final product.
10. Once you have a good handle on how the application is going to fit together, hand out different modules to the correct people (perhaps only yourself) and begin coding. Again, if you become unsure about certain aspects, write some more proof of concept applications. You really should document anything that you have been unsure about, and found the right answer for.
11. After that, it is up to the QA of your company and yourself to find any bugs. Document all bugfixes that you make. This will help prevent you from making the same mistakes in the future.
12. All bugs found should be properly documented. Something like Bugzilla is really good.

Remember that proper planning may make the project seem slow at first, but it will save a lot of money and time in the long run. It will also majorly enhance the quality of the end product. The proof of concept applications will also serve to improve your programming skills to no end, before you even begin work on the actual project. If proper planning is not undertaken from the start, the price will be paid. As the project become larger and more convoluted, you will spend most of your time maintaining it with very little time for adding more features, and working on new products.

In the past, I have taken what were the requirements at the time, with no regard to the future. I delved directly into coding without thinking about future expandibility. This is biting me right now as I struggle to add new protocols, new parameters and features without ruining the structure of the application. I am very fortunate that I am fixing more bugs than I am creating, but I am certainly spending far far far too much time on it.

Another note, if people say bad things about your product, they are probably right. Maybe not fully correct, but correct enough for you to rethink your strategy. Luckily most of my complaints come from co-workers, and not from the customer. But I do know that my unplanned project has been becoming more and more awkward to use. The new one that I am working on now has been designed with all my past mistakes in mind.