I was at a jazz jam session a few years back. I didn’t know it then – but I was learning a valuable lesson about design patterns.
Music, in its similarity to software, has a class of design patterns called scales (think Sound of Music – “doe re mi fa so..”). Scales help musicians to have an intuitive understanding of the harmonic relationships between different pitches. These relationships have mathematical connections that lead to a lot of simplification and a lot of carrying lessons learned in one context to another context. There is a lot of value in deeply thinking about these relationships, and getting them “under your fingers” – getting an intuitive feeling for them by playing them.
The jazz solo is an interesting thing – it’s a time for a musician to attempt to convey feeling to the listeners, following as few rules as possible. Though there are a lot of underlying laws to how to create certain feels….most musicians, in order to be able to express feeling in real-time, work hard to have an intuitive grasp of these laws. Thinking through the specific details of the performance while performing would be impractical, and it would destroy the original inspiration. Hence, musicians have located patterns (such as scales) – that allow them to work on that grasp when not performing.
After stepping down from my solo (which was undoubtedly life-changing for the audience) … another soloist took the stage. He played scales. For the whole solo.
A fellow listener leaned over and whispered in my ear about the ineffectiveness of the approach….in more colorful language.
Scales…..like design patterns in any domain are for developing intuitive understanding of the space. They are NOT to be included for their own sake, thoughtlessly in the actual creation.
I’ve seen this a couple of times, at grand-scale, in software. In the early 2000’s – I can’t remember how many singletons I saw cropping up all over the place (yeah, I may have been responsible for a few of those)…many, many times very unnecessarily.
These days there are a number of patterns that get picked up and used wholesale (with little thought) – MVC, Monad, Lambda, Onion, etc.. This is not how great software is written. Like music – the domain has to be well-understood, and then the thing created from that understanding. Picking up the design patterns, whether they’re scales or singletons, and instead of using them in private to gain understanding, we pass them off as creation, we are using them in exactly the most wrong (and harmful) way.
It will make our software worse – decreasing our understanding, and increasing the complexity of our software by creating code that doesn’t match the problem.
I have to conditionally and respectfully disagree – mostly with the title of the article, but to a lesser extent with the sentiment. I think your editor might have fallen victim to click-baiting, but I won’t hold it against him/her. 😉 Software Patterns as I understand them are really just micro-architectures. Solid software architectures have architecture considerations at every level, including at the level of the individual class / object or small groups of collaborating classes. Some well-known patterns are so pervasive that they effectively “disappear” into everyday use. The Decorator pattern in java.io comes to mind. Spring beans are Singletons by default. In my experience, it is possible to misuse general purpose patterns, but it’s difficult. If the problem doesn’t match the pattern’s intent, you will be swimming upstream the entire time you try to implement it. That’s the obvious sign that you’re misunderstanding something. That’s how we learn and get better at this craft. The software patterns movement brought with it a new way to think about software design that has had a profound effect. It seems disingenuous to say it sucks.
That guy – I gotta keep a closer eye on him………and yeah, I agree with everything you say here – disappearing into everyday use and swimming upstream in the face of mismatched requirements especially.