Garbage Collection (of Outdated Systems)

2149602644_d44914d96d_b

I envy greatly all the newly minted start-ups. They have no legacy systems to support and all possibilities open. But if you are a company running for several years with steady source of income you end up with a large number of legacy systems with most of them being outdated. And it's not only that development of new features is slow and maintenance costs are high. The biggest problem with legacy systems is that they siphon you into a particular way of thinking. Instead of thinking what nails are worth pounding, having a set of hammers in your arsenals make you pounding the same sets of nails all over again. Getting rid of legacy systems is incredibly difficult. First, there's the author of the system. Even though it's usually a love/hate relationship the author is always emotionally attached to the product of his or her hands and he or she is sabotaging any efforts to replace the system (even unknowingly) in myriad different ways. Second, it's always more easy to shovel new functionality into an old system than creating a new system and build interfaces to old systems. With tight schedule and short-term focus starting a new system is never an optimal choice in the short run.

In my experience the only reliable way to get rid of the outdated systems is bankruptcy (nobody ever bought a legacy software system on purpose, so legacy software is never even listed in a liquidation sale). Second option to get rid of an outdated system is termination of a product. This is already less reliable option as forces of continuity will find a way how to reuse old systems in new products. The third option, replacing an outdated system with a new system, is doomed to fail. Two thirds of such initiatives are outright cancelled, while the rest are only pushed through because managers are too embarrassed to admit failure.