Most programmers follow a similar development path. Introductory material leads to more advanced material, a new programmer might start with learning types and conditional statements, then move on to data structures and algorithms. Eventually most programmers are confronted with Design Patterns, the promise - the promise that “everything is a pattern”. And, while Patterns are important, they are not a panacea. In fact, when I sense that people are trying to over apply patterns it reminds of my 15-month old daughter learning shapes. She picks up a square peg and tries to jam it into a round hole, when this doesn’t work she gets a little frustrated, and when that doesn’t work she redoubles her effort until her attention drifts to something else (like Curious George).

Design Patterns: Powerful, Essential, (and Dangerous)

“We use patterns” is not a shibboleth for success. When a new programmer starts to get interested in patterns, I tend to have a mixed reaction. On the one hand, patterns are an important part of engineering any large system. If you are implementing anything with more than a few thousand lines of code, a working knowledge of patterns is a prerequisite; it is convenient to tell someone that this particular system uses an AbstractFactory or the Command pattern. Alternatively, I’ve also seen a number of systems that either overapplied or abused patterns by applying them when they were not appropriate, confusing one pattern with another, or just getting a pattern wrong. (…umm..someone must have read the book backwards because this is definitely not MVC.)

In my own experience, I ran for design patterns at the same time I was infatuated by UML. In 1999, patterns supplied the language I needed to take that next step to understanding larger systems, and my office walls were plastered with man-sized static structure UML diagrams. Patterns + UML made it easy to visualize and communicate, but I found that approaching problems with patterns in mind tended to affect the solution. Subconciously, I would think of some way to apply a “pattern” to the problem. (And, then, all of a sudden everything was an AbstractFactory…) Patterns appeal to the idea that one can escape the day to day frustrations of programming by capturing abstract structures which can be universally applied. All the books about patterns appeal to this ideal, and they tend to play upon Patterns as a pancea or Patterns as a common language. (Patterns as Esperanto.)

Read more…

Preconceived Notions: Doctors and Programmers

What Pattern sales people don’t tell you is that, with the promise comes a challenge. If you approach every problem assuming that it fits a common structure, it will shape your solution. If you enter the room thinking that this project should be solved with an AbstractFactory, the Memento, and a FlyWeight, than there’s a good chance that you won’t really listen to the patient. Think of a Doctor reviewing a patient chart just before she enters the room to ask about symptoms. This Doctor could very well make a diagnosis of Influenza based on temperature and the symptoms as recorded by the admitting nurse. But, she doesn’t, and if she’s a good doctor, she’ll walk into the room, try to forget the patient chart, ask questions, and actually listen to what the patient has to say. Sure, once the patient confirms her suspicions, she can reuse the patterns she knows about, but often our experience with medical professionals is the opposite. Here’s how it usually works (in both IT departments an hospitals):


Patient

Customer

Patient presents common symptoms.

Customer requests an application change.

Admitting nurse takes preliminary measurements and records initial symptoms.

Customer calls you and you have a brief conversation about a requirement. “We need to parse market data”

Nurse communicates with Doctor, they agree that the patient has influenza virus.

You start sketching out the system, maybe you implement a bit of it before the initial meeting

Doctor makes a cursory visit to the Patient, doesn’t make much eye contact, half-listens to patient concerns, is somewhat dismissive when patient mentions a symptom that isn’t consistent with influenza.

At the client meeting, the client presents a set of requirements, you half listen knowing that the system fits few common patterns and doesn’t require a great deal of analysis. You fail to appreciate some of the details that differentiate this customer’s business from the competition.

Patient doesn’t feel listened to, and subsequently receives a bill for $3000 because his insurance is terrible. And, it turns out that he had something a bit more serious than influenza.

You deliver a system that doesn’t wholly satisfy the requirements because you tried to make the customer’s problem fit the solution you had in mind. The Customer begrudgingly pays your invoice, but you couldn’t really consider the engagement a “success”.

Patterns are a valuable tool, but they can also distract you from gathering objective requirements and focusing on important details that don’t fit your models.

Engineering: You (almost) only learn from complete failure..

Seeing problems domains solely through the lens of patterns leads to some heavy systems. And, from what I see, Pattern-lust is a common malady in many corporations guilty of over-engineering. After 2000, I suffered both Design Pattern and UML burn-out - I no longer go near tools like Rational Rose if I don’t need to, and when someone asks me to write code, I don’t start with the GoF book. I still use both, I draw the occasional UML diagram if it is warranted, and I’ll still throw around Patterns names when discussing architecture. But, I’ve learned that “everything is pattern” usually translates to over-engineering, and that if you focus too much on patterns as an end and not a means to an end that they have an insidious way of creeping into every bit of your code.

Like most things I blog about, the thesis is: “Patterns are a great tool, but they can be misused as easily as anything else. Failure awaits the foolish.”

When a new programmer asks me about patterns, I know that while it is important to know about patterns it also means that they have to learn about the over-application of patterns by following a similar “arc” of failure. But, such is my view on just about every topic relating to software development, developers progress by learning from their own failures not the failures of others. (This could also mean that I’ve read too much Petroski.)