As an independent custom application software developer I have determined that any really active application (…defined as an application basically designed and developed on an on-going basis, changed and updated frequently as business needs develop) periodically requires that the developer step back and once again look at the application as it exists, the new requirements – and the methods required to maintain and implement the new requirements. Often I have found that rather than update the application it is often just easier (…read will take less time) to basically start from scratch on many parts of the application.
Now, I’m not suggesting that one throw everything away — but what I am saying is that often early development of the application design limit the ease with which new functionality can be added or processed. This is caused by the simple fact of not knowing ahead of time the additional requirements which may come up. While it is possible in some cases to “suspect” that some future requirement may arise and therefore plan design to accomodate the future need, often it just isn’t apparent.
It is difficult to determine just when to look at re-design and re-structure of an application, but I have developed one simple step for establishing when it is re-design time — When “conditional code”, “exceptions” and new table relationships begin to look like spaghetti code of COBOL days — its time for re-design. I’ve recently found such an application at a customer site — re-design is in progress.