Design patterns have (mostly) flopped | Hacker News Reader

Design patterns have (mostly) flopped

supercoders.com.au

22 pointsandrewstuart49 comments

How about this:

Design patterns have flopped because many if not most of them have proven not to be the universal computer science gems they were touted as.

Rather, they've proven to be:

* Stock workarounds for the overly restrictive type system of a particular language X

* Patterns which in a more powerful language would be a language feature (or trivially abstracted into a small chunk of library code using the language's existing facilities for abstraction) -- but in language X, require so much boilerplate for each invocation, that the boilerplate merits a special name.

(Where for X, substitute mostly Java :)

Even in Java, most patterns can be implemented just fine in a small chunk of library code using the language's existing facilities for abstraction.

I think the relative popularity of design patterns in the Java community has less to do with the verbosity of the language than with historical accident (design patterns became popular at around the same time as Java).

Well, the GoF book was published in the same year as Java's unveiling to the world (1995) so X was C++, but of course today it's indeed mostly Java.

I wasn't sure whether to upvote this article, until I got to this line:

> Design patterns are a universal language that few people speak, a sort of Esperanto for programmers.

Exactly. And I fully expect many of the hackers here to chime in with 'oh, that article is so wrong'. But, the thing is, HN geeks, you are that rare breed that knows and applies the patterns. I've met you, and I've worked with you. And for every one of you I've met in my career, I've met 200 who couldn't give a damn what a DTD is, let alone a pattern.

Design patterns are actually an excellent concept, but they won't really help programming for the masses. And, the more we depend on computing in our lives, the more we need programming as a technical discipline to be able to accomodate the masses. For every structural engineer out there in the real world there are probably a thousand architects. And for every architect, ten thousand carpenters. I know an expert carpenter and I'm pretty sure he couldn't calculate the tensile strength of a basswood 2x4, but he can sure build me a deck!

This article is complete garbage, and I'll tell you why. Being a competent programmer is about being good with logic, constructing a detailed mental model of a system in detail, and thinking across multiple abstraction layers. The problem is there is no litmus test for this. You can glean something from clever interview questions, or coding tests, but even other programmers won't know for sure until the person cranks out code for a while. The problem with using design pattern knowledge as some sort of test is that it's too high level. It's just some observations about things that tend to work in certain situations. But anyone can read about them and if they are moderately intelligent they can talk the talk even if they can't code their way out of a paper box.

My other problem with this article is that the author starts off sounds like he almost understands a bit about programming, but then he veers off unforgivably about the divine superiority of design patterns. "They are worked out for you and bestowed from on high by geniuses so much smarter than you that they solved all problems at once better than you will ever solve your specific problem, and therefore your code will automatically be better if you use them, and suck if you don't!" That's a ridiculous overstatement at best. Knowing design patterns is better than not knowing them, but only if you have the chops to apply them properly. If you don't then you may just be adding complexity without solving anything. Furthermore, design patterns are actually just an emergent property of working systems; just because you don't know what they're called doesn't mean you're not using them. To work with code, such as to make bug fixes, or to extend it you need to go to a much finer level of detail, and to make a large scale system you need to think about overall data flows that are far higher level than the design patterns used in individual components.

Design patterns are to programming as literary devices (allegory, simile, onomatopoeia) are to writing. If someone knows them you can tell they have studied literature, but it doesn't mean they can write worth a damn.

The article doesn't argue that knowledge of design patterns is what defines someone as a good programmer. It's just pointing out that very few programmers know enough about design patterns to be able to recognise the problems that they are intended to solve.

If someone knows what design patterns are then that's one piece of information to find out about them during interview and add to the overall picture of them.

I do agree that there is alot more to finding out if someone is a good programmer that one aspect such as design patterns.

Counterpoints to what you are saying:

Actually the okay but not so good programmers are more likely to be hung up on design patterns. They have learned few of them, and try to apply wherever they can, even when they really shouldn't. Aslo people that tend to do over-engineer a lot tend to overuse design patterns. Also you will see them in interviewees asking a lot more about design patterns themselves than actually coding/problem solving ability. It is is just a higher end version of asking "programming trivia".

To the risk of being downvoted, I repeat again: overuse of design patterns is a hallmark of mediocre programmers, or programmer that are not very experienced yet (they may become really good one day, but not there yet).

Cargo cult programmers are dangerous no matter whether they've been reading horrendous code or excellent code. If you try to build an airplane by copying a beautiful mansion you will still fail.

Agree. Actually design patterns are really good to apply at refactoring time. You often cannot foresee what problems you will be facing and how your code will evolve in order to start trying to stuff in all the patterns you are familiar with. Write code -> see a problem -> identify a possible pattern -> refactor accordingly. This is also learning design patterns by doing.

I've found that Anti-Patterns (http://en.wikipedia.org/wiki/Anti-pattern) are the best approach for refactoring. They explicitly start with recognizing a bad pattern (frequently one which once made sense but no longer does) and then explicitly prescribe methods to refactor them into something better.

Yeah, I agree with your overall point. In general, a sign of mediocrity in any field is someone who over-uses jargon in any field. As much as I hear people throw around "design pattern" terminology, I also see overkill on the now-en-vogue topic of "useability", with phrases such as "use case" being applied at any and every possible opportunity.

In fact, though, what has proven my comment wrong is that the HN community has not chimed in as I predicted. This is a(nother) really informative and thoughtful conversation... I love it here! :D

In my experience, few real-world problems fit neatly into one out of a handful predefined patterns. Having a few typical models to draw inspiration from when solving a problem is of course useful. Mindlessly applying a recipe without consideration of the unique aspects of an individual problem instance will inevitably lead to suboptimal or overly convoluted designs.

A skilled software engineer will recognise important aspects in a given situation and design a suitable solution based on similar situations (patters) without necessarily having a name for it.

Every attempt to formalise good engineering practices has met with a similar fate. Be it structured programming, design patters, agile development, or something else, they all fail when the chosen process is followed to the letter at any cost, no matter how absurd the consequences.

Something that bugs me about these articles is how the data is gathered:

"In the recruiting work I have done I've asked thousands of programmers to explain the concept behind design patterns"

I'd have to find some data to back up what I suspect, which is that the bottom X% of programmers (or at least would-be programmers) cycle through all those job interviews where this lack of knowledge becomes apparent (unless you're recruiting for a really high-level position where the top programmers might be interested in applying, and even then many are already content where they are).

So, if you're any good, you're not as likely to be interviewed, and so the population is flawed.

That doesn't mean that design patterns have or have not flopped. At least, every one of my coworkers have been taught the patterns. Whether we apply them or not might merit a study, one with a methodology that doesn't mislead the observer and where a more valid conclusion might be reached (it could even be the same conclusion, that is, that they have flopped).

Are you suggesting that great programmers tend not to have to go through the normal job seeking process, being interviewed etc, and therefore it tends to be the less competent programmers who end up having to go through interviews, and that these lower skilled programmers don't know design patterns?

The great programmers certainly go through fewer interviews, since they tend to get hired quicker. And then they have a job, so they don't do interviews anymore. It's the incompetent programmers who are more likely to show up because they're more likely to (a) be unemployed and (b) go through more interviews before finding a job.

Really?? That's some strong opinion, which I disagree with.

This old Joel Spolsky article gives an argument to why that is:

http://www.joelonsoftware.com/articles/FindingGreatDeveloper...

If you believe that good programmers are more likely to be offered a job than bad ones, it pretty much flows from that that bad programmers will be interviewing more. If that's so, then you are more likely to interview bad programmers. Statistically, on average, etc. Not in every case.

Perhaps true that some good and great programmers get snapped up by people who know them and never need to look at a job board.

It's not true in general however that good and great programmers don't have to go through the normal channels to find jobs. I encounter many extremely talented programmers who weren't just snapped up by their network of colleagues.

Even assuming great programmers do look at job boards and go through normal channels, they're more likely to get hired and stay employed, which still makes the numbers game work out like I described.

It would be more interesting to hear why you disagree. It seems fairly straightforward to me, though I probably appropriated the argument from Joel Spolsky as loumf points out.

Great programmers tend to have built up a network of people that would like to hire them or will recommend them.

Quite so, it should be intuitively obvious that this is the case.

design patterns are recurring patterns in code. you may not know how often you're solving problems in the same way, but patterns recur, even if they're not one of the classic big-white-algorithms-book ones.

just because you dont have a class called Factory in your code, doesn't mean you're not using one.

and finally, if your programmer doesnt know what design patterns are, do yourself a favor and tell them to learn at LEAST what they are. they'll find a use for them, guaranteed.

should i read GoF or SICP? What is more importend?

Mmmhh I think im going to spend more time on SICP and PAIP then on the Gof Book and more programmers should do that.

Unless you intend to or need to program in languages with weak abstraction facilities (i.e. C++ and Java) there's little need to read the GoF book. If you know Lisp (i.e. have done SICP) then reading the GoF book will result in a "Where's the beef?" reaction, at least if you're anything like me.

Well, it's been my (and many people seem to agree) experience that the design patterns -- at least from the GOF book -- are really only recurring patterns in inferior languages. C++, java, etc. In languages with better abstractions, most of their patterns are useless or trivial.

I'm not sure what the GOF book is, and while its been years since I was a c++ programmer, I'm pretty sure that design patterns are generally independent of language.

also, "inferior languages"? really? can you elaborate? I would also like to transcend beyond the petty squabbles of mere mortals and my .net/python existence.

GoF = "gang of four". The book has four authors. http://en.wikipedia.org/wiki/Design_Patterns I'm not sure if it's an intentional reference to the Gang of Four from the Chinese cultural revolution.

The GOF book codified design patterns. You should probably read it.

don't worry. I own it. I just call it by the author's names.

Sorry, I thought GOF was a common name for it.

I don't really have time to type out a long reply as to why C++/Java style design patterns don't occur in better languages, but I'd recommend putting some time in on lisp, ruby, or haskell. If you read idiomatic code in those languages, I think you'll understand my point.

Design patterns are not, and never will be "important field of computer science".

They're a neat-seeming idea with very little practical value because the real world doesn't fit into a small set of neat patterns, no matter how cute you name them. Overall, they do more harm (usually of the "golden hammer" variety) than good.

IMHO design patterns have been a great success because they have caused people to think about designs and suggested a vocabulary for discussing them.

Whether or not any specific world changing patterns have come out of the movement doesn't really matter to me. What matters is that the average blub programmer is just a little closer to understanding that classes are not just for modelling real world 'things'.

(I'm mostly an OOP programmer, assume something intelligent about functional programmers etc for me...)

The design patterns I care about are things like "use a template system to generate HTML", and "create RESTful APIs that respond to GET requests with a JSON representation of resources", and "write unobtrusive JavaScript". The same general concept as the boring old Gang of Four patterns (describe a problem and the pattern used to solve it), but at a much higher level.

The GoF book is one pattern language among many. They were concerned with OO design that is used in a class of programs they had experience with -- basically GUI programs with runtime extension, and with a bias towards programs that create documents/digital media. There are many other pattern languages -- I could imagine one for web development that had your three examples and others.

Design patterns are universal. You can't avoid using them. The more important question is whether there are core design patterns which can be used regularly to improve the quality of software design, and whether or not we have discovered such a set of core patterns. That question is still, for now, undecided. Some of the canonical patterns (from the GoF book, for example) are useful, some have limited utility, overall there's a good body of evidence that that particular selection of patterns is far from universally applicable in software development.

Not all patterns are equal. Of the GoF patterns, I'd say there are a few that are important to know: factory, observer, and visitor spring to mind. (Then there's the singleton pattern...)

Specifically, examine the singleton's usage pattern, and make sure it's not just a convenient excuse for a mud-ball of globals.

http://sites.google.com/site/steveyegge2/singleton-considere...

On a followup interview to the GoF, they were in favor of dropping Singleton:

http://www.informit.com/articles/printerfriendly.aspx?p=1404...

"When discussing which patterns to drop, we found that we still love them all. (Not really- I'm in favor of dropping Singleton. Its use is almost always a design smell.)"

Yep. The only justifiable use I've run across is internal bookkeeping in a class library across an API that doesn't provide space for context and you need lazy initialization.

My experience with design patterns has been that their usage can prevent people from considering the deeper issue of what it means for a design to be good. I would far rather work with programmers that have a good grasp of the five SOLID principles, for instance.

This is not to say that specific patterns are not of merit in the right circumstances, of course. Just that the notion of design patterns as some kind of shrink-wrapped, off-the-shelf, one-size-fits-all solution is something I find mildly alarming.

Hm. I've written 100's of thousands of lines of debugged deliverable code, and the number that matched a design pattern in a book was smallish.

Everything looks like a nail to a guy with a hammer.

If you read the post and substitute "design pattern" for "algorithm", it sounds quite reasonable. Design patterns are not algorithms though, they're more like language-specific templates. I don't think they deserve the crowning glory of being in every CS degree.

If you were recruiting new people into your development team, would you care about the potential employee's level of knowledge of design patterns?

I would probably want them to at least know what they are, and why they are relevant to a task (or not relevant).

If they'd mostly programmed in modern dynamic languages (Perl/Python/Ruby) I wouldn't expect them to know most of the individual patterns, since they're not terribly relevant for those languages.

I don't do much Python and Ruby. But when I did do Perl there were tons of design patterns.

And Javascript, another modern dynamic language, also has a lot of design patterns.

I find it hard to believe that not all languages have their own design patterns. Just different kinds for solving the types of problems they tend to run into more often.

I ask OO design questions. Experience with design patterns is fairly evident in answers to these questions, and sometimes that's good and sometimes it's bad.

The design patterns implemented by the authors of the API you are using are probably the most important (e.g. Key-Value-Observor in Cocoa).

This article seems a bit spammy, and doesn't appear to be written by someone who is a programmer.

Reply on news.ycombinator.com