Recently (in this great session at TechEd Europe) I learnt about a really useful practice when developing software, called “The Campsite Rule”. I used this practice more or less unknowingly and not aware of the fact that it actually was a development practice. But now, that I have a name for it, I am an even bigger advocate of it.

In its essence, this rules says that you should “always leave a place in at least as good a state as you found it in and preferably in a better one”.

In the world of software development that means, that whenever you are working on a project you should try to refactor or improve it in small pieces. When your are using refactoring tools like Resharper or CodeRush you often are overwhelmed by the sheer amount of warnings regarding all kinds of code, style or architecture violations. Trying to fix them all is most often simply not possible and that is where the “Campsite Rule” comes in handy: just fix some of the issues and constrain your improvements to the files and classes you are working with right now. By doing this for a certain period of time, the warnings get fewer and finally you end up with a clean solution.

Thinking about it, this rule should actually be common sense. But in practice (think about legacy native code projects with countless compiler warnings) it is often just not applied.