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.

Introduction

I’ve been on a number of development projects where emphasis was put almost solely on delivery time. “Just get it working by Wednesday…” or “I don’t care how you do it, just get it done and we’ll clean it up after we go live” are both popular phrases heard from management. Well, when this happens people start taking shortcuts. One of the most common things to leave behind on the original project plan is testing, another, though most may not notice it happening right away, is design.

With many projects emphasizing the agile process, some believe that leaving design to the wayside entirely is the proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.

I’ve always been a big fan of Martin Fowler, and I suggest you take a look at some of his articles on the agile methodology. I’ve had copies of some of his patterns and refactoring books on my desk since I realized what design patterns even were and love every opportunity I get to re-familiarize myself with some of them when designing an application. Projects weren’t always so exciting at the outset, and perhaps it was just a result of me not really knowing what to expect from my team. Maybe it was that I just wasn’t as confident in being able to determine what design decisions to make when given a requirement.

What I’m about to describe in this series is the pattern I’ve seen from not using patterns, to hopefully encourage you to avoid the unrecoverable scenarios of bad design and to become as familiar as possible with patterns and design approaches.

Where using patterns is appropriate

It has occurred to me that there are almost always exceptions to the rule. Patterns in general are not the end-all solution to every design. They help benefit the application’s value and maintainability in that components are generally easier to integrate, and more recognizable by those that end up making changes later in the software’s lifetime…which brings us to the next set of points. How long is an application supposed to last? What is the project size? What are the dynamics of the department or team of people that will ever work on it? All these issues effect the decision on whether or not it’s appropriate to apply patterns to a design.

Maintenance – Lifespan and Size of the project

What you need to consider most about the application lifespan is how much you anticipate having to maintain it. Now I suggest you double, maybe in triple that figure and you’re probably in the ballpark. Maintenance is one of the most underestimated components of a project that businesses dismiss faster than any other. Management wants perfectly written software the first time, and they assume far too few anomalies will show up after pressing you to “just get it done now”. Maintenance is so often underestimated, that I may just have to write another article about it alone. (Yeah, I probably have that much to say about it.)

Knowing that maintenance is one of the key things that patterns can affect, you have to determine if it will live long enough to justify any design time you want to put into it. If the project is simply a bridge-gap for a much bigger integration effort and will be thrown away in a month’s time, the maintenance is obviously not something that will benefit from spending the additional time putting in place pattern implementations. If it’s a large-scale enterprise application that will have 1000s of concurrent visitors, chances are you’re going to be maintaining it for a very long time. Then there are all the projects in between.

For me, the cutoff is generally when I learn the product is intended to be used for more than a couple months. This means it will probably be used for a year or more, and there’s no telling how much they’ll want to change it. Chances are, they’ll grow attached to it the first month, and want to change it one feature at a time into something entirely different. (Eventually you’d have to draw the line and say “these features were never intended for this first application, we’ll need to refactor and begin a new project to incorporate all that” but know that in the end, it’s management that generally decides what’s ok to take on as a new project and what’s ok to just “hack to get it working right now”. Guess which I’ve seen much more of?)

Most stakeholders (i.e. business users or whoever else will benefit from your project) expect things to happen at the moment of conception. If they’ve got even the smallest of ideas, they want to see it in action right now. Management’s reaction is to generally try to give that to them, so a prototype application many times turns into the live product with dozens of patches if you’re not careful. This classic build-and-fix lifecycle usually results in the quick demise of any design pattern considerations.

Team Size

Another consideration is team size, but I find this less important than the project scope. Having a very small team where everyone is on board with each piece of the application and how it works together can typically bypass some of the drawbacks of not using a solid use of design patterns. Depending on how you divvy up the work, if there’s only 2-3 of you then there’s pretty good odds that you had to work together more than the average team in order to get this project out the door. You’re going to have had many more conversations on how things work, and may understand each other’s abilities and programming traits better going into the project.

This may not hold true on a larger project though. Beware the mind’s ability to overestimate your abilities, and assuming everyone else on the team visualizes the final picture the same way you do. Having a small team isn’t an excuse to not use patterns, but the pitfalls may not be as profound as those on a much larger team. You simply can’t predict the ability of a resource as being a standard unit of one. (Like in a scientific calculation) Everyone is different, interacts differently, and communicates differently. Using a universal language for identifying design components and decisions throughout the entire team becomes far more crucial to the success of the overall project.

In the end, I prefer to use patterns in every identifiable opportunity I get. If not for the sake of making the project more maintainable, then do it for an opportunity to practice using them. Regardless of the project’s scope or size of the development team, getting into the habit of identifying patterns and applying them wherever possible is simply an undeniably good practice that can help you later when they’re practically crucial for long-term success.

To continue on to the second part in this series, head on over to The Pattern of NOT Using Patterns – Part II.

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

   

Related Posts:

• The Pattern of Not Using Patterns - Part III
• The Pattern of Not Using Patterns - Part II
• 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.