The Retrospector

Code reuse in software development is something assumed literally through re-using bits of code in more than one place. It is truly achieved through using common libraries and interfaces accessible to both the entire application and to other applications in the domain.

What is code reuse?

Literal definition: Code reuse is the practice of using existing code…again. There are some benefits and drawbacks to code reuse as it is defined here. If you take the literal meaning of the terms you end up with simply using what you’ve got in another place.

Benefits

• Speed – I tell you what, I can copy/paste stuff like no other. My fingers can instinctively assume the copy/paste position on near any keyboard shape w/o me even realizing it.
• Easy – there’s not really much thought involved in having to just duplicate your code in another applicable area of the application, or in another application. If it works in one place, it’s more than likely going to work just fine somewhere else.

Drawbacks

• Maintenance nightmare – if for any reason you want to change a copied section, you have to change ALL the copies.
• Unorganized – there isn’t much organization to it. You simply create massive amounts of code to decipher after a while.

So, if there’s such a possible mess after massive code reuse, what’s all the hype about? Companies are pushing for code reuse, yet it doesn’t seem to lend itself well to long term maintenance, which is the majority of the time spent on any lasting application.

More realistic definition: Code reuse is allowing code that you’ve written to be accessible from more than one place. It can also imply that as a component, it’s accessible via a common interface to other components or applications. Though this may not be the best 2-line definition of the term, the key is that it’s far more meaningful than the literal definition. The following sections elaborate more on what code reuse really is.

(more…)

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.

(more…)

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.)

(more…)

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.

(more…)