Forward and backward compatibility put considerable constraints on the interface designer, especially when changes are to be made. The definition is:
Forward compatibility or upward compatibility (sometimes confused with extensibility) is the ability of a system to gracefully accept input intended for later versions of itself.
If we use the same sentence structure, we can define backward compatibility as:
Backward compatibility or downward compatibility is the ability of a system to gracefully accept input intended for earlier versions of itself.
As an example, think of some of a software library like the Boost C++ Libraries. If a change needs to be made in an interface, it must be done very carefully to ensure at least backward compatibility. If a method must be deprecated, it must not be done immediately. The method is supported but it is documented that support for this method will be removed in the future. And it is often years before that happens.
Much of my work is on existing systems so I have the difficult task of making sure my changes to external interfaces are both forward and backward compatible. This is difficult to do intellectually and I often miss things that break compatibility. I’ve built up what our team has learned into a set of standards we follow to assure that we can keep this compatibility.
But our interfaces are getting more complex and we are still missing things.
This is causing an unfortunate dynamic on our team. The first behavior is tremendous fear. Team members fear that what they release will not be forward and backward compatible so they get in the mode of carefully trying to find every problem imaginable.
Here’s a systems dynamics model of our current problem. The models were developed using Vensim and there is a free trial download of the software at their website.
The first picture is of a simple model. Note that the development rate is constant if the rate of problems found equals the rate of problems fixed.
Note: The graphed results of a simulation of this model are shown in the picture of the model (see the flat rate of software productivity and the rate of problems found and fixed).
Now we’ll add the fear factor to the model. When fear occurs, more problems, whether real or imaginary, are discovered. The software development rate goes down.
When this occurs, schedule pressure starts occurring (note that this dynamic is not shown in the model). Schedule pressure creates more fear which causes more problems to found, real and imaginary, both of which need to be analyzed. Schedule pressure might create an increase in productivity (“you must fix more bugs – please work as much as you can to do this!”). But it can’t match the fear factor and the software development rate decreases even more.
My theory is that if we create a more supportive team environment, we can counter the fear and get our development rate back up. The team will have the following operating conditions:
1. All problems raised are considered and accepted respectively
2. Problems are classified and analyzed by a cross disciplinary team (people with variety of expertise) and decision is made – do we do this change or not
a. This should decrease the churn we have from changes – we probably won’t do as many changes as we have in the past.
3. This team will also recommend the best fix for the problem so the rate of problems fixed will increase.
Voila – software productivity is back up and even increases.
I’m trying this experiment on our team and will report back the results in a few months. I feel confident that this supportive team model will change our dynamics.
No comments:
Post a Comment