Breaking changes

Sometimes, even with the best intentions, we make a mess of our component upgrades. Not with the new or improved functionality you understand, but with backwards compatibility and introducing breaking changes. Sometimes the effects of this mismanagement are minor, other times you, our customers, are faced with a barrage of compiler errors when you update your projects to use our improved components from the suite's latest version.

Backwards compatibility: dread words that strike terror into the hearts of developers everywhere.

Let's get one thing on the table straight away -- and I'm sure this won't be a surprise to anyone who's been writing software for a living for a while. Backwards compatibility is hard: you have to dedicate time and resources to it and you break it at your peril. I'm always impressed that MS have done so much for so long to make sure that your old DOS and Windows 3.1 programs still work in the latest versions of Windows, including the Vista-to-be.

The main reason why it's hard is that developers as a whole want to provide better, more functional, faster software with subsequent versions of their products and to do that will sometimes require making breaking changes: changes to the UI of an application, to the programmatic interfaces of a library, to the schema of a database that mean the existing functionality of the software doesn't work in the same way as before .

You publish your version 1.0 of a product. Now, to get version 1.0, you generally don't have the luxury of ample time to spend on forward-thinking design so you wing it. You make assumptions about what will need to happen for version 2.0 and you try and bake that into your code now. You try for extensibility and flexibility, but in reality you don't have the time or resources (or the business need) to do it properly. Of course, overriding all that is what will happen when version 1.0 is released. Will it be a flop? A success? If a flop, you'll be chucking the code to some extent pretty quickly and moving on. If a success, what will the customers ask for to extend it, to make it better? I can bet their requests and suggestions won't be anywhere near what you envisaged, so your careful preparations will come to naught. And knowing this beforehand, just makes it more likely that you don't spend too much time designing for the future.

Unfortunately, if your version 1.0 is a success, you are now locked in to the expectations of your customers, and those expectations will include a "make it better, but don't break it" component. To be fair, customers (for we all are customers in one shape or form) will sometimes countenance a "if you must break it, break it big, but make it utterly compelling to upgrade" possibility.

Back in the late 80s, Canon were faced with a problem. Their SLR cameras were selling well, were very well liked, but they wanted to produce a new line of electronically-controlled SLR cameras (the EOS series) that could do auto-focus and auto-exposure. Unfortunately, their current line-up of lenses were hampering them. So they did a very brave and risky thing: they brought out a complete new range of lenses (the EF series) together with their new EOS camera bodies. Now, you've got to understand that lenses, especially telephoto zoom lenses, are expensive. In essence, Canon told their customers that to move forward, they would have to purchase all their lenses again after buying a new EOS camera body. As it happened, the EOS series was a massive success because the cameras were so easy to use for non-professional leisure users (that is, there was a whole new market out there), and so compelling for existing users to upgrade (at some cost to themselves, obviously).

So, with a version 2.0 of your product, you have a choice: make sure you're backwards compatible and provide incremental enhanced functionality, or produce an utterly compelling upgrade but break compatibility big-time. In general, we tend to go for the first option: there's much less risk involved.

Of course, in moving forward incrementally, you will be faced with decisions about making minor breaking changes. Sometimes changes can be hidden from the user, but a lot of times it can't. For example, my wife's new Acura TL has a computer-controlled accelerator pedal which is no longer connected by cable to the engine. Instead a computer monitors how much she depresses the pedal and electronically revs the engine. To her the accelerator works in exactly the same way as before, but is just a smidgeon more responsive (an example of a non-breaking change). Conversely, the switch for the sunroof has moved from the lower left of the dash up to the roof (an example of an admittedly small breaking change).)

Next time I'll be more specific and talk more in depth about what we do (and will be doing) at DevExpress to mitigate the problem of breaking backwards compatibility.

Free DevExpress Products - Get Your Copy Today