Should you modernize

Technologists love to rewrite things — some new framework comes out, some new buzzword-worthy technology stack takes over, or some new architecture will solve all the world’s problems. But the reality is that any modernization project is fundamentally a business decision and must be driven by the business. There are a multitude of risks involved and each must be weighed against the rewards to gain a full picture of whether the modernization effort is worth the spend.

One of the key factors to consider with any modernization project is the risk of defect introduction. Whether the project is a complete technology switch requiring a rewrite of the software or a gentler upgrade to a new underlying library or stack version, the potential exists for defects to be introduced in the code base.

To illustrate the gravity and subtleness of even small defects, we need only look at the loss of the Mars Climate Orbiter. Briefly, two pieces of software that needed to communicate with each other used two different units of measure (metric vs imperial), resulting in incorrect calculations and ultimately the loss of the spacecraft to the tune of $327.6 million dollars. While this was new development work rather than a modernization project, it is easy to draw parallel scenarios in modernization efforts as they will ultimately result in some underlying library or framework change.

So one of the questions to ask when considering a modernization project is: “How much will a defect cost me?”. While the cost of a defect in “critical” software is much greater than, say, a business or transactional system, the cost should still be quantified in order to determine the severity of the risk involved. Once the risk is identified and quantified, analysis can determine the appropriate actions and mitigation strategies.