There are numerous reasons why a codebase would be in a state where it requires refactoring. Perhaps the schedule for a project was slipping and corners had to be cut in order to ship a product, or what was once considered good, clean code no longer satisfies the new requirements. Or the developer was just hung over from a long night of drinking and playing World of Warcraft and just wrote sloppy code the next day. Also, No two developers are the same, and even the same developer last year is not the same as he is now. I myself have looked over old code, said “Who the hell wrote this crap?” only to find out later that it was actually me.

Whatever the case, there are numerous benefits to refactoring. It allows the developers to solidify the code base, clean up inconsistencies, and improve the overall quality of the product without affecting the user output. When done correctly, the end result is a code base that can save time, energy, and debugging headaches in the future. It should be able to support the addition of new features quickly and easily (improved extensibility and scalability), and reduce the amount of maintenance work required.

Another analogy you can use for refactoring (or software development in general) is Gardening. Over time, despite how well you grow your plants and arrange them into neat patterns, you eventually grow weeds. If you don’t stop and pull out these weeds, they will eventually spread and overwhelm your entire garden. The same holds true with any software development project that needs to be refactored.

Refactoring should not be relied on for proper coding methodology, but rather as a “TODO” item for the long term. What is often seen is that a developer will race through the code without having developed proper planning for objects and sequence/state diagrams (I am completely guilty of this, as are many people who say they aren’t), which ends up with poor/obsolete code right at first release (Beta as this article indicates), with the thought that “Oh. It’ll be fixed up in the refactoring cycle”.

What should happen is that the developer should develop and implement some of the primary habits (”Best Practices”) of designing their objects first, figuring out what has what, what state delegates which method and so on. Once this has been worked out, then start coding with the idea that “This is it!”, and write the most elegant and effecient code they can for the objects/processes. If these criteria are met first, then the developer can be justified down the road in saying that “Hey. I’ve found a better way to do this, let’s refactor it.”, and then place it in the refactoring cycle.

To have a cycle in which all it is is refactoring of old code, simply means that it wasn’t really done properly the first time, and certainly shouldn’t have gone out the way it was. This may seem like timelines won’t be met, but in my experience, proper planning, research and habits up front will make the actual implementation go that much faster, produce better results, and reduce the need for refactoring.

…of course, I may also be just talking out of my a@#….