Photo by pshab
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Monthly Archive for April, 2008
This is my second post about backward compatibility in software, the first one was dealing with the project management aspect of software compatibility, this one talks about bugs and how, sometimes, correcting a bug can break compatibility.
First of all, coming back to my previous post on the subject, deciding whether or not to break the backward compatibility of an application is a project management matter. The decision that correcting a bug will break compatibility must not be left solely to the developer, sometimes the company may decide that compatibility should be preserved even when it comes to bugs.
Raymond Chen, a well-known developer at Microsoft, has some good examples on his blog, The Old New Thing, to illustrate this. Raymond actually gives us a good insight at Microsoft policy concerning backward compatibility of its OS.
This post, from Joel Spolsky (another well-known ex-employee of MS) gives another good example with this leap-year-bug deliberately created for Excel/1-2-3 compatibility.
So, to make it short, when you correct a bug, incompatibilities can appear because:
- Either the bug as been detected and a workaround as been put in place. This workaround will have to be removed once the bug is corrected.
- Or this was not initially considered a bug and the behavior is going to unexpectedly change.
As an example, if an interface exchanges strings representing date and time and you later discover that the time zone is omitted from the format. If someone developed a parser for this date and time but never expected a time zone information, then the application will break. This is a semantic incompatibility, but one that is brought by a bug fix.
In the case where your management decided that bug for bug compatibility was not necessary, the incompatibility and its potential impacts should be documented in the migration release notes.
In the case where you have to maintain the bug to maintain the compatibility, I recommend you subscribe to Raymond Chen’s blog or stop writing bugs.
I just wanted to share this piece of true goodness with my friends out there and those I will never meet.
For most software companies the ability to ship new versions of a product that will preserve clients’ data and customizations is a matter of market share. Still, this is often an afterthought and there seems to be little documentation available.
This article is the first of a serie about managing backward compatibility in enterprise applications. This will not be a definitive guide but I will try to spot the common areas where incompatibilities can appear and give guidelines about managing them.
This first post is about the project management side of backward compatibility.
One of the most important thing to remember about backward incompatibility is that it is mostly a matter of process and project management.
In order to find the most accurate way of solving a compatibility issue you need to talk about it because the solution can be driven by technical, business or project considerations. Once a solution is accepted, the reason as to why this as been done that way must be properly advertised (this is of uttermost importance when only documentation is provided) and rolled-out.
As backward compatibility is a project concern it must be:
- Listed in the project risks list
- Considered at the project level
- Optionally considered at the product level (mostly when it has business impacts)
There are three ways to solve backward incompatibilities, they are listed from the most desirable to the one that requires the less developer work:
- Ensure binary compatibility - Work is done at the development’s level.
- Provide migration tools - Work is split between development and services but emphasis is put on development.
- Provide thorough documentation of incompatibilities and ways to overcome them - Work is split between development and dervices but emphasis is put on services
- Reject or postpone the change - Work is then at the product management level
Like for bugs, backward compatibility cannot be guaranteed at 100%, the best thing a project manager can provide is a good measure of the risk upon it for a given version.
When a new version is released, incompatibilities, those that have not been foreseen or at least documented, must then be treated like any other bug and become part of the maintenance process.
In the following posts I will focus on what can make an application backward incompatible and give some guidelines in order to limit those issues and ensure binary compatibility.
See also Backward Compatibility on Wikipedia.
I just created my first “Vote for me” badge, with InkScape, sooooo cool :)