Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
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!
Published at DZone with permission of Artur Karazniewicz . See the original article here.
Opinions expressed by DZone contributors are their own.