“When all you do is hammer, everything looks like a nail.” That’s probably true, but I think there’s a second, more frequent cause of mistaking non-nail objects for nails. That cause is having a really really new, really really shiny hammer.
Have you ever seen a little kid with a new toy? Their parents want to take them to the swimming pool, but they want to bring their stuffed llama’s newest plastic hat. Why? Because it’s the newest, shiniest object that they have. They don’t want to be far from it! They might need it! They are, going back to hammers for a second, willing to assume that a random collection of unseen objects is likely to contain nails.
Adults do this too. As soon as I get a new phone, I try to use it to update my blog, or use it as a shopping list, or use it to play Minecraft, or whatever. There are even Android apps for writing code! On a little tiny touchscreen! Nothing happened that broke the little scraps of paper I used for shopping lists; nothing happened to my web browser or my big, fast computer that plays Minecraft just fine. I was excited to have a new toy, so I started using it for everything, even for things for which it is fundamentally unsuited.
Here’s a sad story about design patterns:
The other day, I caught a bad case of object happiness. Object happiness is a disease befalling new programmers that causes them to them to make more objects, more design patterns, and generally more code than is needed. I thought I saw a good place to use a strategy pattern, and I was off and running. Boom! Before you knew it there were strategy factories and strategies all over this little piece of our app. More abstract base classes! Turns out that was a bad idea.
Why? Because abstract base classes are hard to read.
I was over-engineering. I was asking whatever poor dev was going to read this code next to figure out what “ControlMapperStrategyFactory” did. In other words, I was using elaborate design features to solve a problem that could have been solved with four or five stupid, read-straight-down, does-what-it-says-on-the-tin methods. Someone should’ve slapped me.
I think the reason that I ended up over-engineering this poor little corner of our application so much is that the design patterns bouncing around in my brain were my newest, shiniest hammer. I was so excited that I understood the strategy pattern! I felt like I had come across a textbook example of when to use this pattern, and use it I did!
But I had forgotten software’s primary imperative: managing complexity. I was making a simple problem (CRUD app on a website) into a complicated problem (inheritance, two different design patterns, virtual methods, the works.) I was so excited to have a shiny new hammer that I forgot to ask myself whether this thing was a nail. The first rule of programming is to write the simplest program that will work. There are some problems that are inherently complicated, where having some strategies somewhere, in order to separate the logic for selecting which process to use from the logic of performing that process, is really necessary. I just hadn’t found one that day.
So the next time you’re reading your favorite programming book or programming blog, and you learn about something so cool you’ll have to try it, please take a moment to verify your target is a nail before swinging your newest, shiniest hammer. You’ll save yourself some time.
Till next week, happy learning,