A mistake developing organisations often make is to believe a released product doesn’t need further attention. The product is released, to external customers or to be used internally, but no resources or plans are made to update the product. A build has also the tendency to make developers tired, something they want to tuck away to start a completely different branch. Product releases can never be neglected, though, unless the product will be retired within a year. If key products are not maintained, they will prevent future upgrades of hardware and operating systems; other products will also suffer as they won’t be able to interact safely with obsolete products. It results in a software and hardware environment that costs more and more to only keep running. A released product therefore needs constant attention, because of a new operating system and third party software releases. It doesn’t matter if any major releases are planned for, applications still need constant attention and regular updates. Software libraries and kits are regularly deprecated, even if most releases still can use them, but they must sooner or later be upgraded or replaced. Deprecated software often contains old technology that could turn into security problems, but the main reason is how it won’t satisfy architectural needs, and that affects everything in the long run. It is all about interoperability, how libraries and kits collaborate and work in a changing environment, and about evolvability.
The worst position a provider can put themselves in is to ignore a released product, making future upgrades of hardware and 3rd party software almost impossible. It not only affects performance, but security, usability, and the correction of critical failures. Legacy becomes a problem when it should be a foundation that facilitates new functionality.
Legacy must be taken into account from the start when a new product is planned for and built. Teams must be aware that the legacy will put a mark on all future releases, either these are less important or more significant, like upgrading 3rd party software or adding new capabilities. A bad legacy can force the whole software to be rewritten.
Legacy is also about how the software is packaged and documented, either for internal development or for independent software vendors. Apple has always documented Mac OS on routine level from the start, for independent developers to use QuickDraw and other functions in the Macintosh Toolbox. It was a strategy with the Macintosh, to interest 3rd party software vendors, make them bet on Mac OS and develop much needed applications. Apple still does it, although developers need to participate in the Apple Developer Program.
Most system vendors view their software as part of a product they sell to a customer, and it therefore doesn’t need to be documented on routine level. The vendor can document sub-products they hope will be incorporated in other, sellable products, but the sub-products can contain open source and proprietary software that is hard for other parts of the organisation to use without alterations. Sub-products must often be tailored and adapted to work with the architecture of a sellable product, which in reality makes sub-products incompatible with the legacy. Documenting and managing software on API level, including class level, becomes a question about productivity and if traceability is that important. Most managers probably see it as an unnecessary cost, when it is the true legacy everything is built on.