Why You Must Use Design Patterns

I’ve heard a number of novice/junior developers ask me this question over & over again, it’s quite comical in a sense & in all fairness there was a time where I thought maybe it’s overkill to use a factory over a simple switch statement or something like that. Anyhow, to summaries, coding is much like cooking, sure, you can code something simple that pretty much anyone that has the ability to type can code. Much like a cheese toastie, I’m no chef by any means, I’m a terrible cook, but that’s fine, I have little-no interest in cooking. Anyway, design patterns are much like recipes, when you follow a recipe it’s hard to go wrong, even if you do suck at cooking, often the only time you can mess up when using a recipe is if you’ve not followed it correctly or the recipe itself is too vague.

The same applies to code, when you use a series of design patterns, ultimately producing elegant, scalable, testable & good quality code, it’s like serving up a dish from a Michelin star chef. It’s just fantastic, it can be considered as a well established fact that the code produced is fantastic. But still, like cooking, you don’t want to over complicate things, again, thinking about a cheese toastie, you wouldn’t want to add a ton of seasoning & fresh ingredients, it’s a cheese toastie at the end of the day, why try to fix something that isn’t broken? Sure, by all means feel free to experiment, but don’t try to serve your customers these overly engineered dishes, that’s not what people want in a simple cheese toastie.

I’m not sure why software developers & engineers struggle with this, in my experience there’s been a few engineers that I’ve had the luxury to work with where they’ve found that fine balance, but there’s been a lot of engineers that are one end of the spectrum. They either try to over simplify something that should have more ingredients to get the most out of their dish. Then there are those that add too much & just ruin something that’s wholesome, simple & classic.

Again, I’m no exception to this, I’ve fallen into both traps, there was a time where I used to think how you could break everything down & make it all super lightweight & super simple. Queue my experience within the enterprise ecosystem; I soon learned that this isn’t always possible & it isn’t always the best approach by any means. Much like cooking, you really need to think about what you’re developing, if it is a simple front end web application, you should wonder if it is worth using Angular or React or whatever, would that just ultimately be adding bloat? How many developers will be working on this project? Will this project be served to one or two internal users or will it be served to the multi-millions of users? By using well educated analysis & design you can essentially ensure that the technical product that you deliver meets all of the requirements.

Much like recipes that are tried & tested, engineers like myself don’t just advise people to follow patterns for the sake of it or because we have a weird nerdy obsession. Rather, it’s because these patterns are tried & tested & thanks to the engineers before myself we can confirm that they work, they’re scalable, etc. The same rule of thumb applies to all aspects of IT, not just software engineering, but this rule can also be applied to infrastructure, security, etc.

So if you were like myself as a junior & you think you know better, yes I did have that toxic mentality a while back, think again. Learn from my mistakes please!!! 😂