Code is probably the most important part of our software. Different programmers have different coding styles and in attempt to even out these differences, some companies have developed their own styleguides. The quality of the software can be guaranteed only if the code is easy to read and understand, requirements-friendly, maintainable, testable, safe and secure, independent, robust, fast, portable, valuable. But we often forget that it must be interchangeable too.
Very often we rely on different software components that were developed outside our own companies. They exist independently and their versions change frequently. When a new version is available, our software needs to know that in order to get the update automatically on the dependencies it uses. We can think of these incremental updates as if a new component is replacing an existing one. In most cases these components will be interchangeable—we can either keep the newer version or revert to the previous one. Since they use the same interfaces, only implementations will vary in a way that is hopefully completely transparent for the end user. But interchangeable doesn't need to relate only to components that come from the same place.
If a child is playing with Lego bricks and loses one part, it can very often find a duplicate one and still build its construction. Many of the Lego parts are interchangeable. This helps to eliminate some of the possibility that nothing at all can be built. Individual parts shouldn't be allowed to carry the value of the entire construction.
If a patient is bound to a pulmotor, which suddenly ceases to work, there wouldn't be much time to call the technicians, communicate the problem and let them look for replacement parts, especially when the patient is dying. The machine has to be able to discover what went wrong, give proper feedback or signal and immediately replace the failed component with a new one. The proper software allows the machine to remain operational and to inform people of the necessary delivery and installation of the new part. In this case interchangeable components make the machine fail-safe.
Imagine that a company has a problem with one of its software modules, leading to unpredictable behavior on some systems. The developers could attack the problem in the next version, but customers will have to wait, which may force them to seek another provider. Another option is to bring back the older version, but since customers have seen the latest improvements, they may be reluctant to go back. The company faces a dilemma in which the most accurate decision seems to be further development. Although the interface has remained stable, the problematic implementations have made it less usable. The two versions were not exactly interchangeable. If that company has worked together with an outside partner that develops similar software and both companies have agreed on a common interface, that partner might have been able to provide a plug-in replacement for the failed component or at least the know-how needed to fix it. Partnerships can also be effective in search of interchangeable components, which is why more and more companies are willing to look outside their inner workings.
For software to become interchangeable, we need to ensure that random parts from it can be easily replaced if necessary. This allows us to concentrate on improving the important without worrying of the urgent.