Variation Behind Interface

Identical houses on the outside, but you can be sure that the interior decoration varies.

...the architecture has been established, and CodeOwnership has been put in place. Features have been assigned. Now the easy part is over.

✥ ✥ ✥

Once you start developing software, you find that things change. And these changes can affect not only your software, but software written by others as well.

A typical scenario plays out like this: You are working on a feature, and you need to change a certain file. Unfortunately, someone else is working on a different feature, but needs the same file. Good configuration management and work space tools can use file locking to prevent one of you from undoing the other’s work, but there is still a problem with merging your modifications together. Or perhaps you just wait for the other person to complete before you start your work on that file.

A similar problem is this: You are working on a feature, and call a function that someone else is working on. When you build against the official base, you find that the function has changed, and you need to change how you call that function.

We can turn that problem around: You are working on a function that others call. When you build against the official base, you find that your changes cause build errors in others’ code — where they call your function.

These problems illustrate the technical problems that arise from multiple people working on a software project.

Even worse, you may be waiting for someone to check in their code so you can make your own changes to it. After they check in their copy and you check out the image for editing, you find out that they have added some things you would like to use and have deleted some things you need, both in the same unit of editing. This is a fundamental dilemma that tools and technology alone cannot solve.

Therefore:

Create interfaces around predicted points of variation.

Note that this requires one to predict, or at the very least, make educated guesses about what will change, and what will remain constant. This can be called commonality and variability analysis, or domain analysis, and is described in various places such as [Weiss1999] and [Coplien1999].

In spite of our best efforts at analysis, it will be necessary to change the interfaces on occasion. These changes impact others; to minimize the impact, use NamedStableBases to manage these changes.

This is really nothing more or less than information hiding, as originally described by Parnas [Parnas1978]. Here the motivation for information hiding is to insulate others from expected changes. It was also behind Alan Kay’s work in object-oriented programming.

This pattern forms the basis for ShearingLayers [Foote2000], which states that you should factor your system so that the artifacts that change at similar rates are together. One difference is that ShearingLayers is often applied at the system level, rather than the module level, as this pattern is.

✥ ✥ ✥

So what does this pattern have to do with creating effective software development teams? Quite a bit, actually. Of course, a project is partitioned among team members. The team members depend on each other’s software; therefore the connection points of the software — the interfaces — must change as seldom as possible. Otherwise, people find themselves spending much time rewriting parts of code that once worked. And people begin to get testy with each other. The way to minimize interface changes is to hide variations behind interfaces.

Don’t get too carried away. Too many interfaces cause the system to be slow.

Designers sometimes try to anticipate all variations. The extra interfaces slow down and complicate the software. Often the situations they hoped to anticipate never happen, so the interface serves no useful purpose. The trick in good design is to correctly anticipate the changes, or the cost of the interface against the cost of the change.

See HierarchyOfFactories and ParserBuilder as examples of this approach.