The Retrospector

I stumbled onto an article in Ry Lowry’s blog that included a piece about his frustration with applying test driven development (TDD) to a commercial framework.

To summarize, he’s comparing TDD applied to an open source framework (Spring) with applying it to the commercial product. Spring was certainly designed for TDD and being in the open source community is very easily integrated with near any of the popular testing methods.

The commercial product he’s using doesn’t seem to have any easy way to be tested using many of the testing tools that are out there from a TDD perspective where you start with unit tests and work your way up to the different testing levels until you have near-end-user-like testing as well.

A couple of things come to mind that I think add value to the discussion:

(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…)