Ten years ago, one of my coworkers said “You have to read the ‘Design Patterns’ book! It’s awesome!” I bought the book. I got to page 10, and then I realized that it was a stupid boring waste of time. The “Design Patterns” give complicated names to simple ideas.
In advanced Mathematics, there’s an idea called “Category Theory”. When you do advanced algebra, there are lots of similarities among proofs in different areas. These common themes are grouped together as “Category Theory”. Category Theory is sort of neat, but ultimately useless. “Design Patterns” are like Category Theory. They group together some common themes, but are ultimately useless.
Here is an interesting post by someone else who doesn’t like Design Patterns.
At the time, I didn’t realize the difference between things popular due to hype, and things popular because they’re good. Just like node.js and Rails, “Design Patterns” is an idea with good hype, but not much merit. Unfortunately, there are a lot of clueless people who evaluate the hype and not the content.
The only time Design Patterns might be useful is if you’re on a huge project of 20+ people. However, for a complicated project, you will need more than just the boilerplate Design Patterns. Also, if you use Design Patterns, the number of classes and methods in your project increases. Even for a large project, the cost may outweigh the benefit.
It always is amusing when the head developer at a small startup acts like he’s managing a 50 person team. It’s amusing when they focus on tools that add bureaucratic overhead rather than getting things done. It’s disturbing to interview at some of these flaky startups. Are VCs really that eager to flush capital down the toilet? A VC probably can’t tell the difference between someone with good spin, and someone who has a good idea and the ability to execute.
For example, you could use one of the complicated factory patterns. Or, you can just make sure your objects are properly initialized and destroyed.
If you use the right Design Pattern, you can switch from MySQL to PostgreSQL, and you don’t have to rewrite all the other code! Really? How often do you switch databases? In the meantime, you’re bogging down your program with an extra layer of abstraction.
The “Design Patterns” create the illusion of productivity. You’re writing code that follows the Pattern, rather than your actual application logic. If you use a lot of fancy development methodologies with lots of overhead, that enables you to get the illusion of productivity when you have a large group of barely qualified fools.
It’s also a type of shibboleth. If you think design patterns are awesome, you have a certain personality type. If you think they’re a stupid waste of time, you have another personality type. A stupid hiring manager wants to hire clueless people who go along with the hype, rather than people who think for themselves.
When I go on an interview, and I’m asked a “Design Pattern” question, I mentally translate to the interviewer saying “I’m a stupid retard.” I’m polite anyway. I noticed that the more clueless interviewers ask “Design Patterns” questions. Working for fools isn’t worth it, so I don’t mind being rejected because I don’t know the Design Pattern that answers the question.
“Design Patterns” and “We want MVC experience.” are examples of stupid ideas polluting the software engineering profession. Unfortunately, I’m noticing more and more interviewers asking stupid irrelevant questions. It isn’t enough to be a programmer. I also have to be an expert in their inefficient way of writing software. Those fancy ideas exist to enable mediocre people to pretend they’re getting stuff done. In my experience, those tricks add more overhead without enabling you to do the real work.