#53-Changing Change, Part 2

This episode will explore another aspect of the agile design process, from a non-technical point of view.

Transcript

Changing Change, Part 2

Agile says designs should favor compositional approaches over specialization. 

What does this mean, and how can this be expressed in a non-technical way? To explain things like this, I like to use analogies that most people are familiar with.

I have a garden hose with a spray attachment for watering plants, washing cars, or cleaning sidewalks and decks.  Most of you have likely used one of these at some point, but even if you have not you’re certainly familiar with how they work.

I personally enjoy gardening as a hobby and sometimes, usually in the spring, it becomes time to not only water my plants, but to feed them with a nutrient mixture to help them grow and stay healthy.  There are multiple ways to accomplish this including plant food spikes and special food injectors, but since I’m going to water my plants anyway, the way I prefer to do it is this:

I remove the watering nozzle from the hose, attach a food supply vessel that was designed for this purpose, and then re-attach the nozzle to it.  When the water flows from the hose through the vessel it picks up the liquid nutrients along the way and then the nozzle sprays the enriched water on the plants.  I find this convenient because I can use the same hose and nozzle that I normally do, and am comfortable with.

The hose, feeding vessel, and nozzle are composed into a new system.  I don’t always want to feed my plants, so putting the feeder in line is an optional thing that adds the behavior of feeding whenever I want it. 

This, as opposed to buying a specialized nozzle that would always add the food.  You could do it either way, but the agile recommends that you favor, or lean toward, the compositional approach rather than the specializing one.  

In a business system this could be used to add logging, or auditing, or notification... any number of behaviors that are wanted only under certain circumstances, to an existing system.  Those behaviors would not have to be anticipated ahead of time, but could be responsive to a new requirement, an innovative idea, or an unanticipated opportunity or competitive challenge. These changes would be wholly good things, not something to be avoided as dangerous or wasteful. They could be, as agile recommends, embraced.

It’s important to note that agile does not insist that specialization is always wrong. Agile is always about informing and enhancing your decision process, not replacing it.

Also, note that in the last episode I talked about how agile design favors early attention to interfaces.  The reason my garden nozzle can be enhanced with a feeding vessel is that they have the same interface, the threaded screw-on fitting that my hose, the spigot on my house, and basically everything involved with the watering process does.  That's another reason to follow that advice as much as you can. 

But, it also enables the next aspect of changing change, which I'll talk about next week.