Not long ago, a young colleague tweeted the cover of a book she’d just purchased. You may have heard of it: “Design Patterns: Elements of Reusable Object-Oriented Software,” by Erich Gamma, Richard Helm, Ralph Johnson and the late John Vlissides. The book is one of the true landmark development texts of the past 20 years, to the point where “The Gang of Four book” can now be generally referred to by simply saying “GoF.”

I was dismayed by some of the reactions to her tweet; while there were several “Oh yeah!” responses, there was another vein of responses that lamented her choice. This was not an isolated incident, either: Most public discussions of design patterns will now bring up skeptical, even hostile, viewpoints. What’s going on?

First, a bit of history. In the early 1990s, object-orientation was sweeping like a wildfire into the world of software development, largely in the form of C++, but also with a flurry of interest in object-oriented Pascal variants like Delphi, the “pure OOP” language of Smalltalk, and short-lived but very interesting alternatives like Actor. At the same time, people had to deal with the sudden demand for GUI applications (similar to the current explosion in demand for mobile). But vocabulary, both in terms of text and graphical notation, was a huge challenge: Some people said “instance,” some said “object,” some said “function,” some said “method.” Graphically, you could choose among Booch, Constantine, Rumbaugh, Page-Jones, and probably half a dozen I no longer remember.

Meanwhile, there was a belief (perhaps more of a wish) that many hard problems of application complexity would go away by “emergent” behavior that would grow from simple-to-write small objects. That belief was bolstered by the writings of Christopher Alexander, a Berkeley-based architect and academic, whose books, starting with “The Timeless Way of Building” and “A Pattern Language: Towns, Buildings, Construction,” advocated physical architecture acknowledging the “wisdom of the user,” which he based on observing successful communities. The software community seized on Alexander’s ideas, particularly the idea of so-called “generative patterns” that could be used to produce solutions to concrete design problems.

It’s worth pointing out that “It was not the intent [for “Design Patterns”] to be a prescriptive or generative guide,” as the authors told me in an interview I did with them in 2009. The Gang of Four book was never intended to fulfill Alexander’s definition of a “pattern language,” and one frustration I’ve heard from critics of design patterns is that Alexander’s worthy ambitions may have been thwarted by nearly 20 years of people taking the GoF book as a complete and final whole.

Those of us who have done consulting know that it’s not uncommon to see a codebase that shows what I’ve called “an explosion at the design pattern factory.” These aren’t good architectures or module designs: They’re bad. And to the extent that bad designers can avoid hard thought and responsibility for their decisions by hiding behind the label “design patterns,” I agree that there’s a problem.

Another criticism for which I have great sympathy is that, not only do some developers think there are only 23 GoF patterns, but some of these same developers also feel that implementations of the patterns can be cut-and-pasted and result in a well-designed application. In 2006, Mark Dominus wrote a post that argued, “[P]atterns should be used as signposts to the failures of the programming language.” If there’s a design challenge and it occurs over and over, perhaps instead of being satisfied with applying a pattern, one should consider switching one’s tool set. This is a fair point, and Dominus’ point that “Patterns that are used recurringly in one language may be invisible or trivial in a different language” is absolutely true. (He points out that Iterator, for instance, reveals more about the state of C++ in the early 1990s than anything else.)

One criticism for which I have no patience is the claim that certain languages or paradigms “don’t need design patterns.” For one thing, it’s just not true, since there are always design challenges. For another thing, to the extent that common solutions are not passed around and perhaps codified in some consistent manner, that’s a failure of a language community, not a triumph.

For me, the benefits of design and architectural patterns have far outweighed any drawbacks. Patterns fill a tremendously important middle ground between language idioms and general software principles. Are they “timeless”? Of course not. Software is still in its infancy, and we are only beginning to have the vaguest idea of its guiding principles. Perhaps every design pattern should be given a “Best used by” date.

In the mid-1990s, talking to other developers about object-oriented design became tremendously easier in the wake of the Gang of Four book; the partnership of the “Three Amigos” (Grady Booch, Ivar Jacobson and James Rumbaugh), which led to what became the Unified Modeling Language; and a convergence on terminology. The GoF book is occasionally out-of-date, incomplete, and lacking insight into modern tools, techniques and design challenges. But it was never intended to be the final word, rather the opening statement. The software development world would benefit from fresh perspectives on patterns, taking Alexander and GoF for inspiration. Perhaps my young colleague will be one of those voices. I certainly hope so.

Larry O’Brien is a developer evangelist/advocate for Xamarin. Read his blog at www.knowing.net.