Obvious Statements About Software Change Management: #6 Multiple Versions of the Same Application Resurrect Bugs
Most of us need to maintain multiple versions of the same application. And even if you think you don’t, you really still do for a variety of reasons.
Suppose you have an application in production that you must maintain. One of your programmers is working on a large project and this involves radical changes to an important number of your software components.
In the mean time, your customers (this includes end-users) may find a bug in the code running back in production. If that bug is serious enough, it must be fixed before the official release of the big project.
After the quick production bug fix, your programmer still maintains a version of that same program but with the bug still alive. If the release is installed, the bug has “risen from the dead.”
Your company will have this problem all the time if you must maintain multiple versions of one application. A good illustration would be an independent software vendor. Users report bugs on all versions and the ISV must manage every occurrence of each component.
Another good example is a company that must maintain various versions because of country specific changes. Code in the base and in the variants are subject to the "Zombie Bug Pattern".
If a software component was copied to the next version before a bug was solved, then you have replicated the same bug.
In such case, wouldn't it be a good idea to have a good version control system? TD/OMSis the first application lifecycle management solution to offer the so called "social" code reviewing function which allows all developers to review code of other developers in order to find bugs or pieces of code that can be improved. Such way of work improves code correctness and ensures high quality of developed / maintained applications.
The author, Wim Jongman, is managing director and CTO at Remain Software