Is It Upward Compatible?

I like to look at things the other way around and ask the question: Is it upward compatible? And then the answer is: If we don't need to maintain a parallel version.

Upward compatiblity is not an easy term to define. I can give you a hundred definitions that might work but don't. Consider these. It is Upward Compatible (UC) only if:

• it doesn't change the user interface
• it runs on the current hardware
• I don't have to convert or reload the database
• it doesn't de-stabilize the build
• the documentation doesn't have to be changed
• it supports the same message protocol

And so on. There's a lot of seemingly good candidate definitions. And they're not bad considerations. In fact they're very good. The problem comes when I go back to the original question: Do I need to branch this software and maintain a parallel version? Now look at the list above again. A developer takes his answer "if it's not upward compatible" and proceeds to branch his or her software subsystem 19 times before release 1 is even out the door. Why?

Well a lot of changes are going to occur to the user interface early on. The current hardware is changing rapidly to meet production cost targets. The data schema has not yet been finalized and my change requires some new fields. The build is already unstable. This feature was built slightly differently to provide more flexibility than the requirements and specifications mandated, in order to reduce complexity and increase reliability - so the documentation has to be changed. We needed to add a new message and a new parameter to another one in order to complete this feature properly.

The Customer is Right

All sorts of scenarios exist where any of the above are valid UC changes. We get closer to the answer when we start asking the question: Does it affect the customer? That's a good one. If there are no customers yet, I really am a lot less concerned if the user interface is still changing. But I would like to avoid having to recreate my test bed every week because of database re-creation requirements.

So maybe the key is to consider the internal customers as well as the external customers. Until, that is, you fail to deliver a change because it was Non-UC (NUC) and your test lead complains that if you don't deliver it soon, he's not going to have time to verify the product. So as far as he was concerned, the NUC change was really UC, even though others consider it NUC. We're basically working our way back to a better definition of UC.

I would define a change as Upward Compatible if, and only if, there is no need to maintain the parallel version. It's not just a condition, it's a definition. And it forces you to understand the business conditions which designate the "need".

But some will argue that this is no good - I can't look at my change and know whether its UC or NUC. That's right. You can't. In fact, I can take the exact same change at two different points in time and it will be UC at one point but NUC at another. You cannot just look at the change. You have to look at the whole picture.

Sometimes we find this out the hard way. You have to look at the whole picture. So how does this definition of UC help? Well, basically, it begs the question by focusing you on the heart of the matter. You need to understand if a change you