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?
Unit testing. But if you didn't have unit tests from before, they wont help you.
This question sounds like you are modifying existing code by "cleaning it up" as opposed to rewriting it. This process is sometimes referred to as "Refactoring". There is a great book on refactoring called "Refactoring" by Martin Fowler. He starts by giving concrete examples of refactoring on actual code, and links the future chapters about specific techniques he is using right there next to the code.
One of the very first things he says about refactoring is to write a test to test that the code you are changing does the same thing for some common set of inputs. Then when you "refactor" the code, run the test against it to ensure it is functioning exactly the same. This can be pre-bugfix or post-bugfix. But if there is a bug, of course you have to squash it in addition to refactoring.
Why rewrite from scratch? You may be able to reuse parts of the existing application and refactor those parts that need changing.
When I go about to recreate something that has already been done I try to avoid looking at the already existing implementation. I try to focus on what it’s supposed to accomplish instead of looking at how it’s trying to accomplish that.
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:
http://stackoverflow.com/questions/330220/strategy-for-large-scale-refactoring