Interchangeable

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.

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.

bit.ly/1a66WAm