I’ve been in programming for about 4 to 5 years now, and here’s a post about my experience with the concept of Backwards Compatibility.
A common phrase I’ve met in software development is ‘backwards compatibility’. It’s an obvious phrase with no need for an introduction. But, while backwards compatibility is good for a platform, like in Windows, or where being fresh is a big boost for another, there are times where backwards compatibility is just an excuse.
Here are some bad reasons why people cite the need for backwards compatibility in software as a reason to not change, implement or remove a feature or functionality, especially in completely self-contained projects (that do not have other software depending on them)
1 . When the development team doesn’t understand the system they are modifying
This is the most common reason I’ve found lurking behind a decision to not change a piece of software. I’ve found that less experienced, or less capable developers often fear ripping out a defunct piece of code, or clearing up a system when they don’t fully understand it.
If this is the best reason someone uses to counter the idea of modifying a piece of software, then I question why that team, or individual is even in charge of maintaining and developing said code. Since, how such fears must underpin almost any code they write. It’s often the reason why code that will be written by the team will also not be forwards compatible either, since they don’t understand what they are writing for enough to understand how to sufficiently write for it.
Solution: Learn from this mistake, hire better programmers, or ensure the current ones catch up on what they do not know, since your system will evolve into a Big Ball of Mud; it will be a mess.
2. We won’t be able to access the old data
This point I have found brought up when both;
- The old data hasn’t been accessed in years
- They have illegally kept it belong the time specified in the law
- They don’t use or need any of the data any longer
And yes, this data and functionality is still left in the database and the source code. It’s a nightmare to the performance, the code maintainance and the future development.
Solution: Archive the database, create a backup of the code, platform, take a virtual image and keep it ready for the day you might magically need your redundant, useless data that is 3 years out of date and useful to no one.
3. We might need it (even though we haven’t used it in a year)
This is self explanatory; You tell yourself or your colleague or your manager tells you that they may want to use the functionality again, even though it was considered ‘useless’ until 10 seconds ago. They then tell you that just in case we must keep the functionality! Or that removing it may break something else. This is sloppy behaviour and bogs developers down trying to keep up old, useless code that may be used once in a term, in which case it may be better to do manually, if possible, or not at all.
Solution: Do not keep the functionality. You have a much better chance at improving what was there before. Archive the code, keep the documentation, and depreciate it. Make it clear that if you use it again, you will be making a better job this time to make sure it doesn’t become “useless” again.
4. We can’t upgrade our software or platform version since it might break <insert old functionality here>
For developers, you’ll likely recognise this misnomer appearing over and over in the quest to try to have the newest functionality of your language in your toolkit. Admittedly, there are times when you break everything by upgrading, but more often than not, that ancient useless random and cryptic format A to format Z converter that you’ve never seen used anywhere that is only usable with MostRecentVersion– is just holding your team back from having NewSuperCoolFeature. You try telling UselessManager that your productivity would be increased, but UselessOldFeature is exceptionally important to him. You might put this down to a lack of knowledge of the system (point 1), but I’m more likely to say that it can be removed, or rewritten to meet the new platform.
Solution: Don’t let dead-weight hold development in the stone age. Tell your manager clearly that you’re going to need to upgrade. If he doesn’t understand, get the whole team, write up a proposition clearly explaining the losses he will incur without this change. And, if there aren’t any, then perhaps you also need to consider whether NewSuprtCoolFeature is just a toy for you.
5. Client X refuses to upgrade, so we have to keep maintaining the old functionality
At this point, unless your business is critical without ClientX, do your best to move on without them. This chain of software inflexibility will only get longer. Remember; we’re all stuck having to develop for IE6, WindowsXP and other ancient systems for a reason.
Solution: Move on.
Any more suggestions or criticisms of my list below?