Why - Risk at Development
As a programmer, sometimes I doubt whether I should wasting time to think and design about the application that I will develop or not. As a single programmer-architect, there are some self-defined projects where I usually start by code first or by design first. Logically, they should have produced the same result, thinking that the developer and the architect is the same person. Practically, I'm surprised that the project started with code first is tend to have more risk and more likely to be stopped than the one by design-first.
So, logic does not apply here? Yes it is. The reason is basically that the developer is human. and they will likely get bored because of several reasons:
- The project does not has exact requirement and scope
- The project does not has exact release strategy
- The project is most likely isn't needed by the user
The project does not has exact requirement and scope
Once, I have tried to create a so-called "ideal-best" application. The application should be able to handle many kind of business process. That application will be free of bug, easily extendable and has good architecture foundation. And the application can work as both transaction handling or event high level management reporting tools.
It sounds like a good plan at the beginning, however with such a big regards I need to drop the development because I got bored during developing it. It has no exact scope, no exact plan about what I must develop, what I must validate, how is the process after doing this and that, etc. The scope is growing and growing each day I think about the application, and the development cannot follow the planning growth. You have not target to accomplish, and caused you to loss interest in the development.
The project does not has exact release strategy
What I mean about the term of release strategy here is a strategy about how to deliver the application. It consist of release date, the audience and the platform target. It may has more details than that such as how to replace the current running application without breaking, or how to not breaking other applications which is dependent to it; but it's regarding what kind of application that want to be delivered.
Having no release date deadline (target) can affect the development scope, since you will think like "I have unlimited time to develop this" or "I can add this and that feature before delivering the application, since the release date isn't being decided".
Lack of audience target can also affect the scope, because you will try to create an application that can be used by any level of management (transaction level or event advanced-level ad-hoc reporting).
Lack of platform target can demoralize your development. You will be haunted by thoughts such as "will it works well in firefox, chrome, or IE?" or "will it works in other-windows operating system?". Thoughts like that will drag your development, because you will be bugged by how you will check them each time you make a modification. Don't be bugged by it!
The project is most likely isn't needed by the user
Any project needed by the user should has estimated release date. In terms of user, the faster the deliver date, the better. Sometimes you may think that this kind of application/enhancement will not be needed by the user. It can be because you can do manipulation to the database directly. This kind of thought can demoralize the development, since you don't know exactly how your application can give good benefits to the user. Don't develop any kind of application which won't be needed. Or if it will, don't ever think that the workaround (direct manipulation) can be the replacement of the application.
Conclusion
Always design your application first before do code. No matter how skillful programmer you are, the risk of not having the application designed beforehand is high. It can makes your effort go waste, and you got nothing from it, except wondering why this is happening. If you cannot do the design, as someone who is good at it. Asking experts in each field, for example accountant during finance application design or a headmaster during education application design. It can give you clear vision about what kind of application you want to develop, and the functionality.
