The need of doing things right

There are several steps to follow in order to do re-engineering. I've read different books that teach us how to work with legacy code and how to refactor it, but theory is nothing more than an ideal world. Those that work in a company will understand what I'm talking about. However, in the case of re-engineering there are some basic steps that we should follow to achieve success that are so obvious that we don't pay attention to them and we fail.

For example, in order to refactor a legacy code, we have:

1) Define your goals!. 

It is silly, right?, if we don't have goals to focus on, how are we going to define a design?. Well, think about the times you've done a refactor and asked your architecture lead to put in black and white all the goals and objectives you needed to achieve. Where you objectives the same as your manager, architecture lead or client?

2) Having an initial understanding.

If you need to modify code, you'd better understand it!, again, it's obvious, but some common thing among developers is that after understanding what we need to do we start thinking about the design. We say, "ok, this code is a piece of crap and we need to do it all over again!", we are focused on one problem only and we start what we think is the best design ever. Please ask yourself how many times, you asked your colleges about the code you are about to modify, how many times you asked a technical analyst about all the functionalities that you need to cover. 

3) A detailed model 

Not talking about your design yet. Before doing a big refactor, we need to understand the complete functionality of the code you are about to modify, and that means doing a detail model of it. Why this is important?, it is important because it may or not be broken!, we may think that the code is old and useless but after you understand it and analyse it, you might find that despite of the fact you wouldn't do that way, the design is not actually wrong, and doesn't need to be fixed.

4) Your design.

Now that you are sure about what are your goals and that you need to modify the code, go to the fun part. Do your design. Again, ask everyone to review it!, you are not as important as you think you are!, and worst, YOU ARE NOT THE  GREATEST DEVELOPER IN THE WORLD!. Once you are sure that your design fit, COMMUNICATE IT AGAIN!, ask your architecture to review it, make sure everyone understood and agreed on it. Do a prototype of your idea, it will help a lot!

5) Modifying the code.

Now it's time of the real fun, but first you have to answer yourself, have I detailed all the steps to do the refactor?, developers don't like to write documents but they are very useful, we need to communicate our ideas a bit more. After you have your plan in black and white, DO YOUR UNIT TESTS!, again, YOU ARE NOT THE GREATEST DEVELOPER IN THE WORLD!. After your tests are complete, be incremental (despite of the hard work)

6) Communicate the changes

You've worked a lot, but the rest of the teams don't know about it. Communicate your effort and how the things must be done in the future. Explain your design or it will die.

Again, these are silly and very obvious steps, but we don't follow them every time. We need to focus a bit more and leave the time pressure away :-)

Cheers!