How do you deal with design changes?

Question

I just finished working on a project for the last couple of months. It's online and ready to go. The client is now back with what is more or less a complete rewrite of most parts of the application. A new contract has been drafted and payment made for the additional work involved.

I'm wondering what would be the best way to start reworking this whole thing. What are the first few things you would do? How would you rework the design in a way that you stay confident that the stuff you're changing does not break other stuff?

In short, how would you tackle drastic application design changes efficiently (both DB and code)?

Answer 1

If it's THAT drastic of a change it might be best to just start over. I've worked on a number of projects that have gone through some drastic changes.

Starting over gives you a chance to use experience learned since the last project and provide a more efficent product.

I would recommend against trying to re-work the old site into the new site, you'll probably spend more time fiddling around changing things than you would have if you had just re-written it.

Best of luck to you !

Answer 2

How would you rework the design in a way that you stay confident that the stuff you're changing does not break other stuff? In short, how would you tackle drastic application design changes efficiently (both DB and code)?

Tests, code complexity/coverage metrics, and a continuous integration system. Run them early and often, so you know which parts are the riskiest and where to start writing.

These will become your safety nets when you have to make potentially problematic changes. If something does break, your CI system will tell you, and you won't have spent weeks down some rabbit hole before you realize there's a problem.

Answer 3

Presuming that you have unit tests in place, this is just refactoring.

If you don't have unit tests in place, then

1. Write unit tests for the parts you're likely to keep.

2. Write unit tests for the parts you're going to change.

3. Run the tests. The "keep" should pass. The "change" should fail.

4. Start refactoring until the tests pass.

Answer 4

This is NOT-A-NEW thing in software and people have done this and written a lot about this.

Try reading

• Working Effectively with Legacy Code
• Refactoring Databases: Evolutionary Database Design

The techniques explained here are invaluable to sustain any kind of long running IT projects.

Answer 5

Sometimes you do things better the second time around so just try and stay positive. Plus you will have more domain knowledge this time around.

Answer 6

Database design is different from application design in this regard.

Very often, client rethinking changes the application completely, but changes little, if anything, in the fundamental underlying data model of the enterprise. The reason for this is that clients tend to think in terms of business processes, but not in terms of fundamental data. Business processing and data processing are tightly coupled. Data storage is less tightly coupled.

In the days of classical database design, designers learned how to exploit this pattern, by dividing their database design into (at least) two layers: logical design and physical design. There are any number of times that a change of business process requires a complete rewrite of the application, and a major rework of the database physical design, but requires few, if any, changes to the logical design.

If your database design didn't separate out the layers like this, it's hard to tell what gets affected and what doesn't. Start with your tables and columns. Ask yourself if any of the changes require removing any column from the table it's in, or require inventing new columns. If the answer is no, you're in luck. Next, look at the constraints placed on the database (things like PRIMARY KEY, FOREIGN KEY, UNIQUE and NOT NULL). These constraints might be tightened or loosened by the client's changes. If not, you're in luck. If you didn't declare any constraints in the database, and chose to do all your integrity protection in application code, you're probably out of luck.

You still have a fair amount of work to do in terms of changing the indexes on the tables, and the way the application works with the data. But you've salvaged part of the investment in the old system.

The application itself is much more vulnerable to client changes in process than the database. If your database design was completely driven by your application design, you may be out of luck.