A Business Case For Applying Design Patterns

This is my fourth article in a series on the Gang of Four book on Design Patterns. I thought four was an appropriate number of articles. Here are links to the first 3 articles:

1. Design Patterns – A Review
2. OOP Design Patterns in Actor Framework Part 1
3. OOP Design Patterns in Actor Framework Part 2

Intended Audience

The first 3 articles were more technical and targeted towards LabVIEW Developers and Architects. The intended audience for this article is someone who is managing a team of developers. It’s about creating a business case for taking the time to read the GOF and incorporate these patterns into your routine practices.

Benefits of Studying Design Patterns

The following are some of the benefits that can be achieved by incorporating the ideas from the GOF book into your software development practices. I tried to put on my business owner hat and talk in terms that someone (perhaps a manager) who is not familiar with or efficient at LabVIEW programming might understand.

Focus your development effort on domain- specific problems

Most LabVIEW programmers are not software engineers but domain experts. The best use of their time is solving domain-specific problems, not reinventing the wheel of software design patterns. A little time spent studying the GOF will allow your domain experts to spend more time solving the problems only they can solve.

Get everyone on the same page

We all know the power of working in teams. Two people working together can achieve far more than the sum of what either one could by themselves. However, that only works when they are both on the same page. That requires communication. The GOF gives us common terminology to describe and discuss our designs. It makes it much easier to get everyone on the same page.

Spend less time documenting

Developers spend a significant part of their time not just writing code but documenting it. You could write several paragraphs describing your specific implementation of the State Pattern. Or you could simply mention that this particular vi implements the State Pattern from the GOF. As an added bonus, because writing documentation now requires a lot less time and effort, it is more likely to actually get done.

Bring new people on board faster

If we have a common language for describing our code it makes it much easier to bring new people on board. We don’t have to give detailed descriptions of every part of our software. We can describe it at a high level in terms of patterns. If they have questions about the patterns, we can just point them to the GOF book. Then we only have to spend time explaining the domain-specific parts of our code.

Make it easier to reuse code across projects

There is a reason that the Actor Framework makes heavy use of these design patterns. When leveraged correctly they can make your code much more reusable.

Make sharing resources easier

For the same reason that design patterns make it easier to bring new people on board, they also make it easy to move developers around from one project to another.

Add new features faster

Each of the GOF patterns is designed to provide flexibility in a particular direction. When we understand the patterns and use them correctly they can allow us to add new features very quickly by taking advantage of that flexibility.

Avoid Pitfalls and Deadends

The pattern descriptions in the GOF have several sections to help us pick the correct pattern and avoid common pitfalls. The Applicability section describes when a particular pattern is appropriate. The Consequences section makes us well aware of the tradeoffs we are making and points out potential issues. The Related Patterns section indicates related patterns and when it might be appropriate to choose one over another.

How can I learn more?

If you would like to learn more about how to apply design patterns and other software engineering best practices, click here to set up a free one-hour phone call where we can talk about your specific needs.