Software Design Patterns Are a Human Communication Tool

Intro#

Recently my daily routine changed a bit as I assumed a different role within the organization. Among my new daily interactions is the chance to have technical conversations with one of our main Architects about various design matters of the software. This gave me the chance to reflect on the usefulness of some tools I have not used in a long time: software patterns.

But, what are patterns#

A Software design pattern, as defined in wikipedia is:

a general, reusable solution to a commonly occurring problem in many contexts in software design

That definition is all fine and dandy, but a bit light on the meaning side.

Let’s try with a down to earth example: Baking. Baking is very akin to programming: precise instructions with as much detail as one wishes to convey and one can use pre existing frameworks (like cake mix).

We will use making a Red Velvet cake as an example for no other particular reason than the fact that I like it.

The safest way to transmit this recipe, is assuming the baker in question has at least the basic knowledge of kitchenware and ingredients but not more. And so a safe version of the recipe that is accessible by all would look like this:

With ingredients as pre-conditions (the “mise en place”) and a list of steps to achieve the cake.

This approach will reach a majority of the public but will come at a cost.

The time to transfer this information is long, a lot of details are sent with very little density.

The executor of the recipe might need to recheck it often as the multitude of steps might lead to mistakes. Finally there is room for deviation as different readers, due to a lack of a standardized frame of reference, might interpret some steps differently.

Now, if this recipe was in the kitchen of a professional shop, where every baker is assured to have undergone a set of trainings and courses common to all, it would just look like this:

Because every baker knows how to make a sponge, the only variation on the standard is the dye and all bakers will also know when to add it.

Same goes with the filling, they will know the consistency it must have, how to apply it and all the subtleties.

Transferring this information is faster and leads to more consistent results that can also be inspected by others and even work can be changing hands midway through.

There are downsides to this of course, to list them, let me go back to software engineering.

Unlike bakery, software engineering is much less homogeneous. Professionals come from a variety of backgrounds with more or less formal training and even those with equal amounts of training might come from different branches. We sadly cannot have French and Italian meringue versions of algorithms. Knowledge patterns will be present in only some of the educational paths in formal education.

Not for all#

We could talk about design patterns as idealistic objectives of software development (there is always a level of compromise when theory encounters reality). Besides clear communication, they are a gateway for some order. However, not everyone in our industry is looking for order, some profiles are oriented at producing structured results others to a more adventurous and creative path. Both profiles are suitable for engineering organizations and, depending on the profile the organization itself has, more of one or the other might be convenient. For those who seek the thrill of discovery through doing ahead of planning or simply plan but based on finding through experience, these practices might be more a burden than a help. To some it might even feel like cumbersome bureaucracy, at least in the creation phase. Order has its place, for example when facing more chaotic or urgent outside environments, a level of control is ideal to maintain functionality. A more organic and unstructured approach is better when discovering the direction of a product or limitations of technologies.

Conclusion#

I would argue that it is a worthwhile investment to help your engineering team become acquainted with design patterns as a company policy. It is however a delicate subject and you need to ensure this will not have a demoralizing effect that will cause them to leave. Perhaps a good compromise is a mix of having the material available and doing awareness communication without pushing for adoption. The time invested will return as better communication , more consistent product development and ease of induction for new talent. Like my architect and I, we have gotten up to speed on thousands of lines of code in a couple of simple sentences and are now collaborating as if we had been on the same page for years, maybe we were, just each of us had a copy of the same book.