Legacy software, in some ways, is like an old house. There are features that one might consider defects, errors or poorly implemented designs. A badly hung door. A sink in the wrong spot. Not enough outlets in a room. But the inhabitants adapt, cope and even harness utility out of the malfunction.
They implement patches, fixes, and add-ons to address the *issues*. But they never truly fix all of it. Instead they run more extension cords, tighten the hinges every month, or modify their behavior for washing, cooking or cleaning. They work with the old house, and the legacy software….accepting it as incomplete and adequate enough. A sort of perfection in imperfection.
Just as with software, houses have features that are too costly to fix, too embedded within the culture to remove, and too risky to replace. Is this acceptance of mediocrity or recognition of reality?
The plateau of legacy software is marked by this adaptation and acceptance of what is. There is no more striving for a better, greater product; there is just a kinship with the present. The power user rules this lifecycle. He or she knows the tricks, short cuts, bugs-but-also-features, and data rules of the product. They become one with the development team and a common bond forms.
Old software is the stock of the enterprise IT shop. Reliable, if only because we know how it doesn’t work. Dependable, if only because we know how and when it will fail. Usable, if only because we’ve learned to accept its flaws.
Pragilematic 