This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: Why Software Should be Backward compatible
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
Whilst installing some software last week I found a number of niggling enhancements that made previous configuration files and files the customers use in compatible with the new release. This meant I had to spend ages hand crafting the users files until they were finally able to work with the new system.
I have recently found that a number of the previous enhancements have also had this effect. I believe this is a very poor way to develop software and I feel it's important for developers, especially if it affects me to think about the effects of their code. Below are the main reasons why I think code should be backward compatible.
1. Customers shouldn't fear upgrades
Customers are usually cautious about taking upgrades don't give them reason to fear upgrades. This means you should make upgrading their software as easy as possible and make sure there are no hidden side effects.
2. Don't add bugs to the software
It can really piss off other developers if your code breaks theirs and the most common reason for this problem is because you haven't tested your code thoroughly enough or tested the code in a wider context
3. You are creating different releases
If the code isn't backward compatible you will get some customers staying with their old release. This will result in your basically having to support at least two releases, the current release and the old release.
4. Upgrading customer?s software can be a nightmare
When software isn't backward compatible, upgrading the software can be difficult because you will have to go through a number of steps to make it compatible. This is making a difficult and stressful job more difficult and more stressful.
There are of course times when you decide to make the software not backwards compatible often to use new technology or to refactor or re design the code from scratch. I was annoyed with the developers recently because our code was backward compatible just because of sheer laziness and the developers in question (who has left) just couldn't be bothered to think about making it backwards compatible.
We have seen recently examples of backward compatibility and the costs. When Generics was added to Java they did a pretty good job making the code backward compatible but this came at a cost which was making it only compile time and it has come under heavy criticism regarding it's design and implementation. The cost they have made is they would have probably liked to design Generics from scratch but that would mean that it wouldn't be backwards compatible. I rightly believe they made the correct choice, although people might not like Generics I'm certain they would have disliked Generics more if it wasn't backwards compatible.
Another example of backward compatibility or not is the Junit 4, it was redesigned to use Annotations. Although there is a way to use your old code with Junit 4 it involves a bit of a hack and using an adapter. Due to this I haven't yet started using Junit 4
Previous Topic
