Future Legacy Applications

The primary distinguishing feature of any one thing that has lasted the test of time is that there were probably a lot more of them back in the day.

Castles, bridges, forts, battleships, mainframes, PDAs, Blockbuster stores, software applications. All that survive, survive mostly due to luck rather than any lofty aspirations or far thinking designs by their creators (the monuments and monoliths that are the pyramids of Egypt and Stonehenge number the few exceptions).

On the surface, the Romans seemed to be pretty good at building structures that lasted. After all, there are bridges still standing that were built in Roman times.^[1]. But what we see are the few surviving examples, with many resting now in pieces at the bottom of rivers, ravines, or having been disassembled piecemeal to be used as raw materials in new construction projects. And much of what the Romans built didn’t last. Their apartment building skills, for example, left much to be desired.^[2]

With few exceptions, our fore-bearers likely had no notion their software would remain in active use twenty or thirty (or forty, or fifty) years after being deployed, by pack mule or camel caravan, into production. If they had, would they have thought to allocate an extra byte or two to store a four-digit year to head off the Y2K^[3] horror decades hence?

Memory and disk space were expensive and at a premium, so allocating a few extra bytes to a date field would have made no business value sense. Much better to kick that particular can down the road and into the sweaty paws of future hoards of willing consultants and contractors. This leads to a discussion on future-proofing versus the overwhelming urge to overengineer.

The divide between future-proofing and overengineering seems slim. They seem to be two sides of the same coin, or perhaps one side of two different coins.

Overengineering a bad or wrong design makes future-proofing that much more difficult. Like reinforcing a home to withstand a hurricane, using stronger materials will only allow the structure to withstand winds up to a certain magnitude. To withstand stronger winds the entire design needs to change, perhaps necessitating razing the home to its foundations and starting again.

Future-proofing is not about adding a features that you assume your users may ask for in the future. These features will go unused, effectively cluttering your business logic (requiring testing prior to each release, or being hidden by sweeping under a carpet of feature flags), or most likely when the feature is requested the requirements will be so different as to necessitate a rewrite.

A question that should be answered early on is what is expected business value to be gained by future-proofing, as this requires an investment of time and effort driven by architects and designers with some experience and commensurate skill. It is perfectly acceptable getting something out there as fast as possible and subsequently iterating until it becomes good enough (There are exceptions to this approach when working in the financial, health, regulatory and hardware domains.)

Creating a "Google Scale" architecture from the outset brings with it Google scale problems.^[4];

In reality there comes time where parts of the system will have to be redesigned and rewritten. Twitter, Netflix, Reddit are examples of companies where the only answer to continued growth was re-architecture. And that’s OK. It took Netflix something like five years, starting from their massive customer facing outage of 2008, to finally complete their migration to microservices. That’s a long time. And like Netflix, you will to have to live in your home as it is redesigned to withstand an F5 tornado simply because it is impractical to feature freeze legacy systems while engineering resources are moved to busy themselves creating a new system from scratch.

The business won’t stop demanding new features for the guesstimated six months to a year that it will take to build a new system (See Netflix above.) Features will continue to be added to the old system by the very developers who are becoming increasingly annoyed that they are stuck maintaining the legacy system while their colleagues get to play with the new shiny. And when the new system is finally "ready", well, it can’t launch without supporting all the features that were added to the legacy system in the meantime. All because Product rightly thinks that customers will riot and jump ship. Netscape tried and ended up losing all market share and subsequently going out of business.^[5] So don’t do that.

An alternative is to brand a new product or service around the new architecture. New customers are drawn to the shiny and sign up. Existing customers are incrementally (voluntarily or involuntarily) migrated as the features they care about are rolled out. When customers using the old system approach zero you can begin to discuss the plan to sun-set and subsequently pull the plug.

Or maintain both products indefinitely. This has a cost but you now have two products and both have paying customers.^[6]

There was once a culture, not too long ago, of repair not replace. Computers, phones, TV’s, VCRs, shoes, clothes. If you yourself couldn’t repair it you took it to someone who could because buying new was expensive. But did this culture influence the approach building software? Well developers being developers, so the answer is most likely no. It’s hard enough trying to recall that went through your head looking at the code you wrote last Wednesday at 2am - never mind the non-thoughts that may have passed through the mind of anyone else. And what few comments there are in the code are all wrong anyway. Much easier to rewrite from scratch.

New is cheap. The availability of Frameworks, libraries, third party SaaS solutions, mean standing up a new thing is relatively easy, but having the new replace the old is not. See the Ninety-ninety rule.^[7] Plenty of horror stories recount failed efforts to replace legacy systems due to massive schedule and cost overruns, or the new systems don’t perform quite as expected (or at all) when in production.^[8]

It seems that we have always been in a mess of our own making.

A good approach is to strive to architect for simplicity. Make the system as simple to change as possible (or put another way, don’t make the system more difficult to change than necessary - I got this from somewhere. Google currently fails me, I’ll add a ref when I find it.) Software is resilient when simple. Complex software is brittle. It is easy designing complexity. It takes work and time to design simplicity and requires a level of experience on the part of the architect or designer to design for change without overengineering.

Minimize external dependencies where possible.^[10] And examine the development history for those dependencies that you do choose. If your architecture will rely on a platform, SDK, virtual machine, framework, API, or service, how long typically does that dependency go without a backwards incompatible breaking change? Six months, a year, thirty years, indefinitely?

It’s fine to rely on dependencies that have a history of making braking changes, or service providers that have a history of regularly turning off features, ending products and breaking APIs. But go into architectural decisions with eyes wide open.

Remember than in a years time, when you are already overloaded with bug fixes and new feature requests, you may also be forced to rewrite your application from the ground up due to a decision that you are making now.

It is not just the source code and assets (localization, not just art) that should be versioned. Version everything. Libraries, SDKs, build, test and deployment pipelines, tool chains, scripts, configuration files, perhaps entire environments.

When old software needs to change it is usually time-critical. Taking a week to debug how to actually rebuild the code is just unacceptable.

Ownership means that software is within your sphere of influence to change or not.

So, how can any software that is older than five years continue working?

Applications that ran on "big iron" were somewhat resilient to change just by the nature of the environment and the type of work performed.

Thus, modern IBM mainframes can continue to support many applications originally running on IBM hardware introduced in the 1960s^[12] (One of the reasons to pay for support contracts.) And when the manufacturer of your mainframe/minicomputer went of business, third party commercial emulators became available for old PDP, Vax, Alpha, SPARC, and HP3000 architectures that run in the cloud and on commodity hardware.

The amount of engineering needed to maintain the decades of investment that are applications is considerable.