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 of The Pattern of NOT Using Patterns – Part I which talked about how we get into situations where we don’t use patterns, and when patterns can be appropriately applied to a project.

Many outcomes are possible when patterns aren’t applied to a design. In fact, a lot of projects are successful. Success is not measured by how applications are designed, but more-so on meeting requirements and expectations of the customers. This article in the series isn’t really applicable to projects where it wouldn’t make sense to apply patterns in design, but on what may happen if you don’t apply them to the projects where you should.

What happens without patterns

Let’s pick an example scenario that’s actually very common so some of you can relate to it, generally walk through the lifecycle from a high level, and then see what happens…

Let’s say you’re on a project with a team of 5-6 other developers. It’s a project expected to last about 4 months, and there’s about a dozen major features of the application that you divvy up amongst the team after a kickoff meeting. A design meeting is held to roughly plan how the components will all be combined while creating something resembling a technical specification. Then off the developers go to code up the pieces! (This assumes that there’s at least a requirements document for the application that everyone has a copy of.)

Requirements change – like it or not

A month goes by and everything seems to be going great. Meanwhile, the users have had a few weeks to think things over and a couple of feature creep items try to sneak their way in. Management, never wanting to be the bad guy, fends off half of the features but accepts a couple just to make the users happy…forcing it into the development team’s schedule. Well, it so happens that the scope creep effects not just one of the original major features, but three of them. The two developers working on those pieces took totally different approaches.

No big deal right? So they compromise a little or pick an approach. The two come up with something that makes sense according to the original technical specification for their pieces and move on. Here’s where it hurts, if there was a change outside the scope of just one piece everyone should have been included and the design reconsidered.

With a pattern-filled design, most layered architectures allow for easy changes to interfaces and data flow. If all the developers are only thinking of their own little scopes for the duration of the project (aside from the day or so at the beginning when they formed a “clear picture” in their minds how it should all work) then you get many separate little applications each with a defined integration point. However, as requirements change, so may the interfaces or data flows within the application that could compromise the components.

“You want us to WHAT?!?!”

So let’s say another couple months go by with roughly the same cycle. The project goes on, and the users cram in just a few additions or changes every few weeks. Let’s even be nice and say it’s just one or two each month. By this time, the original tech spec is collecting dust on your desk somewhere under your coffee cups and empty soda cans, because each developer already knows their piece really well by now. Here comes the whammy. Something major has come up that forces management to decide whether or not you can continue the project, or give 3-4 of the original major components a major overhaul. “Um, wth?” comes to mind from all the developers. And don’t ask me why (that’s another article in itself, and I may get to it eventually), but it the project stakeholders all buy into it and want you to “just get it working, we can fix it up and clean up the code later once we’ve been using it awhile”.

133t h4XX0r $k1llz to the rescue!

Here are the three main pitfalls that come to mind from events from a scenario such as this, which aren’t necessarily solved by using patterns, but they could have more easily been prevented…

1. Design decisions are made impulsively to meet the upcoming four-week-away deadline since the overall picture of the app is completely different to each developer who is only an expert with their components. Developers will venture further and further from a collaborative design unless forced to do so together. (Seriously, even though most are willing to and say they will…it just doesn’t happen productively unless hand-held by an architect who doesn’t even know the code that well anyway.)
2. Some of the developers have “coded themselves into a corner” where it simply can’t be done any other way, so you really have to pull out the hacking skills to finesse things together.
3. The code is near un-maintainable by anyone who didn’t put it together to begin with because there’s nothing familiar or recognizable in the design or code other than the resemblance of an interface where it ties together with the rest of the application. I don’t know about you, but reading someone else’s code can be pretty tough. Anyone can write code that a computer can understand, it takes a really good programmer to write code that other people can understand. (I forget where I’ve seen that quote, but I’ve seen it before…and I may be off by a few words.)

“OK, it’s later. Weren’t we going to clean it up?”

Just when you thought you were actually going to get a little downtime after launching an application to clean up this mess…yes…another project lands on the hotplate. Here’s a little insight as to why management is NOT going to have you “clean it up later” as they said when they just wanted you to throw your hands up in the air and get it working ASAP.

1. In planning, the numbers can all make this project look successful when handed up the chain of command. And believe me; the managers WILL make it look as successful as possible to their superiors unless they have absolutely no choice. If it was a success, how can they possibly justify having to “clean it up”? Clean what up? It works!
2. Management can’t justify in any ROI equations why you should refactor some code or make things more versatile when there’s other projects that could benefit the company even more. There’s always greener grass when comparing ROI on different project opportunities.
3. In the end, if people are that unhappy with how things are and how long it takes to make any kind of feature enhancements or changes, the entire thing will just get replaced with software purchased off-the-shelf. Or, if you’re lucky, management will somehow justify to the company that the original application just wasn’t scoped out to encompass all the new things and just needs to be rewritten from scratch to handle all the new incoming requests.

Yeah right, this isn’t realistic…

Ok, so a lot of this is very imagination-dependent and a little far-fetched. I did this intentionally in most of the analogies and events simply because everything in this “fake project” DOES happen sometimes. The odds that all of it will happen in the same project are probably not as probable, but I’ve seen all of this before. I’d be very shocked if most of you couldn’t at least relate to half of this scenario. If there’s anything I’d like you to take away from this, it’s most certainly that all of the things I’ve described going wrong here can be better prevented with the proper application of design patterns. (Well, and the buy-in from management on the fact that a little more design is simply needed if this application is to be worth a darn after a few months.)

I’m not saying design patterns are the absolute solution here, nor the only thing needed to avoid the problems I’ve described. But over the years I’ve seen a pattern develop in each project that has similar traits to the one above…a pattern resulting from NOT using patterns.

Soon to come: the third and final article in this series where I’ll describe and conclude how to avoid such horrible (though humorous in my opinion, I’ve lived most of this bad example some time or other over the last 8 years) mishaps using patterns in The Pattern of NOT Using Patterns – Part III.

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

   

Related Posts:

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