Transcript

(Editor's note: transcripts don't do talks justice. This transcript is useful for searching and reference, but we recommend watching the video rather than reading the transcript alone! For a reader of typical speed, reading this will take 15% less time than watching the video, but you'll miss out on body language and the speaker's slides!)

Before I get started, I like to put up pictures of books, because I want you to read those books. But I also go through slides at a really rapid clip. So that's rude, because I put up a picture of a book, and you maybe try to write it down, and then I'm already three slides past. So to avoid that, I just want to tell you that this slide will appear between this talk and the next talk, so you'll be able to write things down at your leisure, if you're so inclined.

I also brought some of the books with me, so if you want to look at them today, all you have to do is ask me, assuming I'm carrying this, which I kind of expect I won't be doing tomorrow. So you might want to do it today. OK, so to start to talk actually, I'm going to frame this talk with a talk that someone else gave at a different conference than this. It was a talk about a new version of a web framework that he's the principal author of.

And there's a part of that talk where he begins to talk about design patterns. And the sentence he uses, to begin talking about design patterns-- I'm going to get a little into design patterns here. But no one freak out. So that's a sign that he thinks they might freak out. He's trying to head off a reaction that he's afraid he might get.

Now, what I want to say here is I am not criticizing him in any way, because I think it's probably actually true that, for the audience he was talking to, maybe any software audience, that he had an accurate perception of what they would think when he said the words design patterns. And so he should try to head off that negative reaction. And I'm even willing to say-- and I am sort of sad to say it-- but I think that the impression that these people have, and that I expect many of you people have, toward design patterns is a reasonable reaction to have to design patterns as they ended up, which is different from how they started.

So after that, he says, so we started looking around at prior art. The bounded context pattern resonated, because it's not some grand pattern. It's pretty much just a set of ideas. And then at the end of that talk, he says, it's not that we're adopting a design pattern. So don't go tweeting, now that we've chosen a design pattern. We just took this concept and took inspiration from it.

Now, if it weren't dark in here, those of you who are on the front row could probably see the tear trickling down my cheek. Because I've been involved in design patterns for a long time, on the periphery, not as a central player or anything like that. And this is not the reaction that we hoped for way back when, when they started.

So the reason I'm crying is because the reaction that design patterns, the design patterns people were trying to get, was the same reaction those people had when they read this book, which is called A Pattern Language. It's by an architect, in the building sense, named Christopher Alexander, and his colleagues. And it's a book of 253 patterns, most of them about building houses and structures that people will live in. And their goal is based on the observation that a lot of the houses and structures that people live in make them unhappy, make them feel tense, make them not like their job, et cetera, et cetera. And arranging things in space can make the people who also occupy that space happier people.

So that was the goal of Design Patterns, and it really resonated with a lot of software people. Now, to give you an example of the reaction people had to Design Patterns, about 17, 18, or so years ago, we had a front room in our house that nobody ever went into. Nobody liked it. Back then, we weren't quite as reclusive, hermit, misanthropic people, that my wife and I are now, so we would occasionally have parties. And people would not go in that room.

So one time, I realized, hey, I've been doing this Design Patterns stuff, and I've got this book. Let's see. So I took that book, and I used it to rearrange our front room. And magically, it became popular. Even people who didn't know it was supposed to become popular, would go in there of their own free will, which they hadn't before.

So this was a bit of a revelatory experience, right? How often is it you read a book, you put it into practice, and it actually works?

[LAUGHTER]

So that's what people wanted to replicate in Design Patterns. Now, I have no taste, in any sense of the word, when it comes to visual, or I can't even rotate objects in 3D. So I'm not a very visual person. But this right here is what my wife calls my nest.

Now, for the longest time, I had a home office, your classic home office. I've always worked at home. And it had the ergonomic keyboard, and it had the typing table at the right typing height, instead of up here. And it had a big monitor on an arm, and it had a good chair, and everything. And I always found myself sitting here at this window, after I had arranged it in roughly this format, because it was just so much more pleasant than going upstairs.

So now, the upstairs, so-called home office is full of cages of exotic animals that my children have acquired over the years. And I sit here and type on my laptop. And I'm perfectly happy doing so.

Now, this particular area here is built out of two or more patterns. One pattern is window place, and that's a pattern that's about the need for people to feel-- people like light coming in through windows. They like being able to look out windows, but at the same time, they need a comfortable place to sit that feels like a distinct place and maybe has some sort of sense of enclosure around it. And window place is a pattern that talks about how you arrange, basically, chairs and windows.

And workspace enclosure is about the fact that people like work spaces where they feel they have a certain sense of privacy, but can still see the other people that are out there in their workplace. And the other people can see them and know when it's appropriate to interrupt them and when it's, in the case of my wife, it's to stop working on the stupid talk. It's a beautiful day. Go outside. Do something. Ride your bike.

So this is what I build, using patterns. And you can see that I took a set of ideas, and I took inspiration from them. I took two patterns, merged them together, added a lobster trap, which there are no lobster traps mentioned in Design Patterns. So it's not that I just copied a template. I created something.

So the thing that the speaker I started with was saying he was doing instead of Design Patterns is exactly the thing that people should be doing with Design Patterns. So this book was the book that came out in, I think, October of 1994, that really made patterns a big thing. It was a hit book.

Now, I was in Ralph Johnson's reading group. So when they were writing this book, I was reading early drafts of this, and I was talking to Ralph Johnson. And so I can say with, I think, a certain amount of authority that they thought of this as a first step in the direction of A Pattern Language. They were trying-- This was the first step on a path that would replicate the experience of using a pattern language, and that all fell apart.

And the question is why. I think you can have several reasons, but I'm going to focus on this one, which is that design patterns started out with not enough building blocks, that were at too low of a level. So if you look at all the design patterns, they're basically composed of two things. There's functions, or methods, which are just functions, and polymorphism, based on inheritance. Those are the two things in your bag of tricks, and that's what you create these design patterns from.

Now, the building blocks from Alexander's book are much richer. There are many, many more of them. These are just a sample of the building blocks used in patterns, where each one of those appears in the title of at least two patterns. So there are lots of building blocks, and they're interconnected in various ways.

So I took my copy of A Pattern Language, and I flipped through the patterns. And whenever there was a pattern that, say, mentioned window and seat, which is the window place pattern, I'd draw a line between it. And so you can see that there are lots of-- seat is connected to lots of different things. Room is connected to lots of different things. So each of these things are building blocks in multiple patterns.

And so if you're using this pattern book, what you might do is you might start out by saying, as was the case for me, I have a window that is facing the street. There's a pattern about windows facing the street, special considerations for that case. So I might read that, and I might look at that. And I might say, ah, well, I want to focus on the window. What other patterns involve windows?

And there's this pattern called window place. And so I read that, and I see that's connected to other patterns. So what I might do, at that point, is I might say, I like this idea of enclosure that is mentioned in window place. So what's a pattern that talks about enclosure? And there's a pattern that involves seats and alcoves. And an alcove is the most enclosed you can get, unless you're in one of those Japanese hotel capsules.

So this is the process of going through it. And again, you can see you're taking a set of ideas, and you're designing from them. You're creating inspiration. Now, what I want to claim is that you cannot do that with the Design Patterns book, because it doesn't have this rich network. Instead, you've only got the two building blocks.

[LAUGHTER]

That wasn't supposed to be funny.

[LAUGHTER]

That wasn't supposed to be funny either. Let's see how long we can keep doing this. We've got functions and inheritance. And there's little interconnect-- there's some interconnection, but little interconnection between these patterns. So what that pushes you toward is a very mechanistic implementation-focused application of the pattern.

So you're working on a program. You say, I've got a tree structure. I want the nodes of the tree, interior nodes of the tree, to be a different type than the leaves of the tree. But I want to do some things to the nodes and the leaves, and I want to be able to do all the usual tree kinds of things. And you look in the Patterns book, and lo and behold, there's composite. It's one of these things that connects functions and inheritance.

And you flip there, and you ignore the bullet lists, and you look for this. And you get the class diagram, and you basically copy and paste it into your code, and you're done. So that is a different way of using patterns than the one everyone was shooting for.

Now, I want to say that composite is a good thing. It's a useful thing. It's a clever thing. I would not have thought of composite, because it's got this cute inversion of what you would expect the inheritance hierarchy to be. So I'm not criticizing composite. I'm even willing to say that composite is a pattern. It appears in lots of different applications. That's one of the characteristics of patterns, is they're not invented so much as they are harvested. So a pattern is worth writing down as a pattern, if you can find multiple independent people solving the same kind of problem in the same kind of way.

And composite fits that, and it does use the building blocks, so we can put it in the book called Design Patterns. So composite is a pattern, and that's fine. But you can also say, by the same token, that bed is a pattern. It's composed of building blocks, and there are lots of people who have invented beds. And they've come up with kind of the same sort of design. Futons aren't the same as a Posturepedic bed, but they're recognizably part of the same family.

Beds are useful. I enjoyed my bed at the hotel last night. But you won't find a pattern called bed in a pattern language, and that's because we don't have a problem with beds. Beds are solved. What we have a problem with is building with beds. And that's why, if you look in A Pattern Language, you'll find there are a number of patterns that involve beds.

So there are things that talk about beds and the light that comes in through the windows. There are things that talk about beds in adjacent seating. I think there is even one that talks about, that involves, beds and closets. But I'm not sure of that. So beds appears in many patterns, because people need to know how to arrange a bed and the space around it so that it's comfortable and nice.

Now, the analogy I want to make is, basically, the design patterns in the book Design Patterns are at the same level as the building blocks in the book A Pattern Language. So bridge, which is one of the design patterns, is the same kind of thing as column. You can call it a pattern, but it's not really a pattern that gets at the root problem we're trying to solve. And if Alexander had written a book that had a pattern called bed and another one called chair, I imagine that that book would have failed and not inspired all of the people that the actual book did inspire. So that, I claim, is why patterns failed.

A final bit of the talk is, should we care if Design Patterns failed? Now, obviously, I'm invested in it. There's the whole sunk cost fallacy thing. So obviously, I'm going to say, yes, we should care. But I want to say that in a slightly different way.

Looking at this unexpectedly humorous picture, you'll notice that if you just look at as a picture without context, this looks a lot like what we as programmers are supposed to be doing. This up here is a mess. It's complicated. This down here is simple. It's even elegant. We've learned from our mathematician and physician betters, superiors, that prettiness is a sign that you're doing something right. And this is a lot prettier than that thing up there.

So this constructing order out of chaos seems to be what we're told over and over and over again, in the process of learning how to do programming. So if you've come up in the traditional route, where you're going to a university to learn programming, you'll hear about abstraction, abstraction, abstraction. It's important to abstract. Don't repeat yourself. Factor out common methods. And you'll be exposed to examples of great abstractions I have known, that talk to you about how a complicated situation was made simpler and cleaner and better.

You will occasionally-- you'll occasionally be told, you can oversimplify. And often, they'll use this quote, which is attributed to Einstein-- "Everything should be made as simple as possible, but no simpler." It's interesting. Einstein never actually said that. It's probably a paraphrase of this, that he actually did say-- "The supreme goal of all theory--

[LAUGHTER]

--is to make the irreducible, basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." That's a somewhat richer quote. So--

[LAUGHTER]

The only part of this talk that's supposed to be funny is what's coming right now.

[LAUGHTER]

Which is we should spend a moment reflecting on the fact that a paraphrase that warns us about oversimplification--

[LAUGHTER]

--is itself an oversimplification of the thing it's meant to paraphrase. You may now laugh.

[LAUGHTER]

Thank you. So having been told this, we go back to the great abstractions I have known. And the more mathematical a name you can pick, the better person you are.

[LAUGHTER]

And on and on. By the way, Elm, which is kind of in the family I'm making fun of here, Elm is a great language. It's the language I use for front end programming. OK, so we've got that tendency to abstraction. And there's very little in our education experience, whether it's formal or informal, that warns us about it. Now, fortunately, we've got other people to warn us.

The one on the left is Paul Feyerabend. He's a philosopher of science, one of whose earlier books, called Against Method, is literally a book that made me who I am today, or at least led me on the path to that. This book is Conquest of Abundance-- A Tale of Abstraction Versus the Richness of Being"-- or I would say reality.

And the other book is James C Scott. He is an anthropologist. His book is Seeing Like A State-- How Certain Schemes to Improve the Human Condition Have Failed. This book is essentially a long litany of cases where people have taken a complicated, maybe even chaotic situation, found a good abstraction or a good set of abstractions, applied those abstractions to the problem, and made everything worse. And he's looking for characteristics of why that happens and what can be done about it.

I'm going to use, not an example of his, but here's something that's griped me for a long time. In the early days of test-driven design or refactoring, there was this notion of code smells that became popular. It became a catch phrase. It was used in Martin Fowler's Refactoring book. Now, it's possible that-- I think Kent Beck introduced the phrase code smell. And if you talk to people who talk about code smells, you'll usually find that duplication is one of the major code smells.

But when you talk about them, it's not just, oh, this block of code here looks exactly like this block of code. If you talk to people who've worked with the great code smellers, what they will tell you is-- Ron Jeffries has said something like this about Kent Beck. He'll say, Beck will say, there is this code smell here. And Ron won't see it. And Beck will start changing the stuff around and moving it around and fixing it. And then, all of a sudden, it becomes clear that, in fact, there was knowledge over here and over here, that even though there was nothing structurally similar, they were duplication that could be fixed.

And I've had people who are good at this do this to some of my code, and it's magic when they do it. And of course, any time we see magic, we have to ruin it.

[LAUGHTER]

So what happened is no doubt, many people all at once said, ah, code smells-- let's write an automatic code smell detector. And they did. But the problem is so much of code smells is in the head of the person looking at the code, and only some of it is in the actual text of the program. So the automatic code smell detectors turn into things that just distinguish, look at two abstract syntax trees, and say, those look alike-ish to me.

And this important notion that it's about duplication, many-faceted kinds of duplication, duplication of knowledge gets lost. James C Scott talks about this as metis, I believe, is how it's pronounced. It's a Greek word meaning practical knowledge. And he says, it's this kind of knowledge that tends to get lost in the process of abstraction.

So his description of metis is, "the kind of knowledge that can be acquired only by long practice in similar but rarely identical tasks, which requires constant adaptation to changing circumstances." It's a process of learning over time and doing the same thing over again, and looking at some code and not really liking it, but living with it, until two months later, you realize what that little niggling feeling in the back of your head was trying to tell you. And now, you know a little bit more about code smells.

All of that stuff is not discussed, or it's very lightly discussed, in software. It's taught not at all or very seldom. And that's a big disadvantage to our field. Just to plug another book, there's a guy named Donald Schon. He's got a book called Educating the Reflective Practitioner, which he doesn't use metis or any of that. But he's talking about how people learn this kind of practical knowledge, which is much more difficult than you might think.

So I guess, on Gary's original slide, I was the tip-top point of abstraction. But what I'm actually saying is we've got too much abstraction in this field and not enough of the metis. And what I would like to propose that you go out and do immediately is redress the balance a little. Not saying abstraction is a bad thing, so don't tweet that. I'm just saying we need more balance.

Abstraction is still really important to our field, obviously. It's what makes our field-- one of the things that makes our field special. So we'll always have that, but we need to have this concrete idea that there is a thing that's not abstraction, that is actually good.

So I did here a retrospective of patterns, so a not very successful sprint. And any good retrospective should end with action items. So I have an action item. The action item is maybe we should try patterns again. If I'm right, we now understand some of the ways they can fail, so we can avoid those mistakes. And patterns were an attempt, one attempt, by Christopher Alexander, to take common knowledge, practical knowledge, metis, and somehow get it written down in a way that people could use it and be inspired by it.

So I'd like to suggest starting patterns up again. And to do so, what we should do is start from this book, Domain-Driven Design, by Eric Evans, which is the book that, in feeling and rhetorical style and in lots of other properties, it's the closest software book to the original inspiration of patterns, a pattern language. So that is what I have to say.

[APPLAUSE]