Design Patterns Live in Solutions

This week, I've been talking about where Design Patterns live and where they don't.

I have a suggested model and I didn't come up with it alone. It was an accumulation of knowledge from old work and a collaboration with Eran Pe'er of DevCraft.

First, I'm going to lay out some information.

Think about all the ways a Design Pattern can impact your life as a developer...

A Design Pattern can be a starting point for existing code, the goal design for new code, the destination for a sequence of refactoring moves, or any combination thereof. It can be an area of study for someone attempting to advance their skills, a collection point for knowledge about how to address certain kinds of problems, and a phrase in a high-bandwidth conversation between developers.

There are more advantages but these six are really, really important.

All of those things are either directly or indirectly about solving problems. It stands to reason that design Patterns are tools we use in solving problems. They are far from the only part of solving a problem, they represent a critical aspect nevertheless.

To me, that's where Design Patterns live: in the act of solving a problem or helping someone else do the same.

I like positioning Patterns as solution elements. It connects them to problems the way they should be connected to problems. It connects them to implementations the way they should be connected to implementations. It gives us a language to describe, refine and expand them appropriately.

Is it perfect for everyone, always? Probably not.

Is it good enough for me, now? You bet it is.

Design Patterns Are Indicated by Problems

If patterns don't live in code, drawings, or any implementation artifacts, then where must they live.

Some have suggested that they live in problems. There is substantial evidence to support this claim.

I'm not sure if I'm totally on board with the idea that a design pattern lives in a problem but I will definitely agree that the problem you are addressing is one of the primary factors influencing which pattern applies.

In other words: problems indicate patterns.

Design Patterns Don't Live in the Code

In my previous post, I wrote that design patterns don't live in the drawings. You can't just replicate a picture someone drew a bunch of times and get a good design.

A natural next conclusion is that they must live in the code. This is also not the case.

Design Patterns Aren't the Drawings

An easy, and very forgivable mistake is to think that the drawings in the original book, Design Patterns, are the essence of the patterns.

One reason someone might make the mistake is that the drawings proliferate like dandelions.

Fundamental Tenets of Design Patterns Thinking

There are four basic principles of deep design thinking. These are all paraphrased to make them easier to digest in 2018.

• Start with contracts and drive implementations to serve needs.
• Encapsulate variation so you need only attend to it in the fewest places possible.
• Couple to the highest abstractions possible.
• Delegate between objects rather than inheriting between classes.

These principles underlie all the design patterns wherever they apply.

One could write a book on these four principles. In fact, a lot of people have.

I'm going to dig into each of these more deeply in subsequent posts.

Code Quality Deficiencies Demand Root Cause Analysis

Looking for code quality problems and then fixing them is really just another form of trying to test quality into a product at the end of the development process.

This simply doesn't work. Problems have root causes and. So long, as those causes are allowed to persist, new problems will continue to arise.

Hard Work Doesn't Always Pay Off in the End

I had a coworker who used to always say that lazy people were the best programmers. Her reason was that we don't like to do anything twice.

I think she was right that good programmers often look lazy. I'm not sure that the reason is what she thought it was.

When we bump up against a hard problem, most people have one of two impulses: Give up or try harder. Both of these approaches are unlikely to succeed - although they do both succeed more often than I would have guessed. Often, when you run into something really difficult, the best expenditure of time is the one that makes it a little easier.

Don't Try to Balance Code Qualities

There is a popular idea that you strive for balance between code qualities.

This seems misguided, to me. Balance requires opposition yet none of the code qualities opposes any of the others.

A Personal Example of Changing Mindset by Creating a Habit

A few years back, I wanted to start eating steel-cut oatmeal for breakfast. I had high cholesterol. I believed this lifestyle-change would impact it in a beneficial way. If I was right (I was) it would obviate the need for statins.

After languishing in excuses for a while, I decided it was a matter of discipline. I was going to do it. I would eat oatmeal every day for a week.

A Trick for Retraining Yourself

Previously, I suggested that one way to change your mind is to start with a discipline, evolve it into an habit, and let the habit reprogram your thinking.

Getting through the discipline phase can sometimes be challenging. In my experience, old habits try to reassert themselves a lot in this phase and sometimes they succeed.

When this happens, one trick that I used was to always undo whatever I did and redo it using the discipline I'm adopting.

Adopting the TDD Mindset by Altering Habits

Previously, I wrote that test-driven development is a mindset, more than it is a skill. It's easy to learn but it's difficult to adopt because you have to change how you see and think about software development.

One way to modify your worldview is to form an habit and allow that habit to gradually transform your perspective. That's exactly how I made my transition to being a test-driven developer.

Test-Driven Development as a Mindset

For what I consider to be a long time, I've been trying to help people adopt test-driven development. It always seems more challenging than it should be.

I think I might finally have identified the fundamental impediment: I'm trying to teach people something that cannot be taught, because it is not really a skill.