Design patterns are from hell!

The “Design Patterns” book is one of the worst programming books ever. Yes, really. I’m 100% dead serious when I say that I think it has set (and will continue to set) the progress of software development back by decades. Why?! Let me offer up a parable; I will call it “The Plank.”

The Plank

Back when I took computer science, as part of the curriculum was a compulsory class in statistics. Two of my closest friends (Olle and Martin) and I scoffed at this statistics class — we were computer scientists for chrissake, we don’t care about statistics! — and kept postponing the class year after year, until we basically had to take it in order to graduate. Still, we resisted up to the very last minute. Sure, we went to a few lectures, but didn’t pay attention, didn’t do any exercises, or anything. We sort of were planning to postpone it another year, because… duh… statistics! Except, the Friday before the Monday of the exam, Olle (I think) really insisted we should take the exam and get rid of this horrible thing once and for all. His brilliant idea: just cram all weekend and do the exam on Monday! Reluctantly we all agreed the time had come and it was the right thing to do.

The plan of attack that we devised was to go through the exams of the last several years, look at every question that was asked and see if we could identify questions or question categories that recurred, and learn enough categories that we’d get a passing grade on the course. I don’t recall the details, but let’s say that the typical exam had 10 questions, worth 5 points each, and you needed 25 points for a passing grade (50%) and 38 points for passing with honors (75%). Thus, we needed to learn 5 categories and ace the questions to pass. To err on the side of caution, I think we identified 8 question categories from combing through the old exams (which you generally do get access to in Sweden) for several hours. We then sat down, split the question categories amongst us, and each studied only the text book chapters relevant to our own categories. After cramming the chapters enough that we could solve questions from that category, we taught each other what we had learned, and the steps to solving these questions.

One trick we devised was to create our own stereotypical problem for each problem category, and we pretty much memorized its solution as a means to remember how to solve problems in that category. I only vaguely recall one particular stereotypical problem that we had named “The Plank” because it involved sawing a wooden plank in two and somehow looking at the distribution of the lengths of the two resulting pieces.

We spent Friday evening and all of Saturday and Sunday doing this. Sunday, Olle brought along caffeine pills as an extra study aid. Everything to give us the edge in defeating the statistics beast!

Monday morning as we gathered outside the exam room, Olle looked like a man possessed. He had stayed up all night, popping caffeine pills like they were peanuts. “I feel good about this,” he said as we entered the room. Finally, sitting down with the dreaded statistics exam in front of me, I dove right in quickly trying to solve as many problems as possible with the limited statistics knowledge I had crammed into my head before it evaporated! To this day I vividly recall looking at one of the questions of the exam, thinking “Yes! Score! It’s The Plank!” and furiously scribbled down the solution I had memorized, but applied to this incarnation of the problem. Six long hours later the exam was over and the three of us met outside. “I think I aced it,” Olle exclaimed. Martin and I weren’t quite as confident.

Two weeks or so later, we finally got the results. Olle didn’t quite ace it, but he did get over 75%, passing with honors. So did Martin. I was 3 or 4 points shy of the 75% limit, only getting a passable grade. Looking over my answers I soon found out why. I had a zero on The Plank question! Reading the question again, suddenly it was clear to me: it wasn’t The Plank, it just superficially looked like The Plank! It was also painfully clear to me that had I paused and thought about the problem for a while, I would not only have realized this, but I would also have nailed the question, because I knew how to solve it!

If you didn’t guess it already, The Plank is a design pattern. In this case, I had focused so heavily on the design patterns we had identified that I was seeing solutions before I was seeing the problem! I would have done much better not learning any of the patterns in the first place, just relying on the skills I had obtained through study, which got me through all the other questions.

Stay away from the box, or I’ll smack your head with the plank

How does that story relate, you ask? I’ll tell you. What the Design Patterns book teaches is for people to think in the box instead of outside of it; just as I did on that exam. Pattern thinking has now permeated and perverted peoples’ thinking to the extent where patterns are perceived as being an ends; something you need to use to correctly solve problems. Such thinking, whether intended or not is, of course, utter nonsense. Worse, it’s pure poison to the malleable brain of a young programmer! Thinking in patterns is exactly the wrong thing to do! It makes you think in terms of the solution instead of in terms of the problem! Pattern thinking makes you try to fit a round, square, or oval hole (your choice of patterns) to the triangular peg (your problem). When all you have is a hammer…

As if spreading poisonous mind rot wasn’t enough, the other outrageous thing about the Book From Hell is that it took stuff that had been known forever in computer science circles and renamed things we already knew by some other name (or indeed no name at all, because it’s blatantly obvious). For example, before dumb and dumber decided to call it the “visitor pattern” every programmer worth his salt would just call it a “map” operation (as in the LISP functions “map”, “mapcar”, “maplist”, etc). That’s just, oh, something like 1994-1960(?) = 34 years of previously established terminology! Twits.

Peter Norvig has a more reasoned presentation on why design patterns are completely not needed if you use a reasonably modern programming language (instead of tripe like C++ and Java).

Design patterns? Just say no!

52 thoughts on “Design patterns are from hell!”

  1. Nice story, Christer. When you mentioned “The Plank” I was expecting this.

    What annoys me more than Design Patterns is when programmers talk about designing for “reuse”. Instead, how about designing for use?

    The book from hell as you call it is, in my opinion, only relevant to implementation of ’90s era GUI toolkits in pre-generic programming C++. cf: InterViews. A lecturer and potential PhD supervisor of mine was Paul Calder, who’s PhD work is paraphrased in the book as Lexi, so I’ve had some exposure to the horror of various toolkits in the X Windows world.

  2. I agree that the Design Patterns book is likely to have set programming back more than slightly. I have never read the book directly but I am aware of the pattern it is based on. What your missing is that this book is entirely appropriate for computer scientist. Scientists are specifically tasked with exploration and discovery. Engineers, however should consider such items insofar as they fit the requirements of the task at hand. Many disciplines have design patterns. What you are noticing is that some people are acting as engineers who are not. I attribute prevalence in our industry to universities not making the distinction between science and engineering.

  3. Ah finally. I totally agree with you! I think that this is a very general problem, in fact, is one of the problems that I see more while programming. Just a bit of knowledge is horrible, its the cause of all programming errors.

    from my blog (http://c0de517e.blogspot.com/2008/04/singletons-new-superglue.html):
    “Generally speaking, I don’t like patterns too much. They provide you just the right amount of knowledge you need to make a bad design, thinking it’s good. The worst errors I’ve ever seen do not came from no knowledge, but from having just the the right amount of it, too small to really understand what you’re doing, but enough to think you did. That amount of knowledge, is evil.”

  4. One factual correction. Map and visitor aren’t very closely related at all other than that the former might or might not use the later and the later might or might not be used in the former.

    Map is about creating homomorphisms. E.g. it’s a transformation from one list to another list, or from one tree to another tree, etc. For a better generalization of the concept than you find in most lisp variants, check out fmap in Haskell. When you fully grok it you’ll see it as a way to transform even something like a parser.

    Visitor, on the other hand, is about decision making on a single object. The decision making may or may not have anything to do with functors like list and tree. You can apply a visitor to a single object and the result might be a transformation or a side effect or whatever. A better analogy is that visitor is a “pattern” for encoding a form of multiple dispatch into a single dispatch OO language. For equivalents in lisp look at CLOS, which is already multiple dispatch. In modern functional languages, e.g. Haskell and Scala, the same idea is (more or less) subsumed by pattern matching – but read about the Expression Problem to see how they have complementary strengths and weaknesses. http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt

    You CAN tie visitor and map together – but not because they are the same thing. For instance, map in an OO language that doesn’t do HOFs will use the “Strategy” pattern. If the strategy needs to make a decision based on runtime types of elements and the language doesn’t have pattern matching, then it might also use the Visitor pattern.

  5. Your argument is wrong. When looking at a bizarre problem, you automatically thing of usual solutions, which might be wrong. When you look at a normal problem, which you do all of the time, it tells you the answer straight away.

    As the quotation goes, “Those who do not know history are doomed to repeat it”. If you don’t know the list of normal solutions to normal problems, you’ll spend all of your time reinventing them.

    The problem isn’t teaching design patterns, it’s the inability to see where they don’t fit.

  6. I don’t see how the Visitor pattern is related to the “map” operation (as in the LISP functions “map”, “mapcar”, “maplist”, etc).

  7. Your parable seems mostly to teach that procrastinating drug-addled students contemptuous of their subject matter do more poorly than they might in examinations to which they pay insufficient attention. I don’t think that this is news.

    What GoF teaches is that good designers understand that they don’t need to solve every problem in a novel way. That there can be advantages to using once more a design approach that has already been used many times before. It also teaches that each such design approach has consequences, and that these can sometimes be problematical in their own right. It also teaches that a given approach will be suited to some circumstances more than others and should be used mainly in the former. And I’d say that if GoF has anything to say about boxes is that since you are going to spend most of your time in a box, perhaps it would be best to know your way around it.

    If GoF has been abused by bad teachers, blame them not it.

    By the way, if Norvig says that Lisp doesn’t have patterns (which he doesn’t, but if he did) then he’s simply dead wrong: http://peripateticaxiom.blogspot.com/2008/01/problem-with-problems-with-patterns.html#patterns_in_lisp

  8. I found this post quite refreshing. I’ve been programming games since WAY before The Book came out, and have been too busy shipping to catch up. A couple of years ago I started to feel like I had missed out on something important, because people around me started having conversations that sounded like they were from another planet. “Oh why don’t you use a Flyweight Decorator on a Memento Observer?” After I finally read the code they wrote it gradually dawned on me that they were just using funny words for commonly practiced techniques that had already been around forever as you point out; and sometimes they were just adding extra layers of obfuscation and indirection on top of things that should be fast. I think I started getting a bit tired of patterns when I started getting feedback that I hadn’t implemented a Singleton properly, and I’m like, excuse me, back in the day, this was called a global variable. In any case it’s going to sit in the BSS, and damned if I’m going to go and hit the d-cache AND the i-cache to satisfy a semantic. I sometimes feel that a lot of the Patterns simply wallpaper over deficiencies in the language design!

  9. I find the criticism of patterns in this post superficial. Any programming book can become the hammer that makes everything look like a nail and that tells us more about the readers than about the book.

    For a much better pattern-bashing article see ‘ “Design Patterns” aren’t’ at http://perl.plover.com/yak/design/ . I think it should be required reading for every DP critic.

  10. @ Nick “using funny words for commonly practiced techniques that had already been around forever” is one of the major benefits of using patterns. Are you suggesting that it is in some way a bad thing that programmers develop a well-known vocabulary to talk succinctly about frequently occurring phenomena in their practice?

  11. Dan, you’re dating yourself! It did occur to me that The Plank might cause associations to the Eric Sykes’ slapsticks (plural, as there is a second, later version of The Plank, which is the one I’m familiar with), but I figured no one would remember it. (I just dated myself.)

    Aron, I see what you’re saying, but I disagree. Yes, patterns are everywhere; after all, our brains are giant pattern detectors. However, that doesn’t mean there’s any more need for scientific study of design patterns than there is for study of, say, patterns for wiping one’s ass.

    Angelo, amen.

    James, it wouldn’t be a very good rant if I let the message get hidden amongst extensive technical elaboration; the post is about the big picture. I imagine that despite your protestation, you’re astute enough to understand what I was getting at, even in this technically simplified form. (BTW, with ‘map’ I wasn’t just referring to the homeomorphic variants of ‘map’ but general mapping across a structure, so including e.g. CL’s mapcan, etc.)

    Mr Hate, arguments that can be “wrong” are reasoning ones, which present a series of steps leading from premise to conclusion. My argument was one of emotional nature. They cannot be “wrong.” Thus, you’re wrong in saying “your argument is wrong.” (This was a reasoning argument.)

    Dave, you should try caffeine pills!

    Keith, I’m sorry I poo-pooed your dogma. Just to let you know, I’m afraid that at some later point I’ll probably be poo-pooing agile, extreme programming, and all that other programming mumbo-jumbo you’ve made a career of, so you might want to, um, stay away for that. (Look, nowhere did I say vested interest. Oh. Darn it.)

    cruizer, they are too from hell. Proof: the next edition of Design Patterns lists 666 patterns.

    Nick, but the words make them feel important! (That, and serve to draw attention away from the fact they cannot actually code.) You don’t want them to feel unimportant do you?

    praptak, see comment for Mr Hate.

    Keith, do you know there’s a whole world outside the box?

  12. Hej Hej Christer

    Australia is a British colony and we aren’t likely to give up the Queen of Australia any time soon, so all British comedy and slapstick is required viewing for school children. (Could we trade royal families?)

    I’m sorry for both of us, if we are dated. Time to replace the safari suit?

    Can’t wait for your rant on Agile

    DanG
    (Who should stop posting comments and blog more)

  13. Christer, do you know that all that’s outside your box is another box?

    By the way, your book looks pretty interesting. I might buy a copy. I especially like the way you’ve collected together lots of solutions that everyone has been using for years along with their names.

    It’s almost as if you’ve published a vocabulary of well-known designs that can be re-used by others in your field. I wish that there was a term for that kind of thing, might be useful in other domains too…

  14. Nick: LOL at “Memento Observer”

    Norvig describes what patterns are nicely in a slide as “Descriptions of what experienced designers know (that isn’t written down in the Language Manual)”

    So if you want to do multiple dispatch in C++, which doesn’t have it, you need to implement it yourself. Give all the missing things names and formalise them and you have the GoF Design Patterns book.

    I’m sure there’s a tonne of patterns I use my head, but I couldn’t articulate them all easily to someone else. If somebody was able to, for our line of work, I think it would look very different to the ones in the GoF books.

  15. I also don’t like design patterns, but for a different reason.

    IMO design patterns reflect language deficiencies. The example I think of the most, because I learned to program in C, are all the OOP C “design patterns” (although they weren’t called that at the time) which involved aligning structs in memory and the like.

    These “design patterns” were codified, brought down to the syntactic level, and made into the OOP languages in the C family tree. The same thing has happened with other, “proper” design patterns.

    The Factory Pattern is obsolete in languages that support metaprogramming, like Ruby, for example.

  16. Christer,

    Oh, I think it’s a good rant. Like all good rants there’s a bit of hyperbole and a bit of simplification. The core problem is really about hammer wielders looking for nails and ignoring or pounding down screws, something which is not unique to the patterns community. But I’m not arguing against hyperbole or simplification. It is a rant, after all, and that’s the kind of stuff that rants do.

    But if you want to rant about renaming things then Visitor is a renaming of “multiple dispatch” or the more specific “double dispatch.” Strategy is a renaming of “function value” or “function object” or “first class function.” Singleton is a renaming of “module” (for at least one kind of non-first-class module). Facade is a renaming of “API”. There’s plenty of renaming to complain about.

    But “map”, in whichever flavor, has nothing to do with double dispatch except that double dispatch (or “Visitor”) can be used in the transformation function (or function object or “Strategy”) passed to map.

  17. Keith, the fact that you see boxes everywhere you look is a clear indication that pattern thinking has clouded your brain. Seriously though, it saddens me that you cannot see the difference between descriptions of data structures and algorithms and design patterns. Then again, that’s exactly the kind of skill you need to excel in the world of Agile, so power to you!

    tunafish, broaden your mind and you’ll realize that “a book about programming” is a strict (and possibly small) subset of “a programming book.”

    James, I wasn’t so much trying to say that “map” equals “visitor pattern” but that a typical usage we see of the visitor pattern (or, at least, that I see) is over a collection or structure of elements, for which “map operation” has always been adequate terminology.
     Had I known several thousand prepubertal reddit readers (not you, mind you) would be dropping in, eager to nitpick on irrelevant details and incapable of seeing the forrest for all the trees, I probably would have elaborated more and not posted at 2AM in the morning.

    And for the plonker on reddit (phaed) who couldn’t fathom the “50% a passing grade, 75% passing with honors” thing: in Sweden we center the bell curve in the neighborhood of 50%, unlike the US where it’s centered around something like 75%. If you had taken statistics (like me!), you’d understand this means it’s actually harder to pass with honors in Sweden than in the US. We also complete our masters degrees in about half the time too — in part because we don’t think it’s relevant to have electives like bowling as part of a computer science program. Bowl on dude!

  18. Christer, what can I say? It saddens me that you think there is some very important difference between descriptions of data structures and algorithms and design patterns. By the way, GoF isn’t a major, or even representative, part of the patterns literature these days.

    I get the feeling that you don’t really know what you’re talking about when you say “pattern”

    You know that there are thousands of patterns, in all sorts of domains? Some large, some small, some formal, some informal? That many, many practitioners have a lot of success using them in teams of many kinds in organizations all over the world? And there are plenty of not so skilled folks that don’t use patterns correctly: of what tool is that not true?

    More broadly, I wonder what it is that makes you so angry about folks being successful (that is, successful at improving their customer-pleasing delivery capability) in ways that you’ve decided you don’t like?

  19. Keith, in terms you might grok (though clearly not agree with): if every book and all knowledge about data structures and algorithms would disappear overnight, no software could be developed. If every book and all knowledge of design patterns would disappear overnight all that would happen is… nothing! Design patterns have no value.

  20. Here are my 2 cents on what you have posted and I would like to sum up my thoughts in one line by saying – “Design Patterns are a Helper and Design Patterns are a Bar” What do I really mean by this?

    One can view this as two categories of people: the class and the mass. Generally speaking the class are the people who are innovators (or pioneers) and can view at a problem from a different plane and solve it, they are problem-solvers by nature and then there are those who are not great problem solvers, they look at finding to solve the problem by thinking in the box and get over with it (either because they do not have enough time or they do not have the skills/capability to think out of the box…whatever be the reason). Now, for people of these kind, they would love to see if someone has treaded down that path and tried to solve a similar
    situation. If they find one, they would apply that solution and move ahead. Whereas a problem-solver is a person, who would go to the roots of it, and come up with solutions that solves the problem differently or in a similar way the other journeymen have solved it earlier.

    This is exactly the case with Design Patterns. They are some good solutions to problems shown by the journeymen who have been in similar situations, but are not meant to be taken as gospel. If you do that, you are stopping innovation. Other aspect is do I want to get conditioned to the way people think? Isn’t this similar to cultural conditioning that our societies do to us as individual…would you then say that I don’t need this way of life, i’ll create my own…my answer is probably let us start somewhere, realize its applicability, merits and drawbacks and then point out a new way which you have invented/discovered. So, one has to be diligent enough in realizing that when patterns become a bar and stop your progress, its time to go back to the drawing boards, dive to seek a deeper insight. If you belong to class, then this realization dawns quickly and you will rise towards newer innovative solutions. Whereas, for masses, they need something to rely upon, to guide upon until, they themselves become a class.

    One of the things that I really like is to depend on more deeper principles, like the SRP, OCP, LSP, DIP etc… which Uncle Bob has mentioned in his book and I have seen that these when applied through continuous refactoring ultimately evolve to some known pattern. Again these are not to be taken as gospel, but they are quite sound. Also, one can reflect upon your past project problems and who knows, you may uncover even more deeper ideas than these principles mentioned in his book.

  21. Christer, now we’re getting somewhere. You’ve stopped shouting about how angry you are and said something interesting.

    I don’t agree, partly because I think one of your assumptions is wrong, and partly because your value judgments seem too unrefined. Let’s take a more subtle view.

    If every book and all knowledge about data structures and algorithms would disappear overnight then we’d be back to where we were before that knowledge was developed in the first place. Quite how far back depends on what you think an algorithm is (do we lose al Khwarizmi? Euclid? Double-entry book-keeping? a lot more than programming wold stop), but lets say that we end up back where Kleene and Church and Turing were when they began their study of computation. That was a lifetime ago so it would a slog to get that stuff back. But we would. The material would be (re)discovered, just as it was discovered in the first place. So such a loss would be devastating indeed and there would be a substantial gap before we got going again.

    In comparison, losing all the patterns, but not the algorithms, wouldn’t be an outright disaster but it would be an very great inconvenience. GUI programmers no longer know what MVC is. No-one who wants to connecting to a database knows what an ActiveRecord is, nor a DAO. I appreciate that this maybe isn’t of much interest in your domain, but trust me, having knowledge of these things go away would wreck a huge chunk of the industry. Would we still be able to write software at all? Yes. Would doing so be a slower, more expensive, more error prone, harder to maintain? I’d say yes.

    So, no, I don’t agree that patterns have no value. Is knowledge of patterns absolutely necessary for programming to happen at all? Clearly not. Is the value of a technique a binary variable? Also clearly not.

    By the way, someone has seen fit to collect a bunch of patterns in the games programming domain: http://www.amazon.com/Patterns-Game-Design-Development/dp/1584503548 Presumably you never, ever use any of the vocabulary in there, and consider the material described to be of zero value? Being stopped from using the solutions presented would have no impact whatsoever on you and your team, I take it?

  22. That’s not even a book about programming, it’s a book about design.

    In my experience, when a game programmer starts using fancy words to describe things that have been known for decades (like “singleton”), something terribly wrong is about to happen: virtual inheritance might be lurking in the shadows, a dynamic cast might pounce at the unsuspecting CPU, an exception might get thrown, or a std::map > is about to be born. Not because patterns call for these, but because they are part of a larger, foul-smelling package: the “software engineering” mindset. You know, that stuff you do when you can’t actually program, but want to make it look like you can and be the boss (i.e. order overtime pizza).

    If binary trees disappear tomorrow, we’ll have to spend some time reinventing them. If the word “singleton” disappears tomorrow, absolutely nothing will be lost. Nothing would have to be reinvented. We won’t be set back because of it, not even one second, because everybody knows how and when to make a global variable. Giving it a fancy name hurts, because then people start feeling smarter than they are when they learn this exquisite new word. Actually, if singletons go away, maybe our build times will go down, because we won’t have huge classes called “Render”, “ResourceManager”, “Logger” and so on, which are included everywhere and cause a recompile of the project when somebody changes a private member (which in a sane world wouldn’t be a member at all but a static global in some cpp).

    When I first heard about design patterns, I thought they’re some kind of Holy Grail and set out on a quest to make my life richer by learning about them. But then I found them and went like “what the hell?”. It’s obvious stuff. It’s stuff which you either figure out by yourself, or you don’t belong in programming. Yes it occurs often, but so does calling the elevator. There’s no need to write a book on elevator calling just because it exists.

    Seriously, I don’t know if this stuff makes software cheaper. It may allow non-problem-solvers to get jobs as programmers and I feel like in the long run that’s not a smart thing to do. It also allows “software engineers” to get smug looks on their faces when they utter nonsense like “singleton” or “visitor pattern” and “non-software-engineers” don’t get it. I don’t know what the demand for these people is in other branches of software development, but surely we don’t need them in game development.

    Design patterns: The Problem Mutilator™.

  23. This is genuinely very fascinating to me.

    “that stuff you do when you can’t actually program, but want to make it look like you can”

    I wonder what “can’t actually program” means? In my world (which, BTW, is one where anyone who suggests using a Singleton gets shouted at, and the keyboard taken away from them) there’s a strong correlation between familiarity with patterns (especially when not to use any particular one) and being someone who adds a lot of value.

    But then again, in my world code is the enemy because we know that every line we write will potentially be causing someone a headache in ten, twenty, fifty years. There are some guys who work for me who are working with Fortran from the 1950’s and it would be a huge help if the guys who wrote that stuff had written down the explanations for the idioms that they use (before they died).

    “When I first heard about design patterns, I thought they’re some kind of Holy Grail and set out on a quest to make my life richer by learning about them.”

    How did you come to that conclusion? What aspect of the way that you heard about patterns lead you to believe this? These questions are not sarcastic.

    “But then I found them and went like “what the hell?”. It’s obvious stuff. It’s stuff which you either figure out by yourself, or you don’t belong in programming.”

    Well, yes. And no. I agree that anyone who is going to be a programmer should be capable of “figuring out” the content a pattern, I don’t agree that we should therefore make everyone do that if they want to use a technique. Patterns aim to capture knowledge born of past experience and make it findable and usable, and thus learning should be faster with them than without. Which would seem to be a good thing.

    “Giving it a fancy name hurts, because then people start feeling smarter than they are when they learn this exquisite new word.”

    Hmm. One of the goals of naming patterns is to enable people to be smarter (but it’s certainly not guaranteed), in much the same way as mathematical notation is meant to. Frankly, this sort of complaint smacks of insecurity.

  24. “Patterns aim to capture knowledge born of past experience and make it findable and usable, and thus learning should be faster with them than without.”

    I agree that there’s a need to formalize things if you want to teach them. Maybe some of these pattern things are actually worth teaching, though I still say that many of them are trivial and should occur naturally in the mind of a programmer. But naming trivial stuff is counter-productive; it’s obfuscation. And it does lend a sense of self-importance to those who can speak the lingo. It’s not insecurity you’re sensing, it’s frustration at people trying to patronize other people by calling select() a “reactor pattern”. When I hear this stuff in a meeting I feel transported into a TV interview with some “account” or “creative” from the advertising industry; I instantly feel like suffocating the speaker with a dictionary because of the shower of made-up words.

    It may be faster to tell somebody to “apply a reactor pattern” than to use 10 more words to describe what you mean (given that the person doesn’t know about select()). However, that’s assuming the person knows what this otherwise meaningless idiom is. That requires them to go through some books and read an abstract, dry description of something which is trivial in practice. It’s like math notation only if you abuse math notation by forcing it into places where a couple of words would be more descriptive. It’s not something a good educator would do. Sure, after the proper explanation you can say “and this is called a reactor pattern”, but that’s just trivia.

    I came to the conclusion that patterns must be some sort of Grail because they were hyped to me by several of the People Who Know About Patterns. I thought they’ll help me organize and formalize solutions to recurring problems, maybe even help me see “elegant” solutions to new problems. Well, guess what: it was just stuff which I knew and used before, but with fancy names. Sorry, but it was just wasted time for me and I strongly feel that it should be wasted time for most people I’d like to work with, i.e. people who “can actually program”: solve problems, get the job done, innovate.

  25. Keith, “we” are not “getting somewhere.” That would imply I have an interest in perpetuating this dialog; I do not.

    Nevertheless, I feel compelled to point out that you should consider if “it saddens me that you think there is some very important difference between descriptions of data structures and algorithms and design patterns” is consistent with “a loss [of data structures and algorithms] would be devastating” but “losing all the patterns […] wouldn’t be an outright disaster but it would be an very great inconvenience” (my emphasis). To me, seems like you backpedaled like hell on there not being an important difference. Also, you admitting frowning upon the singleton pattern doesn’t rhyme well with your broad claim that “patterns aim to capture knowledge born of past experience and make it findable and usable, and thus learning should be faster with them than without. Which would seem to be a good thing.” Either you backpedaled again, or you are admitting not all patterns are useful. And the latter is exactly what I’m saying (except I replaced the “not all” bit with “no” for more accuracy and conciseness).

    And yes, the “Patterns in Games Design” book is a waste of paper, just like the Book From Hell. It’s an academic exercise from start to finish, with no practical relevancy to game development reality.

  26. Christer, I won’t expect a reply, then ;)

    I can see why you’d think I’m backpedalling. Now that I understanding the kind of difference you meant better, then yes I needed to refine my point. And I can see that you still want there to be a very hard black/white distinction between any value at all and non, with patterns on the non side. I still absolutely disagree with that.

    I don’t admit that not all patterns are useful. And I certainly don’t admit that having them written down isn’t useful. That’s independent of whether or not I use a particular pattern.

    Every pattern has a context where it has (really has, by actual programmers other than the pattern author) been applied many times before, and a resulting context where certain aspects of the situation have changed, some for better some for worse. A pattern that doesn’t tell you it’s down side is a bad pattern. And that’s all a pattern is, a frequently applied mapping from one common set of circumstances to another.

    It turns out (after 10 years and more practice) that the circumstances under which Singleton applies well are very rare, and the resulting context is rarely much of an improvement. Having Singleton written down is still useful, though. As is having the name. Often in sentences like “that’s effectively a Singleton, don’t do that” This still accelerates learning. Learning what not to do is a very good thing, isn’t it?

    It’s a shame that a weak pattern like Singleton gives people who’d like to dismiss patterns as a whole some low-hanging fruit. It’s a nasty, wizened little crab-apple of a fruit, though.

    I’m a huge fan of patterns as social phenomenon, and as a knowledge management tool. I know and use patterns, use them frequently. That shouldn’t, and doesn’t, mean that I use every pattern I’ve ever head of everywhere all the time. It doesn’t mean that I recommend that anyone else does that. It also doesn’t mean (in fact, it means the opposite) that I think GoF is the finest expression of the pattern idea, nor that I think all the patterns in GoF are particularly good examples of the form. And that itself doesn’t mean that I think GoF is a particularly bad thing, either.

    What it is, is old. And that necessarily limits the applicability of some of the patterns in it, because the contexts they address don’t occur as frequently as they used to. I’d be interested to meet the folks who are going around saying that the GoF patterns are some sort of end-point (or high-point) for design thinking. They are simply wrong. And GoF is still useful to have. The world is a complicated and subtle place.

  27. @keithb
    “Nick, are you suggesting that it is in some way a bad thing that programmers develop a well-known vocabulary to talk succinctly about frequently occurring phenomena in their practice?”

    No, I am suggesting that too many people confuse having vocabulary with having knowledge of what those words describe.

    I agree with you that design patterns have didactic value; you can use them to teach and introduce. I am dismayed that many programmers do not look beyond rote application, or worse, treat patterns as inviolate dogma.

  28. The premise of the original rant is not well supported by the analogy. I think arguments by analogy are weak. To give an example of the kind of flaw I am thinking of, Christer strongly implies that he specifically did not pay attention to the problem and misused the Plank. So his failure in this case could be due to the misapplication of a pattern, and not a flaw in the pattern, or the concept of a pattern.

    It would be better to provide some specific evidence for the following statement:

    “Pattern thinking has now permeated and perverted peoples’ thinking to the extent where patterns are perceived as being an ends; something you need to use to correctly solve problems.”

    To really accept the argument it would be best to show some kind of quantitative evidence to support this claim. For instance, something like showing that significant quantities of people are learning “pattern thinking”, and that defects in their code increase after they learn it, compared to a control. That is what you would really want if you are going to believe the assertion of the original post. Maybe that is an unreachably high standard of proof, but without something at least kind of like that, it’s just hand-waving (maybe that is the nature of a rant though). Although, you could possibly get something like that data from studying university courses.

    But even an anecdote would be better than nothing.

  29. I think when it comes to polemic, the rant is the best and most enjoyable mode of rhetoric, and the best modes of response to a polemic rant are to enjoy it or ignore it :)

  30. Kirth, if you bothered to check the pulse of the new generation of programmers on various internet fora, instead of wasting your time on dated sci-fi, you’d find tons of evidence of my statement, such as: [1], [2], [3], [4], [5], [6], and [7].

    These are all from gamedev.net, which is particularly disturbing to me because that’s where a large number of future programmers in my (and your?) field are being raised. However, the very same problem is apparent in just about any forum where you see young programmers congregate.

    Finally, as Nick already implied, you’re sorta deluding yourself if you think a rant needs a proof. But, hey, I’m a nice guy so you got one (actually seven) anyway!

  31. Didn’t patterns actually solve your statistic course problem?

    You spent a minimum of time studying and you all passed, actually with pretty good grades considering. Seems great to me, especially since you wasn’t really interested in learning statistics anyway. Would you have been able to do that without “patterns”?

  32. Nice rant!

    As a swede used to the classic way of studying to exams at the university I fully understand what you try to say with your analogy. Instead of actually learning something for real, you try to memorize some typical assignments and solutions. If you only use that knowledge, you are totally screwed when a new “examinator” appears…

    My personal experience is that I like patterns cause it gives me a way of describing things in simple words. One of the tasks I find most difficult as a developer is naming everything in an understandable fashion. Instead of using ArbitraryClassName I therefor use ICarObserver or TEnemyFactory. That will give the next developer a hint on what the code tries to accomplish.

    So for me I believe the greatest benefit is just the common vocabulary that can be injected into the code. The main pitfall is when you try to apply patterns to everything without understanding the problem.

    Thanks for the enjoying blog and keep up the rants!

  33. Hi MagnusC, and thank you in return for being the one to truly get it! High five, and heja Sverige!

    zaphos, point aside, yes absolutely, statistics is useful in computer science, much unlike design patterns.

  34. Many fields suffer from too much faith in meta knowledge and it quickly turns into pseudo knowledge. Learning all the design patterns on the planet certainly doesn’t make anyone a good programmer just like that, and can possibly also ruin your problem solving skills.

    However, one shouldn’t under estimate the value of patterns in general. It is fairly well established that what discerns an experienced specialist from a beginner, is that the beginner focuses entirely on the problem, and tries to connect it to his or her atomistic knowledge, while the specialist immediately starts to associate to solution patterns. The more experience, the more patterns to associate to, and the more efficient this skill becomes both as an alaytic skill as well as an intuitive skill. This picture is also supported by brain imaging and fairly hard cored science.

    Therefore, I do believe that patterns in code are important for our problem solving skills, but often I’d like to think about these patterns as DATA STRUCTURES and ALGORITHMS rather than fluffy design patterns. There is one area where design patterns actually make quite a difference though, and this is when many programmers collaborate and need to communicate their design choices. Here patterns are quite useful, but one should as usual pay deepest respect to the KISS principle!

    Hälsningar,
    Kenneth

  35. Looking at the parable of Christer and his friends – their mistake was trying to cram a whole semester of learning into one weekend. What could possibly go wrong?

    Sure, their plan was a good one, but they knew there were going to be gaps in their knowledge and they were trying for a high probability of a decent score. Not a 100% score. They got what they were looking for.

    It seems that he has compounded his mistake by trying to draw the wrong lesson from his adventure.

    I think that design patterns are usefull – if only for putting words onto common concepts. Like Christer, I came across design patterns after having programmed for many years, and I found that I already had used many of the techniques from the GoF book. Having words for them is usefull when communicating with other programmers.

    I think that patterns should probably be looked at as a set of common departure points or a set of common attractors in practical programming.

  36. Christer, judging by your replies, I see you may be taking the opinions of others a little too seriously. Your posting was a personal opinion and not a fact, you’ll need to accept the different viewpoints of others.

    I strongly recommend leaving this kind of blogging to Hani Suleiman. He’s more detected emotionally from his blog than you are.

    I can relate to the frustration you feel when it comes to “Young brainless programming zombies” you described, but don’t take it out on everyone else.

    Best regards,
    Richard L. Burton III

  37. Good blog and great post from Nick. “Design Patterns” codified a nomenclature. Unfortunately, “design patterns” are now used by people who don’t know how to code or how computers, networks, and such work. “The Psychology of Everyday Things” and others also talked about patterns. Knowing how to follow a set of instructions to put together a table from IKEA doesn’t make you a table designer nor a structural engineer. The same with patterns. Its bad nowadays in the large companies. Lots of “architects” and “tech-leads” who are clueless. They start their design documents by quoting several design patterns but have little clue how to actually design software.
    P.S. Another enormous flaw in some of the design patterns are because the software was not properly designed in the first place so needs to be able to be changed ex post facto by config files (Spring is a perfect example as of it supports post-release design changes. A bad idea to anyone who knows anything about software engineering due to the enormous loss of quality this may present.).

  38. I wouldn’t go into extremes but I agree that “design patterns” are overrated. They have a marginal value of showing how to solve a specific problem by example, but they most certainly do fail at providing a framework to solving a large variety of problems that they attempt to solve. There’s usually a simpler solution that doesn’t need a fancy name and is easier to communicate to others.. just because it doesn’t need communication. Code has a purpose, that is a spec. The simplest code that satisfies the spec is the easiest to maintain and is therefore the best. That is KISS philosophy. Design patterns do kind of steer people to think in fixed terms.. oh, I see a bridge pattern.. lets write some bridge code. That might be ok, but there could be a simpler solution… a solution for the specific problem at hand. Perhaps the worst part about it is that people start using these highly abstract terms for naming the actual identifiers in the code, and the identifiers become cryptic and impossible to understand. Identifiers should be chosen as specific and self-explanatory as possible. Still some patterns are better than others. Singleton is just silly. Factories in most cases are way too overdesigned although sometimes the procedure of creation of other objects gets complicated enough that it deserves it’s own class.. I might even name it a factory then. To summarize.. common sense > “design patterns”. Still I’ll give the book some credit. If it was trimmed down to about 1/20 the size and renamed to something like “solving class design problems by examples” then it would be far more useful. Think of books like “Programming Pearls”. That’s a truly great book. Design Patterns just isn’t in the same league. But it could be if it was trimmed down to just examples and wasn’t pretending to be more than it is, pseudo-science.

  39. Pingback: | Dev.bg

Leave a Reply