The Importance of Design Patterns

I suppose this post is aimed at the recent graduate of computer science, or to the programmer who is at a stage of his career where “Look!  It works!” is a validator for whether they know how to program or not.  (And further down in the article towards a CTO who has to give business arguments for why certain things need to be done)

I’m a freelancer and have been for almost 2 years.  What this means is that, for a fee, I am parachuted into unknown territory and am asked to complete task X in amount of time Y.   This is straightforward and enjoyable for prototypes or new tasks, but now that I have some time to reflect on the past, like pulling teeth when you are dropped into a project with a pretty old codebase written by mostly recent graduates and students.

Basically what happens when programmers do not adhere to the paradigms of design patterns (I’m an iOS developer, so I am mostly in this case employing the Model-View-Controller pattern), basically any object ends up with a pointer to any other object, and when you hope to implement a feature by extending the functionality of one specific component, it slowly dawns on you as you are stepping through code to try to understand how it works that basically the app is one big component called AppDelegate and everything else is a member variable.   In programmer parlance, it’s Spaghetti code.  And not just the ‘i just pulled this out of the strainer’ spaghetti, no, this is the ‘i just went back into the kitchen 3 hours later to see if there’s any spaghetti left’ spaghetti, and when you pull on one noodle, the entire blob which has now taken on the form of the pot it was in, is lifted out with it.

This post is about the importance of design patterns.  Yes, we all hear of these things.  But then we are implementing, and don’t know how to get this object talking to that object whilst following the pattern, so we hot-wire a solution where objects A and B, who should otherwise not have any knowledge of each other to do their job, now contain pointers to one another.  This is called coupling.  Now repeat this idea for almost every object in your code, and you not only have the most tightly coupled mess, you now have code that:

* has a very very steep learning curve for new programmers on the project

* is very difficult to extend and add new features because it’s impossible to work on one component in isolation

* is NO fun to work on (affecting quality of life and thus how much they will charge in the future)

* next to impossible to test / debug in any timely manner

What does this all mean?  Cost.  At the end of the day, we are all being paid to produce something, and all of these things result in longer amount of times required to get anything done.  So, you hire a freelancer to implement a simple feature?  First you have to pay him handsomely to learn and understand a codebase that doesn’t follow any pattern, so on his side, no assumptions can be made about how it works.  He has to discover everything new.  You’ve just spent 2-3 weeks on one person who still hasn’t accomplished much.  Now that freelancer understands how it works, but wants to extend a component.  Now the implementation could also end up being messy because it’s trying to consider all of the existing mess and tries to prevent that from getting worse, if possible.  This also takes longer.  The entire time it actually kind of sucks for such a programmer because it’s just painful at every turn.  This programmer will no doubt demand more money next time because the job was not fun.  You just want to implement something simple, but it’s a constant 2 steps forward, one step back, maybe even two steps back.  Actually it’s more like “maybe I can take a step here?  No.  Try somewhere else”  And testing…. ?  Well, that’s just something we won’t get into here.  We just assume that if the code is as it has been, unit tests were never in place to begin with.

Good, structured code, that adheres to principles of software design is ESSENTIAL to any project that is more than a prototype.  What business leaders need to understand is that development takes TIME.  “Yes, it takes one week for that little spinny wheel to do its thing so that later an image is displayed.  But NEXT time we need to do that, our costs are like 1/5 of what they would be because we built something GOOD.”  You get the drift.

Stay tuned for a post about how to approach writing structured code that’s easy to work with.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s