![]() |
![]() |
Back to Papers and Articles |
Guidelines for a Successful Application Copyright 2002 Paragon Corporation ( October 15, 2002) |
|
Accept failures as part of the development processThe road to success is fraught with failure. Many application development efforts fail because individuals involved are afraid of failure. They spend months planning how to setup the pieces so that it will scale well, it can be easily extended or bug free, easy to understand for the user, satisfy all a users needs etc. The problem with this approach is that nothing gets done. Every one wants to set things up the right way the first time so they don't have to redo things. In doing so, they never get to the point of setting up anything that will provide a visual working context to progress from.The main key that people often miss in all the confusion is that application development is an evolutionary process not a revolutionary process. Things rarely work perfectly the first time, but it is from these first time efforts that you have a working model to learn from and to sculpt. Redo what doesn't work and don't look back.
Never plan to build the most robust long lasting thought out application or to do things the "Right" way Start programming as quickly as possible. People tend to wait till they've fleshed out all the details before beginning to program. This might be fine for one shot deals such as operations or building a house etc., but tend to not be the best approach to take when architecting an application for a number of reasons.
With that in mind - it is good to balance out your programmers if you can. Some programmers are good at producing output quickly, or generating mockups which may not be most efficient or the best coded while other programmers write really tight code that is fast efficient and easy to understand, but seems to take forever for them to write it. Programmers that are fast at outputing code should be put on the task of developing the prototype. The term I like for that is stalling for time (until you've got the real stuff). This keeps your low attention span coworkers content while providing a visual context for your other staff to work with. If your target deployment is greater than 5 months, develop your application with future tools in mind. If your target deployment is greater than 6 months, develop with future tools (beta versions of tools that will be used).With the rate of change in the computer information industry tools of yesterday become passe within a year to 2 years. For a large application, the last thing you want is to spend a lot of effort designing and programming with tools/languages that are already obsolete or incompatible with newer tools by the time you are ready for deployment. Your friends will laugh at you. The IT server department will despise you because it doesn't work on their new-fanged server they have. The programming staff will resent you for keeping them in the dark ages because programmers hate programming in obsolete things and like to experiment with new things - if nothing else but for job security.
Even though the tools of tomorrow are not out there now when you are developing, it is important to keep abreast of them with magazine articles etc. to minimize as much as possible on developing apps that will be incompatible in the next release or so.
| |
Back to Papers and Articles | |
|