Why I hate all articles about design patterns

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

Warning: This article merely describes what I hope to achieve with this series. There is no software code in this article. Those who wish to stay focused on those articles that are focused on code should skip this article. Since I am here describing my personal motivations for writing, this article is necessarily the most self-indulgent of the articles in this series.


This is part 2 of a 12 part series:

1.) Quincy’s Restaurant, a parable about concurrency

2.) Why I hate all articles about design patterns

3.) Clojure has mutable state

4.) Immutability changes everything

5.) Mutable iterators are the work of the Devil

6.) Get rid of all Dependency Injection

7.) Sick politics is the driving force of useless ceremony

8.) Functional programming is not the same as static data-type checking

Interlude

9.) Inheritance has nothing to do with objects

10.) Is there a syntax for immutability?

11.) Immutability enables concurrency

12.) Quincy’s Restaurant, the game


Sometimes play is a lie

Imagine two children, both nine years old, decide to play tea. They rummage around in the closest of their respective parents. They dress up as they’ve seen their parents dress up. The one goes over to the other’s house.

“Mr. Worthington, it is so nice to see you,” says the girl who is acting as host. “Would you like some tea?”

“Why, yes, Mrs. Kentworth, I would be delighted to have some tea.”

The host brings an empty cup of tea to the guest, and the guest pretends to sip at it.

“Why, Mrs. Kentworth, this is such delicious tea!” says the little boy.

“I am so glad you enjoyed it!” says the other little girl.

They talk about their imaginary house and imaginary kitchen.

They are imitating the manners of their parents. This is how children learn. And when children are so young, there is no harm in it. Rather, it is cute and somewhat comical.

For better and for worse, people continue to play when they grow up. This is fine so long as the play is labeled as play. Joyful play is the starting point of creativity. But play becomes dangerous when the people who are playing convince themselves that they are doing real work. And such play can be insidiously difficult to spot if the people in question are hyper-intelligent and able to come up with seemingly reasonable justifications for what they are doing.

Imagine two programmers who spend all day discussing Design Patterns. Their conversation sounds like this:

“Why, Mister Yi! How shall we normalize our data? Is Fifth Form enough, or do we need Sixth Form?” said one.

“Why, Mister Kerr! What a delightful question! I suggest the Strategy Pattern. Let’s make normalization levels a configurable, pluggable behavior!”

They are playing.

I once worked at a small startup where the CTO and his buddies were working on a website that gave nurses a way to track patients medical information. When I first spoke with them, I was dazzled by their intellect. I recall our first conversation lasted 4 hours, during which we covered dozens of important topics: how many unit tests are enough, the trade-offs to be made when invalidating a cache, optimizations of TCP, the right length for Git commit messages, when to rebase, the advantages and disadvantages of polyglot programming, how to resolve inconsistency in a distributed database after a network partition, and so on.

Once I started to work with them, my impression of them changed. We had fantastic conversations but we were getting very little work done. Also, they were doing some unusual things, such as storing JSON strings in a text field in a PostgreSQL database. They had begun work in 2011, but they rejected all of the existing document databases (such as MongoDB or Riak). In 2013 they decided to work on version 2.0 of their software, which would be a complete re-write, but they decided to continue to keep JSON strings in PostgreSQL. They liked some of the Python libraries that they had been working on, and they wanted to continue working on them. They were not even adapting to the fact that PostgreSQL had begun to support JSON natively.

Was the work justified, or were they simply engaged in a hyper-intelligent kind of goofing off? This was for a website that was a fairly straightforward CRUD app. They could have used an existing framework (Django, Rails, Symfony, etc), which would have allowed them to develop much faster, and which already had many of the tools they were building. But using other people’s code to build a CRUD app is not fun.

Fun is important, because we should all have some fun at work, but at the same time, I could argue they were just sort of goofing off on a project that wasn’t really necessary.

I’ve worked for more than one client like this. I sometimes feel some frustration at what seems like too much emphasis on theoretical concerns. In urgent situations, I often suggest we cut a few corners so as to get some important work done. So, I could say that I hate all articles about theoretical subjects such as Design Patterns. Too much theory! But here I am writing a series of articles about theoretical topics such as Immutability and Dependency Injection. Am I the biggest hypocrite that ever lived?

Maybe.

Timing matters. There is a time to focus on the craft of software. And then there is the time to build the features that you’ve promised your customers. I would never argue that craftsmanship is trivial. I write articles like this because I think these issues are important.

More so, what is the real point of discussing theoretical issues? I write these essays because I want to write software in the most simple and direct way that I can, while still achieving the safety and reliability that the software needs. That is, I want to be more productive. I feel that discussing theoretical issues can be justified, especially if the articles give advice that really help developers get work done.

In 2016, some of the dominant paradigms for creating software seem full of unnecessary ceremony. I’d like to argue for a simpler style. In particular, I have found that the Object Oriented paradigm has failed to live up to its promises, while it inflicts a lot of conceptual overhead. Meanwhile, the Functional paradigm allows me to write in a simpler style, while still building resilient apps.

At the same time, I have probably read hundreds of articles about the Functional paradigm, and I have found most of them too abstract. It’s possible that I am both lazy and stupid, but I find it a real struggle to find the nuggest of wisdom in some of what I’ve read. So I hope to take an informal approach here, and speak in a plainer language than some of the worst kind of articles about Functionalism. I won’t be talking much about Monads.

Any genre of writing tends to develop cliches which make that genre ugly. Those familiar with the genre no longer notice how bad things are, but outsiders who encounter those cliches for the first time are starkly aware of how lifeless the writing is. I have known women who read articles about love in various women’s magazines and they find those articles sickeningly artificial and far removed from their own experiences. They denounce the whole genre of romance writing. But some of them then go on to write on the subject of love, drawing upon their real experiences, and writing as honestly as possible about their own experiences. In so doing, they rehabilitate the whole genre. I hope to write about abstract computer science topics, but with the directness of someone who is reflecting honestly about their own experiences. In that sense, you may regard this series of articles as a kind of love story.

Source