The Importance of Software Design Patterns

Posted: September 25, 2015 in Design Patterns, Patterns and Practices


Author: Cole Francis, Architect

Many of our mentors who leave us with beautiful masterpieces to gaze upon also tend to leave behind prescriptive guidance for us to glean from. But, how we decide to implement their imparted knowledge is always left up to us. What I’ve found is that a fair number of people choose to ignore their contributions altogether or find themselves rushing to judgment when it comes to applying their prescriptive guidance, often proposing the wrong tenants to solve a problem. Both of these approaches often yield poor results…occasionally even catastrophic ones.

The realm of software design and development is very similar in this respect. Designing and developing architectures using proven design patterns, prescribed by industry mentors, almost always lend themselves to a more cohesive understanding of a project’s composite breakdown across the entire project team when applied properly, which results in a solution that’s both easier to build and maintain. The design patterns attempt to achieve this by eliminating most of the technical guesswork involved, as well as overcoming many of the technical complexities by attempting separate the concerns.

So, it’s a little bit shocking to me each time I come across a technical article, or even speak with someone face-to-face, that talks about software design patterns like they’re the plague. Their excuses for not using them vary widely, but some of the more common responses include feeling like they’re boxed in when incorporating them into their designs, or feeling like their projects get into this state of over-design and design paralysis when they’re used, or even experiencing unwanted project bloat due to the added layers of unnecessary abstraction. The bottom line is that these people intentionally dismiss the benefits of the design patterns for…[Insert An Excuse Here].

While some of their concerns are warranted, I maintain that software design patterns are ultimately meant to ease the complexity of the Design and Build Phases, not to increase it. What’s more, if a certain design pattern doesn’t actually provide you with more flexibility and predictability, or if you’re really struggling to make that pattern work for you but it doesn’t quite fit, then my advice to you is that you’re probably doing something wrong. Either you’re trying to apply the wrong pattern to the situation or you don’t fully understand what it is that you’re trying to accomplish.

In addition to this, there’s a huge difference between laying down the initial architecture versus having to maintain that architecture or having to operate inside the architectural structure during the project’s immediate lifecycle and beyond. So, if you aren’t using software design patterns to your advantage, then you’re probably inflicting some degree of punishment not only on your current project team, but also on the individuals who will eventually be responsible for supporting and maintaining your final product.


Sure we always joke around about how the final product is someone else’s problem (usually the ASM Team’s), but it’s only a joke because there’s a certain degree of truth to this, and we’ve all been on the receiving end of a poorly designed product at some point in our careers. Trust me when I say that it’s about as much fun and productive as trying to stick your elbow in your eye.


I have this theory that if Architects were forced to support their own finished products, particularly longer-term, then they would incorporate patterns into their designs a lot more often than they ordinarily do. It’s been proven many times over that employing design patterns make a solution more predictable, flexible, and in most cases more scalable. These are all very important factors to consider when it comes to a project’s “buildability”, extensibility, maintainability, and even the sporadic refactoring.

Additionally, software development is often considered to be a highly subjective exercise; therefore, taking a little extra time up-front to pair the correct software patterns with right contextual areas of the design will often result in an architecture that’s uniformly framed for your developers, which means that it becomes much more difficult for them to get things wrong during development.


I need to point out that this shouldn’t be construed as “boxing people in” or “adding unnecessary bloat to your project”, but instead it should be thought of as incorporating a malleable structure that ubiquitously understood across your entire development team. I would argue that this pervasive level of understanding should make your project much easier to build and maintain over time. It’s really cool and productive when everyone speaks the same language and understands where each unit of functionality lives without having to say it over and over again.


Also, keep in mind that design patterns are language agnostic for the most part, so including them early in your Technical Design process shouldn’t necessarily influence the programming language(s) you eventually decide to use during your Build Phase. The benefit is that conversations can be more oriented around the solution’s functionality and less oriented around the specific tools that will eventually be used to accomplish the more detailed technical tasks involved.

Finally…who knows? After many years of practice and hard work, perhaps you will be so inclined as to contribute something back to your own community that’s one day revered as a masterpiece by others…

Thanks for reading and keep on coding! 🙂

Your Feedback is Welcome

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s