Last week when I started writing about Design Patterns, I mentioned the Singleton Pattner offhand with the assumption that everyone was familiar with it. Unfortunately, I was off in my assumption...

The Singleton Pattern is probably one of the first and definitely one of most common Design Patterns that you'll find. A quick and dirty definition from Wikipedia says:

the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.

Over the next few weeks, I'm going to use this space one day each week to go back to basics because - unfortunately - I discovered that many people don't have these basics.

A few weeks ago when I was digging up information on IBM's various PHP efforts, I found a great article "Five commmon PHP Design Patterns". If you're not from an Object Oriented background or haven't run into Design Pattern yet, the concept is quite simple:

This is the first item in what I hope to become a series covering one of the largest systems I've ever been involved in building. A full year has passed since it was put into production so now I can give a level of detail which wasn't possible before. Yes, this is all written after the fact which gives insight not available at the time... oh well.

Alright, the first thing you need with any new system is a set of requirements. Some people want to skip this step and dive directly into the design or even coding but hopefully those people will be tied up and left in a closet by themselves somewhere. Just like you can't buy plane tickets without a destination, you can start system design or implementation without a destination. So here we go...

Over the Christmas Holiday, I was back in Northern Illinois visiting friends and family like I always do. Since I grew up in the area, I know it like the back of my hand, but I noticed something else. Even for areas which I had never been or paid much attention to, there was a simple pattern. Check out this map and see if you see it (click for a larger view).

That's right, the entire city (and even the county) is laid out in a very simple grid. Therefore, no matter where you are in the entire county, you have a set of Cartesian coordinates which can pinpoint your location relative to the origin. With the exception of just a few roads, it can be further represented by nearly every road in the county. 9000N designates the road 9 miles north of the origin. Anyone care to guess the distance between 9000N and 6000N?

For those of you not keeping up with my current events and noticing the silence on this blog, I am out of the office this week attending and preparing to speak at the Better Software Conference.

So far it has been an excellent experience and I've managed to meet and talk with some great people ranging from Jean Tabaka from RallyDev, Alistair Cockburn, and Robert Galen. I will be writing up day by day coverage starting this evening.

When software developers talk about a project, concept, or just about anything else, we normally speak in reference to models. We use analogies, we make comparisons, we have even come up with the concept of Design Patterns just to improve communication. While making comparisons can speed communication, we must choose the right comparisons and acknowledge that no single comparison is going to perfectly describe all aspects of what we're doing. After all, if there was, why would you be doing it again?

I was reminded of this last week when I was at a family Christmas party and I heard:

Person A: That stuff is as slow as molases!
Person B: It *is* molases.
Person A: (pause) Oh.

As you can probably tell, the comment didn't add anything to the discussion. While the point wasn't to share an idea and/or convince someone else of a model, I found it painfully familiar to other discussions I have heard.

Software development is confusing to many people and black magic for many others. We have a responsibility to make good comparisons and analogies in order to translate for everyone else. Not only can we communicate with customers better, but it allows us to communicate with each other better.

Think about the models and analogies you're using and ask yourself these questions:

Do the comparisons make sense?

If you're talking about email, comparing it to a postcard makes sense for various reasons: it's cheap to send, it's essentially public for everyone to read, and there's little to no guarantee that it will get there in a timely manner.

Do they add anything to the conversation?

If you have a library which simply wraps a different library to give it a standard interface, don't call it a "wrapper". That doesn't mean anything and doesn't add anything. Call it the proper name - an Adapter - and compare it to a US to European electrical outlet adapter.

Where do they fail? and Why do they fail?

Software development is regularly compared to constructing buildings, tending crops, waterfalls, and a variety of other things. When you're working with non-physical pieces that can be manipulated at will and have a near-zero transportation cost, these models only work so far.

Can you use other comparisons to describe those areas?

To describe software development, none of the above descriptions capture it completely, but some capture different aspects. Constructing a building gets to the concept of building frameworks and fleshing out the application. Sculpting a statue gets to the concept of removing unneccessary pieces and simplicity. Evolutionary concepts get to the idea of "survival of the fittest". None of them perfect, all of them useful.

Thanks for reading and Happy New Year.

A few weeks ago, Tom Copeland author of PMD Applied was nice enough to give me some time for an interview on CodeSnipers. I figured the least I could do is give him and the community some feedback on his book. Read on for details.

Once upon a time, I was involved in a rather large Java web project. This codebase was huge, under active development, and in need of a serious overhaul. As far as I was able to discover, there were no less than eight people's hands and development styles thoroughly embedded throughout the code. It was a mess, but it was mostly functional, so it was hard to complain. Until I realized that the system was still deployed and jar'd by hand.