When to think about refactoring your code

Introduction and Classic Use Case

You're working on a codebase of reasonable size and you find you have to add a feature to the program. As an experienced developer, you're also sure that you will continue to need to make changes on a consistent basis. The change is difficult to make, however, because the program is not structured in a way that is convenient to add a feature.

Explanation

When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

The program might not be broken, but it does hurt. I've found this to be an excellent early warning sign that your code is in need of refactoring. Remembering this rule of thumb as you go through your workflow will be immensely helpful in keeping your code clean, easy for everyone on your team to understand and malleable to the only guarantee in software engineering, that code will change.

Sources

Those readers wishing to check a bit more about this tip should reference:

Refactoring: Improving the Design of Existing Code by Martin Fowler