Cannot Clean Code

Anti-pattern:

You can't clean the code as you go.

Context:

Your development environment makes it hard to clean code as you go. For example, large code reviews become frustrating due to numerous little changes. Source control process fragility increases linearly (or worse) with the number of changes.

Anti-Solution:

Prohibit the 'clean as you go' approach to programming by forcing developers to change only what is absolutely necessary. Abandon the 'BoyScoutRule' and the 'RefactorMercilessly' tenets. Adopt a culture that prides itself in understanding and working with an ever-expanding mess of complexity.

Real solution:

When your development environment makes it overly hard to write the cleanest possible code, replace or improve parts of it so that all existing obstructions to routinely cleaning code are minimized. Code reviews can be replaced by PairProgramming. Inadequate source control software / processes can be replaced with better software / processes. Bias against clean coding can be reformed by augmenting staff with more conscientious developers.

Meta-pattern:

If something is causing a problem in development, address that problem directly instead of compromising the rest of the development process to work around it.

-- BryanEdds

A real-world example of a force against refactoring is environments where branching and merging is done: In some places three versions of the code are simultaneously maintained -- (1) production, (2) stabilization/testing for the next release, and (3) development head. Any change in #1 or #2 needs to be merged into the other code lines, and refactoring makes this difficult and costly.

Certainly, lack of refactoring makes everything more difficult and costly. But increasing merge costs is a very immediate and visible cost easily blamed on a single agile developer, while the costs of not refactoring are more diffuse and easy to blame on "other people."

The best long term fix is to improve testing (TDD) and refactoring so that you don't have so many production bugs to fix. -- JeffGrigg

Are you meaning that TDD would eliminate the need for multiple versions of the code base, thus lowering the cost of refactoring in that environment? If that's not what you mean, could you elaborate otherwise?

Nope. I'm meaning that TDD would improve the reliability of the delivered code so that dramatically fewer bug fixes would be needed in the other branches.

So, while the cost of merging changes would be higher, due to the higher rates of refactoring, the number of changes would be dramatically lower. So the net cost would be lower. -- JeffGrigg

As another suggestion toward improving version control tools to make refactoring less costly, it would seem better to use 'semantic' diffs and merges rather than the textual sort we are used to. Such a tool would seem to be easily implementable for an easy-to-parse language such as a Lisp or Ruby or C. -- BryanEdds

Recording refactorings, as they are done, has been suggested. But this could be complex and hence possibly prone to failure. -- JeffGrigg

That does seem fragile. I would instead suggest discovering refactorings at the time of diff using some simple AI that reasons about the code's semantic trees. This could reason across different code files and modules, being much more powerful than today's textual diff. -- BryanEdds

Could be interesting. Tell ya' what: You build it. I'll break it. >;-> -- JeffGrigg

CategoryDevelopmentAntiPattern

JanuaryEleven