December 12th, 2017
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
(Tonight I’m dumping some of my notes, from my riffs.txt, onto my blog. Not sure why I kept these for years without publishing. I was probably waiting for a moment when I could write a longer essay about them.)
Why I hate books about Design Patterns
Imagine two girls, both nine years old, decide to play tea. They put on nice dresses and bonnets. The one goes over to the other’s house.
“Mrs. 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 girl.
“I am so glad you enjoyed it!” says the other little girl.
They are imitating the manners of their mothers. 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 and become adults. This is fine so long as the play is obviously labeled as play. But it becomes dangerous when 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 is, ultimately, a form of goofing off.
I once worked at a small startup (they had 20 people) where the CTO and his buddies were working on some code which would, they claimed, reinvent data aggregation for the medical industry. When I first spoke with them, I was dazzled by their intellect. They struck me as very serious, and willing to think deeply about the problems humans face when using software. I recall our first conversation lasted 6 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. They were in their 20s and early 30s and had been programming long enough to fail once or twice, and to start over with new insights.
Once I started to work with them, my impression of them changed. 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 the software, which would be a complete re-write, but they decided to continue to keep JSON strings in PostgreSQL. The schema would change completely, but the basic idea would remain the same.
They had spent much of a year building a system in Python that allowed them to serialize Python objects to a JSON representation. They were, in fact, writing their own document database, using PostgreSQL and SqlAlchemy to do all the boring stuff that they didn’t want to deal with, so they could focus on the fun stuff that interested them, in particular, how to represent data-types. I was often engaged in conversations that would last for many hours in which we would discuss interesting theoretical issues such as the best use for Algebraic Data Types, the use of Union and Disunion to validate types, and how to deal with a hierarchy of nested data types. We would talk about Design Patterns, and the relationship of a schema to an architecture, and the natural relationships of certain architectures to certain Design Patterns.
They were, in fact, playing. The game would not be obvious to anyone other than a programmer. They were having fun working on software that allowed them to talk about abstract theoretical topics. The software had nothing to do with the mission of their startup. And yet, they had brilliant conversations on every kind of topic that might be interesting to people who study computer science. This was a sophisticated game, and they were able to invent serious-sounding justifications for what was, in the end, as unserious as the 2 girls playing at tea. I have never worked at a company where I spent so much time discussing the nuances of computer science, while spending so little time doing any actual work.
I remember the place for its brilliant conversations and for its lack of productivity. And this is why I hate all books about Design Patterns. Such conversations can be an invitation to goof off and play. And yet, every type of engineering has its Best Practices which should be studied, and computer programming is the same. And therefore, despite my doubts, I am writing a book about Design Patterns.
Mind you, I would love an invitation to play. And brilliant things can happen when smart people are allowed to play. But these things need to be supported by a generous sponsor. At times, the government can be a generous sponsor. In the mid 20th century, the government of the USA played the role of generous sponsor.
An invitation to play is an important thing. Sometimes it is even historic. But it feels very wrong to play while at a startup that is burning through its investor’s money. There was some mismatch between the urgency of the situation and the way the staff at that startup played.Source