TITLE: Why Patterns Failed and Why You Should Care
AUTHOR: Eugene Wallingford
DATE: October 05, 2018 3:39 PM
DESC:
-----
BODY:
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.
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.
Those two nearly-sequential paragraphs are from
Patterns Failed. Why? Should We Care?,
a talk Brian Marick gave at
Deconstruct 2017.
It's a good talk. Marick's provocative claim that, as an idea,
software patterns failed is various degrees of true and false
depending on how you define 'patterns' and 'failed'. It's hard
to declare the idea an absolute failure, because a lot of
software developers and UI designers use patterns to good effect
as a part of their work every day. But I agree with Brian that
software patterns failed to live up to their promise or to the
goals of the programmers who worked so hard to introduce
Christopher Alexander's work to the software community. I agree,
too, that the software pattern community's inability to document
and share patterns at the granularity that made Alexander's
patterns so irresistible is a big part of why.
I was a second- or third-generation member of the patterns
community, joining in after Design Patterns had been
published and, like Marick, I worked mostly on the periphery.
Early on I wrote patterns that related to my knowledge-based
systems work. Much of my pattern-writing, though, was at the
level of elementary patterns, the patterns that novice programmers
learn when they are first learning to program. Even at that
level, the most useful patterns often were ones that operated up
one level from the building blocks that novices knew.
Consider
Guarded Linear Search,
from the Loop Patterns paper that Owen Astrachan and I
workshopped at
PLoP 1998.
It helps beginners learn how to arrange a loop and an if
statement in a way that achieves a goal. Students in my beginning
courses often commented how patterns like this one helped them
write programs because, while they understood if
statements and for statements and while
statements, they didn't always know what to do with them
when facing a programming task. At that most elementary level,
the Guarded Linear Search pattern was a pleasing -- and useful --
whole.
That said, there aren't many "solved problems" for beginners, so
we often wrote patterns that dropped down to the level of building
blocks simply to help novices learn basic constructs. Some of the
Loop Patterns paper does that, as does Joe Bergin's
Patterns for Selection.
But work in the elementary patterns community would have been much
more valuable, and potentially had more effect, if we had thought
harder about how to find and document patterns at the level of
Alexander's patterns.
Perhaps the patterns sub-community in which I've worked in which
best achieved its goals was the
pedagogical patterns
community. These are not software patterns but rather patterns
of teaching techniques. They document solutions to problems that
teachers face every day. I think I'd be willing to argue that
the primary source of pedagogical patterns' effectiveness is that
these solutions combine more primitive building blocks (delivery
techniques, feedback techniques, interaction techniques) in a way
that make learning and instruction both more effective and more
fun. As a result, they captured a lot of teachers' interest.
I think that Marick's diagnosis also points out the error in a
common criticism of software patterns. Over the years, we often
heard folks say that software patterns existed only because people
used horrible languages like C++ and Java. In a more powerful
language, any purported pattern would be implemented as a language
primitive or could be made a primitive by writing a macro.
But this misses the point of Alexander's insight. The problem in
software development isn't with inheritance and message passing
and loops, just as the problem in architecture isn't with beds and
windows and space. It's with finding ways to arrange these
building blocks in a way that's comfortable and nice and, to use
Alexander's term, "life-giving". That challenge exists in all
programming languages.
Finally, you probably won't be surprised to learn that I agree with
Marick that we should all care that software patterns failed to
live up to their promise. Making software is fun, but it's also
challenging. Alexander's idea of a pattern language is one way
that we might help programmers do their jobs better, enjoy their
jobs more, and produce software that is both functional and habitable.
The first pass was a worthy effort, and a second pass, informed by
the lessons of the first, might get us closer to the goal.
Thanks to Brian for giving this talk and to the folks at Deconstruct
for posting it online. Go watch it.
-----