Question

My new project is to renew Software that a customer had used for years.
Like we all know…things grew over the years.

So i looked at the old app. get all Infos about it and wrote a lot of user stories down.
After cleaning it up i recognized that i made (in the end) a mistake that leads to the same problem that the customer has now.

It is a different Mistake i made but really annoying.

How do you guys prevent such mistakes. Do you refuse looking at the old app?

Answer 1

This is a really hard problem. I’ll describe what I would do (and have done) if the old code is substantially large.

In general, the old code is full of decisions, bug fixes and undocumented behaviors. If you throw that away, you’re bound to make many of the same mistakes they did and then some more.

For what it’s worth, you should evolve the system around the old code. Try to abstract away from the old code, e.g., by creating interfaces, and then implement them by calling the old code at first. Write lots of unit tests for the interfaces, and gain knowledge about how the old code works. New features should gain new implementations, so old code and new code will live side-by-side, for as long as needed, and maybe even forever.

Now, slowly and carefully make incursions into the old code, refactoring it, replacing it, and making sure that your tests still pass. Write new tests as well. If you have regression tests for the system (apart from the unit tests), they still need to pass.

It’s OK not to touch the old code, typically if it’s working OK, there’re no bugs reported for it, it passes your tests, and it doesn’t need to be extended.

Some good resources:

http://martinfowler.com/bliki/StranglerApplication.html

Working Effectively with Legacy Code

I’ve also found it in StackOverflow already:

Strategy for large scale refactoring