Jim Shore tackles "design"--that loaded word we all talk about so fluently and yet define and think of so differently. The way Jim slices and dices "design" into a taxonomy that communicates the true meaning is an example of the kind of work consultants all around the world do every day, trying to help their clients see their software development projects and organizations from a new angle.

Much of the problems encountered when introducing techniques, methods, and processes to an organization are at least in part strenghtened by prior bad experiences with similar sounding, yet different vehicles. A client once mentioned they couldn't use the word "functional testing" in their organization because the term had a bad ring to it dating back to the 90's. Another client has a hard time convincing some colleagues that agile methods are any different from the RUP stuff they had experimented with some years ago with less than admirable results. The problems started when they heard the magic words "iterative and incremental" and snapped right into the knee-jerk position combined with a temporary blindness and a malfunctioning hearing aid. And without the slightest insight into the reality--them having applied RUP as a glorified waterfall method instead of tailoring an iterative, incremental process. Yet another client always jumps from 2.x to 4.0 in their release numbers because the 3.0 release for a certain big project was such a flop that it stained the number 3 for good.

In a world riddled with such quasi-superstition, it certainly is difficult to bring forth change. Fortunately, it is not impossible. Just difficult. And every time we succeed it becomes a bit less intimidating even though it doesn't get any less difficult. Luckily, these days I have the luxury of not facing these difficulties alone. More and more, I'm seeing clients taking the lead on their agile adoption just like they should instead of bringing in a consultant and walking away thinking they've done their part.

Understanding is a prerequisite for change. Interestingly enough, often times the perhaps most important work I do as a consultant is to make problems visible and name them as such. Again, not an easy task. Nobody likes the outsider who thinks there's something less than perfect in how we've always written software. Yet, someone has to do it and I like doing it. Maybe it's the challenge. Maybe it's plain old masochism. Maybe I'm just addicted to being able to help.