The right side of software design patterns

When I first started learing about software patterns I thought they were supposed to teach me to write great code. To solve something I had not yet figured out myself.

This has changed over time, and today I was yet again reminded of the communication value when discussing source code. If you both have the same understanding of a pattern you can suddenly express a lot in a short comment, it can even fit todays 140 character outbursts.

The real example of this value came to me some years ago when I was hired for a code review and quality assesment. My customer were on their 3rd rewrite, estimates and cost sky-rocketing. And boy had their contractor made a mess, their estimates suddenly made sense. To prove a point I printed one class, 51 A4 pages! That's a 15 meters long class in 11 point font size. If you ever need to illustrate a code problem to executives, printing a long class works quite fine.

Trying to understand a gargantuan estimate, I could really need some other input. I knew they still had their old system, so I requested a copy. It turned out they did not have the source anymore, but the executables were still available. Enter IL-Spy. Upon opening the dll's I was baffeled, just by skimming the class names I knew what was going on, I could follow their thoughts through the system, I could dig deeper exactly where I needed. Needless to say, the old system was not made by their current contractor.

By understanding and using software patterns and following known principles such as SOLID you establish a foundation of understanding. It will make it easier for yourself and your peers to work with your code. It will no longer appear as a mystery-box of methods but a set of directions and instructions acting as a tour guide through your application.