Over engineering a computer program or script can be a frustrating experience.   At the beginning, there are ideas of how something is going to work.  The problem is you cannot predict exactly how it will be used in the future. At the other end, it can be frustrating when the solution chosen was overengineered and a portion or all of it cannot be used. A new solution has to be thought up and all the extra effort made in the initial version for the future has to be thrown away.

For a new company with limited time and a lot to get done, it may be best to get a working product out and enhance it as needed later on. This often turns out to be faster than the over engineered method.

The “learn as you go” method adds incremental additions and changes which are easier to stomach if they are scrapped or removed from the product. This approach may seem like an inconvenience and unneccessary when you are devoted to getting something solid and that won’t require a whole rewrite in the future. Keep in mind it’s also inconvenient having to reinvent the wheel for a whole product because it doesn’t fit a new vision.

Reinventing the wheel is also a painful process. Having to rewrite a substantial amount of code to get the product to perform like the old version did but in a new fashion should be avoided if at all possible.

If you must rewrite the system, make sure that the changes are absolutely neccessary and not just a time waster in hopes of improving the core of the system. Critique the new concepts that will take more time and effort to implement and see if the value outweighs the time and effort required.

The best advice is K.I.S.S., keep it simple stupid. Complexity of a project adds to the training time for new staff, can create hard to track bugs, and a system that is difficult to maintain and enhance (which hopefully doesn’t mean completely rewriting the system).