Evolving to Patterns

Day three of TechEd 2006 and this morning I attended a session on "Evolving to Patterns" by James Newkirk. What I found most interesting was his use of the "broken windows" paradigm and its application it to software development (others have done so as well). For those not familiar, the idea came from an article written by James Q. Wilson called "Broken Windows" that appeared in the March 1982 issue of Atlantic Monthly. In a nutshell, the idea is that human beings tend not to respect that appear to be in a state of disrepair leading to a vicious cycle of further deterioration. The example used by Wilson is that of an apartment building with one broken window that acts as a signal to vandals to break even more. The same idea can be applied to litter and even the accumulation of junk or dishes in the sink in your own house. The lesson is to fix problems when they are small.

As applied to software development the notion of fixing your broken windows can be distilled into three basic ideas.

Remove Duplication. Duplicated code is broken code because it encourages sloppiness and thought processes where developers don't look for ways to inject abstraction.

Simplify Your Code. Code that is difficult to understand from a structural perspective is broken code because developers would rather write something themselves than have to figure out how to refactor existing code to get the job done.

Clarify your Code's Intent. A corollary to the above is that the intent of the code needs to be clear. Code's whose intent is not clear through the judicious use of comments and naming conventions is broken because it leads to misusing the code or once again the tendency to put that code in a virtual black box that is not to be touched which leads to duplication.

And of course evolving your code to use patterns helps us to design code that is ready to handle the changes that will inevitably come.