Time, cost & risk of change

As the graph below clearly shows, most legacy software systems live in a conservative ecosystem that’s inherently resistant to change:

Everything about this system is unproductive. Because so much time is given to fixing legacy bugs and maintaining the system, productivity and quality suffer. And with time-to-market so drawn out, confidence gets eroded. For teams stuck in this IT bottleneck, adding to costs by experimenting with new features isn’t exactly high on the list of priorities. But in a monolith culture, it’s easy to fall into this trap. It’s just as easy to lose sight of the bigger picture. The fact is everyone wants an inverse graph where the time, cost and risk of change are significantly reduced. When this happens, the appetite for innovation increases and everyone has more time to focus on the things that matter. So how do we restore confidence and free up resources?

Reversing the legacy trend

First off, let’s dispel the notion of a quick fix. As Frederick P. Brooks famously put it, there is no silver bullet. The smart approach is to start small. Identify the friction points and apply some short, sharp, effective changes. That process starts with automation. With monolith systems, IT managers get caught up in a never-ending game of whack-a-mole. All their time is spent on patching the system with only one net gain: mounting technical debt. But even automating one key process, like redeploying a web-based application to the cloud, can have positive effects.

Thankfully, for every pressure point there’s an automation solution. And for the most ancient legacy code, there’s help out there from programming languages such as Bash, Python, Groovy and Powershell. Even the most siloed legacy system can benefit from automated builds and release creation packages. With just a few key agile changes in place, the future tasks of testing, delivery and deployment suddenly seem a lot easier.

Incremental delivery

Automation and incremental delivery go hand in hand. The good news is that every time you want to fix or update, you can be sure that building and packaging will work seamlessly. And the delivery of each separate component means one less build to worry about, reducing overall development time. One of the reasons no one wants big complex releases is the associated risk. Let’s face it, error tracing at 2 am is a fate no sleep-deprived IT pro wants to suffer more than four times a year! Once you shorten a build-release-deploy cycle from days to minutes and make that practice “business as usual”, confidence grows in all departments. Watch the belief in your enterprise build with incremental delivery.