Why Patterns Suck

Tags

design, emergent design, software, Software Craftsmanship

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.

 

 

The ONE Lie Your Computer Science Professor Wouldn’t Stop Telling You.

Tags

code, design, OOD, OOP

What is this lie?  It’s not subtle – and in fact like any great deception – it has been doubled-down on over and over again.  So much so, that it’s actually carried around as if it were the DEFINITION of truth – the one true way to design software. And like many of the most successful lies throughout history – it seems viable, even helpful in the short term but carries with it long-term, bad consequences.

What if I told you – everything you’ve been told about OOP is a lie.

The lie goes something like this “The purpose of an object is to encapsulate data behind behavior”.  The idea is that we expose the things we want to do, and then implicitly have some backing information with which we accomplish those things.

As with any good lie – it starts with a kernel of truth – viz. yes, exposing only one thing is important, so you shouldn’t expose data if you are going to expose behavior.  The lie begins with the idea, that the object, a single object, embodies both.

At a bare minimum, this will always represent a violation of SRP.  No matter how closely related, specific behavior and any data that are related to that behavior represent two reasons to change, and thus two “Responsibilities” in the SRP sense.

So to say this again generally, the old wisdom about the purpose of Objects being to hide data behind behavior, especially its implication that this means the same object does both, is a violation of SRP, and is actually more like an OO anti-pattern.

Why should you care?

For all the reasons you’d care about following SOLID principles in the first place.  Violating them means that your code will be less adaptable, and communicate its intent less clearly.  I’ve personally seen plenty of code that blindly follows this common wisdom – and it bares out the fact that adhering to this lie does us no favors.

But Morpheus’ approach to sharing deep truths like this is very applicable – as with SOLID generally, or TDD, or Agile Principles – one cannot really be told about the matrix – one must see it first hand.  So – I would challenge you – find some code that follows the one-object-hides-data-with-behavior anti-pattern.  Imagine modeling it, or even try modeling it in a way that separates out the responsibilities, and see if you don’t end up with clearer, cleaner, more flexible code.

-Kyle

The Craft of the First Creation

Tags

design, Unit Test

Jobs aimed for the simplicity that comes from conquering, rather than merely ignoring, complexity. Achieving this depth of simplicity, he realized, would produce a machine that felt as if it deferred to users in a friendly way, rather than challenging them. “It takes a lot of hard work,” he said, “to make something simple, to truly understand the underlying challenges and come up with elegant solutions.
Walter Isaacson

---

Stephen Covey, in his uber-important “The Seven Habits of Highly Effective People” lays out a general principle that is as true in Software Development as it is in any other craft. The principle I’m referring to is that of the “First Creation”. You always create a thing twice. The first time, you create it in your mind, the second time you create it out in the world.

This principle is one that is very poorly understood by software developers. The reason that it is poorly understood is likely due to the lack of friction that exists between our ideas and and getting a representation (however crude) out into the real world. That is – with minimal explicit thought we can start typing into our ide – and get the Hello World version of whatever we have in mind to create in very short order.

We’ve all seen this – she sits down and immediately is able to accomplish things without really thinking things through. Though in her defense – there were man-eating dinosaurs after her.

And really – isn’t that how we love to start working on a project – we take pride in being able to sit down at a computer and start typing – and magically things begin to work. Not only do we love the praise and the instant gratification that comes from this – even on our favorite movies and TV Shows, this is how computer work happens. And of course – it’s really the obvious way to begin when we first learn to code.

So what we end up doing is a very quick, very intuitive “First Creation” – and then riding off like Code Cowboys into the sunset, sure that we’ll save the world.

Problems…

There’s a problem that comes from this though. A quick, intuitive first creation gives us only an intuitive, vague understanding of the problem space. If we haven’t explicitly thought through all the road bumps we are likely to run into – we will only have a gut feel for them.

Intuition is a powerful thing – and our ability to solve problems without a complete understanding of them is one of the things that is really cool about being a Human. However – though you CAN solve a problem without understanding it entirely does not mean that you will solve it in a particularly good way.

Practically speaking – if you don’t spend some time *explicitly* thinking through a “First Creation” – you will invariable start coding like crazy only to run into many, many decisions to make that catch you by surprise. You will be able to solve them – but because you didn’t think clearly through things to begin with – the decisions will undoubtedly compromise your structural vision (which again, you’ve made implicitly).

The end result is – you end up with code rot long before you even get anything into production.

The State of Things…

Is the world going to end if you don’t put in the effort to perform a “First Creation”. No.

Will you limit your craft and fall short of your potential. Yes.

The systems you write DESERVE to be elegant, well-crafted works of art that not only perform the function for which they were created but also clearly communicate your intent to the developer that comes after you. Even if that developer is you – don’t you want to inherit elegant, well-structured code that takes minimal effort to understand?

Or if you like thinking in terms of negatives – the warning I’ve always heard is – Code like the developer that is going to follow you is a murderous madman that knows your address.

The Solution…

Part I

So how do we do this first creation? Am I suggesting months of documents and powerpoints to ensure we have exactly the right thing before we begin to code – NO!!! IN NO WAY AM I SUGGESTING B.U.F.D. (Big Up Front Design).

What I am suggesting is explicit forethought – I usually do this with some scratch paper and a pen – or with the ubiquitous white-board. Write out an object model – ensure that your objects are abiding by SOLID principles – and think through all the interactions until you feel you are comfortable and have a handle on everything within the scope of what you are building. Then start to decompose … then, and ONLY THEN – Code.

This could take minutes – or it could take a couple of days – but every developer involved in actually writing code should be comfortable with things prior to coding. Will it change along the way – certainly. Should you be explicit in your “First Creation” with regards to solutions to any changes – yes.

Part II

The first section here discussed having a First Creation for the whole feature you are creating – another aspect of the First Creation in software development is at the granularity of the actual code. When you create a class or a method or even a for loop – you should explicitly think it through before writing code. This would be obnoxiously difficult if we didn’t have a technological tool to make this possible.

That technical tool is called the Unit Test. When we write a unit test – we are creating client code for our actual production code. This forces us to switch perspectives to think about what it is we are creating and how it completes its mission. This change of perspectives allows us to quickly and with minimal context shift do a First Creation for every bit of code we write.

Conclusion…

Creating elegant, simple (but not simplistic) solutions to the problems we face is hard work. It’s ultimately far more satisfying (and profitable) than hacking code together quickly and throwing it out the door. If you are up for it – if you are up for doing the work to intimately understand your problem space and deliver amazing solutions – well you are well along on the way to creating more incredible software!!

And the world is a better place when we create more incredible software!!

Happy Coding!!
-Kyle