views:

67

answers:

2

For reasons it's not worth getting into, the object Model of the django application I am working on is now "wrong" insofar as a number of relations that are 1 to Many are represented as Many to Many. The application functions correctly and is most of the way through QA. It has never been deployed.

My design OCD makes me want to refactor it to correct the problem The only good time to do it is now, before it goes into production, but it's still not that good a time as QA would have to be redone and the project would slip.

Are there any good engineering reasons to do the refactoring? This is a tool which will have a user base numbered in the tens rather than the tens of thousands and the database is unlikely to grow to significant size in the short to medium, probably even the long term. I strongly doubt performance is going to be a factor.

+2  A: 

The only business reason I'd potentially see to justify redoing the QA is maintainability. My questions would be:

  • Is this project one that will be used for a long period of time?
  • Is this project one that is going to be changed and adapted over time?
  • Will there be adequate QA opportunities when changes are necessary later?

If you refactor now, you'll take a short term productivity hit at the potential benefit of long term productivity gains, since the simplicity gained will probably improve maintainability. There is no right answer, though - it really depends on how your project and deployment is setup, and how your software will be used.

Reed Copsey
A: 

Sounds to me like your "reasons not worth getting into" are actually important here. That 1-to-many vs. many-to-many design issue reeks of a client who changed their requirements. This happens so often that I'm going to assume it is what happened here.

You should really just decide on what would be the cheapest route in the long run, and make sure the client who changed their requirements will pay for the time. Or you could optionally inform whoever is paying for this system about the risk involved in going forward with an incorrectly designed product, and let them decide whether or not to spend the time and money fixing it.

Fragsworth