Magical Thinking, Tee, and Tea

(note: this is a continuation of a story that starts here)

But Will it Work Here?

It happens with alarming regularity. Everywhere I go; almost every team I meet; with the majority of the people whom I have mentored, there is always this question: "Yeah...but will it work here?"

The implication is that this place is special. This place has a different set of circumstances which exempt it from needing to learn TDD, design patterns or refactoring.

Yet these techniques are established. They are proven beyond any reasonable doubt and on a broad scale. There might be something better coming in the future but it's not a resurgence of the old ways.

Those three disciplines work, largely, because they aren't sensitive to where they work. There's nothing special about any environment.

Your circumstances aren't special.

Test-driven development, design patterns, and refactoring are what software development is. If they don't work in your environment, it's because software development doesn't work in your environment.

Design Patterns and Code Qualities

A friend of mine recently intimated that we don't need design patterns because all the principles and patterns can be derived from code qualities.

It's true. Patterns can be derived from the principles of code qualities...the same way aerodynamics can be derived from quantum mechanics.

Design Patterns Questions

Like code qualities, I'm going to start sharing questions you can ask yourself to help sort through which design pattern applies where.

As I add questions to the set, I expect it to grow into a checklist someone can use to evaluate whether the pattern they are considering is the right one for their situation.

I'm not expecting to create a perfect result every time. I'm happy with better results some of the time.

There will be two categories of question: general and specific.

General questions apply to every pattern. For instance "What variation does this let me add without changing any existing code?" applies regardless of what pattern you are considering.

Specific questions apply to one pattern or a small group of patterns. For instance "Do I need to decouple when something happens from when the decision is made that it should happen?" applies primarily to the Command pattern.

The label for this post will also be on all such questions.

When All You Have Is an Hammer...

A lot of the time, when I come into an organization and look through their code, it's really easy to tell when one of the more gung-ho developers just learned their first design pattern.

Suddenly, there's an area of the code-base where everything looks like the Visitor pattern diagram or the Observer pattern drawing.

It's easy to fall into this kind of trap. Not everyone does but I haven't done the science to figure out what, if any, extrinsic factors affect whether or not this happens. I doubt anyone has.

I didn't have it happen and it's really easy to trace why. I had already "invented" the design patterns long before I was exposed to the book. Before the book was even written, really. My difficulty with patterns was "Why should I use these?" not "How can I make these useful?" I'm sure plenty of developers my age had that same experience.

I know a couple of people who were introduced to design patterns on my watch and who didn't seem to go through the "everything is this pattern I just learned" phase. Yet, I know a whole lot of people who went through that phase, regardless of who introduced them to patterns.

It's probably okay.

It's more important to find your way out of it than it is to avoid getting into it.

There is one defense I can imagine. I have no proof it will work but it probably can't hurt. Whenever you realize you are trying to bend a problem to fit a pattern, remind yourself that you should be finding the pattern that fits the problem, instead.

Cultural Momentum

I have a friend who is going through The Fountainhead. That's as of the time of this writing. He reads fast, so it probably won't be true when this post is published.

Without debating the merits of this book, there's a particular part that he was discussing with me, recently, which I think is relevant to everything.

Near the beginning, the main character (Howard Roark) is chastised by the dean of his college for not doing what has always been done. This is done in a very ham-fisted way where the dean basically explicitly states that we have to keep doing what our ancestors did.

My friend's objection to it was the fact that the conversation seemed hyperbolic (my words, not his), not to the point being made. Yet, the problem is actually a very common one.

Though it's typically presented more subtly, culture does exhibit inertial properties. This is as true for corporate cultures as it is for national ones.

What does that mean for us?

It means we have to slow down. A lot.

It's easy to know where we want a culture to go. It's possible to personally adopt skills, disciplines, or even a new mindset pretty quickly.

What's hard is to alter the culture of a large body of people faster than that population will accept.

If you chisel away at a culture, you can make a cumulative difference. If you try to be an iconoclast, you're more likely to be ousted or ignored than you are to make a real impact.

An Acting Troupe Behaving Like a Software Development Organization