The Retrospector

Not using patterns in software design and development leads to code that will probably work at first, but almost never withstands the test of time. This article is a continuation and conclusion of The Pattern of NOT Using Patterns – Part I & The Pattern of NOT Using Patterns – Part II which talked about how we get into situations where we don’t use patterns, when patterns can be appropriately applied to a project and what happens when they’re not applied when they should be. In this final segment, I intend to explain how differences in pattern familiarity can affect people as they’re working on a project.

Familiarity is key

I’ve really seen both sides of the patterns argument. There are the anal-retentive pro-pattern almost snobby-like developers that simply can’t imagine projects without them. Then there are those that simply don’t see what all the fuss is about and can’t understand why people would waste their time with patterns in the first place. Of course there are all the shades in between, where people decide to use them sometimes and not others. Some use them when they don’t realize it, and others don’t use them when they think they really are using them.

Familiarity is important in either case. I believe a certain level of understanding is required for any technology to be created or used effectively. If you don’t understand the patterns you’re trying to use, then you won’t gain much by trying to use them. Likewise, if you’ve really put the time in to understand them correctly but don’t know how to apply them…what good are you? This isn’t just about patterns. I think this particular segment could apply to near anything if you really think about it. You have to know what you’re doing to be effective at all.

Patterns love me

For the majority of people that have become familiar enough with the programming patterns through simply discovering what works best in their programs (well, not simply really…it takes awhile to learn them on your own through trial and error), they can easily recognize the cases where it would make sense to apply some kind of pattern to an application. I’ve seen that these people, whether truly learning them on their own or learning them from another source, can effectively produce applications that make maintenance easier.

Granted, if whoever is charged with maintaining the applications isn’t familiar with the patterns used then it could get ugly. That’s what documentation is for though. Whoever is maintaining an application written by someone else, there has to be some level of documentation to be effective or it’s just a needle-in-a-haystack type of bug-fixing/enhancing.

Patterns love me not

As for the other group, or those who don’t have some level of familiarity with known patterns out there, knowing when to apply patterns to projects just doesn’t come easy. To compensate for this, they might just say the use of patterns is generally stupid and way overrated or they’ll just flat out ignore them which could result in missing valuable opportunities.

I’ve noted both extremes here, but I really think people rarely fit in either category all the time. Most will fall somewhere in-between, but lean towards one side or the other. I haven’t met too many people that were indifferent on the subject. Either you know how to use them productively, or you don’t. The key is to know when to apply them, and you have to be very familiar to really see most of the opportunities to do so.

Patterns, let’s just be friends

At the end of the day, being on a big web project where the obvious MVC (model-view-controller) pattern is being used whether most realize it or not isn’t all that a project could benefit from. This particular case is one where many in the grey area could be distinguished. The hardcore pro-pattern crowd would insist that there’s dozens of pattern opportunities everywhere in the framework to use. The anti-pattern crowd would say “But we’re using a pattern, it’s MVC. What else do you need to know?”

In my experience, having MVC in there is better than nothing. Knowing when to apply more patterns in this case takes me back to The Pattern of Not Using Patterns – Part I where I discuss more about where they’re appropriate. My point is the ones that are more familiar with patterns will know where and how to apply them. If they truly are familiar with them, and the project is appropriate for pattern-use then being familiar really helps the project in the end.

Don’t lose sense of urgency

If the pro-pattern crowd pushing the pattern use into the project is worth a grain of salt they should be able to apply patterns without adding too much time to the overall project delivery. Many people believe that having to apply patterns to a project will drive the implementation cycle to a screeching halt.

Let me tell you right now that it can happen like that. I’ve seen it happen both with experienced and inexperienced pattern users. The crucial element in delivery is meeting the requirements by the promised time. If not everyone developing is on board with the intention to use a pattern, or if the developers don’t all know and understand how or why they’re applying any of the patterns you may as well not bother with them. The sense of urgency can be lost or outright ignored if people feel they need to take time to learn what the pattern is or how it’s correctly implemented.

If you don’t know how to use a pattern and just saw someone preaching on how awesome or great it is when your project is starting, either get someone who’s done it before to help you apply it, or figure something out that everyone on the team can understand and follow from the get-go. A developer that knows what’s expected of him and knows how to fulfill that expectation is more likely to deliver you something you can use.

At any rate, being familiar with patterns is a crucial element to being able to apply them in a timely manner during a project. It’s a difficult practice until you get the hang of it, but is an extremely powerful skill when stepping into another project that’s already been started.

Conclusion

Not using patterns is going to take away from your bottom line in some way or another almost every time if the project is appropriate for them. The gist of it all is that you have to know where patterns are appropriate, you need to know what happens when you don’t apply patterns to appropriate projects, and most of all you need to be very familiar with them to understand and know where to apply them.

Maintenance of any application being where most time is spent should be a focus, if not the focus when building an application intended to last a long time. Patterns are very helpful in setting up a project to be maintainable by anyone else that is familiar with them. Otherwise, we have a world full of proprietary applications that have to be dissected each time we have an employee turnover, or someone new brought onto the team. Not using patterns is potentially one of the biggest anti-patterns there is.

Tags: pattern, patterns, design, agile, anti-patterns

   

Related Posts:

• The Pattern of Not Using Patterns - Part II
• The Pattern of Not Using Patterns - Part I
• Group Communication: Start with something positive
• Why Gamers Make Great Developers
• 5 Steps To Help Your IT Team Concentrate

Explore posts in the same categories: Technical, Design

You can subscribe via RSS 2.0 feed to this post's comments. Feel free to comment below, or link to this permanent URL from your own site.