Agile Zone is brought to you in partnership with:

I'm a software developer particularly invested in REST and distributed systems, service oriented architecture, and software architecture in general. I work and live with my family in Poland. Artur has posted 2 posts at DZone. View Full User Profile

Patterns Antipattern

07.12.2010
| 5530 views |
  • submit to reddit

In late nineties I started my career in software development. This was roughly few days since I started my second gig. In a Bank. After initial hoopla I finally tackled my new SUN  Ultra 5 pizza boxed workstation, CDE and all that bleeding edge stuff like CVS and gcc. I was ready and excited to start my next journey, dive into muddy waters of bits we were working on. Oh boy that was freaking great feeling. Me working on a critical online banking system, could You believe? Me… erm… completely green. Me, the novice.

Eagle was a senior developer. Not a formal leader, just guy keeping development going, knowing all dark nooks of our app, build scripts and interfaces; all stuff. A go-to fellow. He was proud owner of SUN Ultra 10, with whole gig of RAM, and he always built the final release of the system. Because his workstation was, pretty much, the only one capable enough to build whole system within less than half a day. He was a gate keeper and an expert.

Eagle didn’t talk much. He rather showed in his cubicle early morning, typed with the speed of machine gun and bah! Next feature ready. We, all the greenhorns, pulled his new stuff from CVS immediately and tried understand all that brilliantly esoteric bits. He was the only guy who actually actively used all cast types in C++: dynamic, reinterpret, static and const casts. And he understood the difference. He was probably the only person who understood this on planet Earth (OK, maybe Bjarne Stroustrup knew this stuff, too, however I’ve never talked to him, so I’m not sure:). Huh! That was mastery. Truly. And this was how Eagle had communicated with the rest of the world. Through the stuff he was working on; the code. He checked bits into repository, we pulled it and tried to understand. A communication loop. Or stream, strictly speaking. Because there was no feedback back-channel closing the loop. Eagle didn’t care much about our code, granted we followed his ideas and style. And we followed.

One day our manager popped in and communicated we have to start working on a brand new module. And we started. We formed small team: Eagle, Paw – a competent fellow developer, and me – the novice guy. Next day Eagle showed up, and he didn’t start coding immediately, as he usually had used to. He stared at me for a while, came to my cubicle and put white, a little bit fatigued paper brick on my desk. A book with friendly, blue letters: “Design Patterns: elements of reusable object-oriented software”. And he went back to his Ultra 10, and started typing. After few seconds I got e-mail: “We gonna use Design Patterns in this new module. Read this book. Regards. Eagle”. Holly! Eagle emailed me. Can You believe? And we gonna use Design Patterns, ain’t this cool?! ‘Design Patterns’…Wait! ‘Design’ what? What the hell are ‘design patterns’? And remember this was in late nineties, the prehistory. No google search, no wikipedia and all this usual stuff we are so used to nowadays. My altavista search didn’t cut it; neither my experience from university days. Nothing. “This must be even more esoteric stuff than all that C++ casts we used”. I thought.

This afternoon I brought “Design Patterns” book with me and started reading. Indeed, this was more esoteric than all this ‘C++ casts’ stuff. Lots of high-level ideas, with names, in the form of ready-made recipes. And all that taxonomy (and Yes, I looked up paper dictionary to discover what ‘taxonomy’ actually meant. Remember, no google search back then). Lots of examples in Smalltalk. Wow! Smalltalk! I’d used Smalltalk during one of my university courses. Wrote few trivial, hello-world size projects. Didn’t even know somebody used this stuff in real-life. Huh! Those GoF guys must be smart, they use Smalltalk! And Eagle asked me digest this book. Cool! Two days later I was speaking patterns. Ha! Design patterns. I’ve seen patterns everywhere and was ready to put this stuff into my code. I was wondering how the hell I survived without patterns actually.

Next day we gathered: Eagle, Paw – a competent fellow developer, and me – now design patterns guy. Design patterns and… still novice. Anyhow. We brainstormed our high level design, full of patterns. The only guy who had a problem with all those patterns was… Paw. Meh! Eagle and me voted for patterns, Paw was against. But eventually all that Paw’s ‘Why?’ annoying questions were refused. Didn’t he know GoF guys are smart, so we were, using their patterns, huh?! Boring. Eagle took final decision. Use design patterns. Period. Paw went away with his opinion in his mind, anyhow.

We started coding brand new module. Full of patterns. We built beautiful architecture with all possible levels of abstraction. We created every single object with Builders. We glue stuff with Bridges and Delegates. We implemented business logic with Chain of Responsibility. We built SQL queries with Visitors. We implemented security with Proxies. Everything with grain of Singletons and MVC. Just to name few patterns. You know… all this smart stuff. Let me rephrase: all this smart stuff. Literally. We actually worked two months more than expected and produced half the code whole system had so far. But who cared? We did great stuff, right? At least I was proud of this.

Few months later Eagle left company, and me and Paw eventually ended up with this design patters legacy. Alone.

Fast forward. Quite few brand new modules later… Now, I walk Eagle’s shoes.  I’m the expert. I’m go-to guy. I even understand all C++ cast types. Huh! And I drive all development, including our shiny design patterns sandbox. Still have to support it. But guess what? It’s the worst module in whole system. Seriously. How come? Somebody did something wrong in the meantime? Somebody has broken beautiful architecture? Sneaked some wrong ideas?… Antipatterns? Nope. Nobody even wanted to touch it because every single change took literally weeks. Almost nothing changed since its inception. So what happened, then? Nothing. It’s actually the same, original module we wrote few years ago. Untouched. Oh…wait… there were quite a few workarounds carefully bypassing this stuff. It stayed in its own vacuum.

It was quite few Years, and few gigs ago, in the middle of all that Patterns mumbo-jumbo. Some Patterns became antipatterns since then. And we eventually drank our cool aid. But guess what? I like this story. It taught me more than all Patterns books I have read. I learned that patterns, without enough care, might become harmful. Astonishingly harmful. Even more astonishingly harmful without proper communication and reasoning. It’s what I call a Patterns Antipattern. What this story all about: blindly followed ideas, just because someone smart wrote a book about them. And someone had wild idea to check if all this stuff work together. And won’t implode. And someone else followed. Do not try this at work. Avoid Patterns Antipattern.

So… be the Paw, not the Eagle! Challenge ideas. Don’t drink cool aid without asking questions. Paw, thanks for the lesson, pal!

References
Published at DZone with permission of its author, Artur Karazniewicz. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Philopator Ptolemy replied on Mon, 2010/07/12 - 7:53am

Great story.

I can also witness how absurdly people try to apply patters just because it's the way to build software.

I know of a team that was tasked with building a medium size JSF app (other frameworks were not an option due to Bank standard). So, one of the developers felt that his 5 years experience in software industry and a book about Core J2EE Patterns are sufficient proof needed to try to force as many of J2EE patterns as possible into the application.

He proposed to implement Front Controller, View Helper, Business Delegate, and few more (i don't remember exactly which) ON TOP OF JSF. Why - because that's the right way to build Web apps in Java.

Luckily few team members were sober enough to convice him that all those patterns are already implemented by the JSF itself and implementing them from scratch would be crazy. (The app was indeed completed simple and fast without any of those).

The funny part of all this is not that ONE developer was infected with this pattern-itis, but how captivated many other people including management became when he was describing the absolute necessity to use those patterns.

 

 

Paul W. Homer replied on Mon, 2010/07/12 - 10:36am

I've seen this a few times too. Design patterns are supposed to be used as an initial "pattern" for architecting the code. If you treat them as literal building blocks, the complexity from that perspective overwelms the design and the patterns have a negative inffluence.

You shouldn't have any classes named Singleton or Proxy for instance. The class is named for what it truely is (usually a noun), and both the Singleton and Proxy patterns might been combined to contribute ideas into the initial version. Design Patterns are not building blocks, they are not mean to be taken literally and they are definitely not carved in stone. Abuse at your own risk.

Andy Pemberton replied on Mon, 2010/07/12 - 4:18pm

I agree and wrote a similar post on the topic a while ago:

My argument is that the cost of the additional layer of 'pattern' code should be outweighed by the value the pattern delivers; further, you must evaluate the value when implementing any pattern.

- http://blogs.captechconsulting.com/blog/andy-pemberton/knowing-when-apply-design-pattern

Chris Lovett replied on Fri, 2010/07/16 - 3:28am

Love your story. I've often thought design patterns were clever, but a toy when compared to reality. I think in real systems we use thousands of different patterns and morph them and hybridize them as we go. Building real software out of a few toy patterns is like building a Lamborghini out of lego. I think what we really need then are ways to dynamically discover the patterns we care about at a given moment, I think of it as "data mining the code". Then interesting ways to visualize that to make the patterns really pop out so the are crystal clear for the new dev who joins the team and picks up where someone else left off.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.