To fix or not to fix?

Re-Write or Correct…

The age old question when you are asked to take over developing an existing solution for a client who was un-happy with the state of the solution.

The big question for a new developer: Is the database badly written or just incomplete?

Both of which are subjective viewpoints based on your own level of development expertise and coding standards.

If it’s poorly written then the next big question is how much time and effort should be invested in the existing database, before explaining to the client the cost benefit of re-writing.

There is no easy answer to this as it depends on several important questions:

  • Has the development been completed, but the fine-tuning and bug fixing has not be completed thoroughly?
  • If the solution has not been completed, how much more work is required to complete the database?
  • Does the client have plans for further development, and does the scope of this new work fit into the current design and structure of the existing solution?
  • And how badly has the solution been designed?

As a general rule of thumb, if the solution has been completed then de-bugging and rigorous testing with the clients input would be the sensible option. This would also give you the perfect opportunity to show the client that their future database requirements can /cannot be incorporated within the solution going forward.

If the solution is far from complete, then the more difficult opinion to voice is the option to re-write the database from scratch. There are a number of barriers to convincing a new client to take that option, primarily the cost, although this can be negated in a simple cost benefit analysis based on the de-construction and repair of the existing system and the cost to re-write.

But the more difficult barrier is the fact that you are basically asking your client to write off the investment made to date in the database, and that carries with it many implications.

Regardless of the state of a solution the only option as a new developer approaching an existing system is to be upfront and give a genuine honest assessment of the solution based on your knowledge and experience of working with databases.

A client will always make their own decisions, but to make effective choices the information must be supplied in detail and allow your client to make the best decision for them, after all forewarned is forearmed.

Simon Ward

Simon has been developing FileMaker databases since the late 90s and joined Linear Blue in 2006. Over this time he has developed database systems for clients in many different industries from Order Processing to Book Publishing. Simon’s BSc in Chemistry from Thames Valley University comes to the fore in his analytical skills and he is certified in FileMaker versions 7 through 12.

More Posts - Website

Leave a Reply