Software Design Patterns...Why Are They Important?

Background.

In 1991, I was just a co-op at IBM in Charlotte, NC.  If you had asked me then about software design patterns, I would have thought you were talking about algorithms or data structures.  At that time I was writing C and providing QA for a large banking image recognition project.  Since then I have been exposed to 6 years of C++, 14 years of Java, 8 years of C#, 15 years of HTML, and 8 years of JavaScript.  My employers have ranged from 4 different multi-billion dollar corporations and 6 different start-up companies.

Around the year 2000, I was working at a start-up where "speed to market" was the name of the game.  However, I learned that if I keep my source code organized and easy to read, then I will be able to change it more quickly when the investors come around to tell us what the new direction for company is going to be (every six months, haha).  I latter learned that I was following a practice known as separation of concerns (SoC).

By 2004, I was working on a large contract for the Department of Defense.  This required a huge amount of interaction with many talented developers from all over the country.  I was force fed the software design pattern of Service-Oriented Architecture (SOA) that brought 19 different DoD organizations together to share their data in order to fight global terrorism.  At the time, there were aspects of it that felt like overkill, but I was happy to be able to follow the concepts and jump right in to help in the coding effort.

In 2007, I was leading my own team at Martin Marietta to design and implement a web-based product that would expose billing information to customers in a highly scalable manner.  Based on my experience of the past, I decided to focus on using design patterns so that each member of the team would have a baseline for understanding my expectations for them.  Therefore, I realized that design patterns would help me create a common dialog for which to build discussions about the problem domain.  Furthermore, by using the patterns in the implementation, it was easier to split up the work among different developers.  The project became very successful and is known as www.erocks.com.  Erocks uses Spring MVC, a repository pattern (Hibernate underneath), and Inversion of Control (IoC).

The Point.

I could go on and on about projects that I have seen using patterns that have been successful.  I could also tell you about a few projects that have been unsuccessful using patterns...but it was always due to a problem with funding or with business aspects outside of the control of development.  Of course, there is the occasional misuse of patterns that cause great confusion and disarray in projects, but I have had only encountered that a few times in my career (thank goodness).

The point is that I am a huge fan of Software Design Patterns.  Not because they sound cool (well, maybe only nerds think they sound cool).  I believe that patterns allow us to get to what matters the most about creating software, understanding the problem domain and doing something about it.

Imagine that you are a gifted developer that always works alone and always remembers the frame of mind that you were in for every line of code you ever created.  You would not need any design patterns in this case.  You could always just say, "Hey, it works doesn't it!"  However, if you are like me and can't always look at a line of code you wrote last year and recall the reason for it immediately, then you probably will benefit by having patterns.

Patterns also help with identifying the overall design strategy when architecting a solution.  Odds are that there is another developer in the world that has already created your design but maybe it was not applied to your business domain.  Why not take advantage of that fact and learn from the problems that have already been solved and resolved by hundreds or even thousands of others.  This is what Patterns are.

Why Are Software Design Patterns Important?

Software Design Patterns are important because they facilitate a baseline of communication among teams using common terms and concepts, they provide a foundation of solutions to be used in solving problems in new domains, and they allow implementations to be assessed in terms of meeting an established expectation or standard.  The bottom line is that these benefits save money for the company and save time for the developer.