Time to put an end to Sneak-factoring

If refactoring is defined as...

"...any change to a computer program's code that improves its readability or simplifies its structure without changing its results."

Then sneak-factoring is...

"...refactoring that occurs without full commitment and/or knowledge of the coding team."

If you commit to enhancing a specific section of code—perhaps adding some new feature or correcting a defect—your team should assume that some refactoring may occur.

Often when you write code, you're focused on solving a particular problem, so some coding best-practices may be far from your mind. Revisiting the code months or years later, you may find yourself stumbling—or deciphering as you read—your own code and asking yourself...

"What was I thinking?"

Everyone on the team knows this will happen. It has happened to them, so they expect routine refactoring to occur.

Depending on what code you have committed to enhancing, you may need to refactor your own code, or you may need to refactor someone else's code.

In both cases, there are times when developers are reading code that the team has not committed to change, and they will feel that inevitable, uncontrollable urge to reach out and fix something.

Don't do it!

Transparency is one of your team's keys to success. If you change code without anyone else's knowledge, you break that transparency.

In that oh-so-rare instance when your little "improvement" will break something else, no one will know where to look to correct the problem, and the time lost looking for it will cost your team time and your company money.

If you stumble upon code that could use a washing, just add it to your team's task list, and address it when the team has the time to commit to it. If this is not possible—if you cannot control the urge to refactor—at least notify the team of the changes you've made—or better, the changes you intend to make.

You and your team will be better for it.