Back to the future — part 1: failures & rewrites

Legacy software stories

Everyone likes to discuss new technologies. Yet, the (sad) reality is that more people work with legacy stuff than with new, clean & shiny solutions. The reason is simple. We keep creating software each year in massive amounts, and most of it does not disappear. It keeps value for longer and longer periods of time, and in many cases, it remains relevant over the years. The legacy grows around us and there is no escape! This is why we need to learn how to deal with aging software. Taking into account all of the above, we decided to share our experiences and write a series of articles on this topic. The series will show some of our ideas on how to go back to the future with your legacy, enterprise applications. So, let’s get started!

What is legacy software?

First of all, we need to agree on what legacy software is. One way of defining this notion is looking at the underlying technology. If I say legacy, most of you would typically think about Mainframes with Cobol or PL/I, etc. Some of you will also think about two-trier applications with rich business logic in the database. We can continue by adding some of the younger siblings like old Java / JEE applications and .NET.

Maybe your current, existing legacy software looks like this good, old Warsaw car.

Year by year, the number of development technologies grows. Year by year, the number of technologies that we can call legacy grows just as fast. Due to this trend, a lot of JavaScript applications, which may seem fresh and modern, should also be considered legacy by now.

Summing up, some technologies (like Cobol) are legacy without any further questions, while for some others (like JS) we need to look deeper to decide.

Next step is to look at specific problems. In legacy software we typically experience a set of common problems. Firstly, modern tools are not available. Simple activities like creating a release, deployment, building, etc., need to be done manually. Integration with your favorite IDE, building an effective Continuous Integration / Continuous Deliver pipeline may often seem hard. Things just do not work out of the box. Furthermore, there is no up-to-date documentation or vibrant community, so finding help on the Internet is almost impossible. Magical knowledge, secret scripts on local computers, “ask Jack, he did it 2 years ago” advice… we’ve seen all of that and much more. That all leads to the fear of doing nothing more than putting an IF statements to the source code. Coders (especially younger), are often afraid to touch anything, so they follow this omnipresent pattern:

IF (my_new_super_specific_condition) {
  // my new code
} ELSE {
  // some old code I don’t understand
}

Which, eventually tends to grow further, leading to:

IF (my_newer_super_specific_condition) {
  // my newer code
} ELSE {
  
  IF (my_super_specific_condition) {
    // my new code
  } ELSE {
    // some old code I don’t understand
  }
}

Effectively, this leads to maintenance nightmares and very slow development resulting in poor quality at the end. Summing up, the costs grow in time.

So finally, how can we define legacy software in simple words? Basically, it is a software that nobody likes, nobody knows, and probably nobody wants to know.

Of course, it is also a software that still has a business value. If nobody uses an application or if it is in use but can be easily replaced, then it is not a legacy in our sense. It is only a piece of history, which should be forgotten.

Having defined what legacy software stands for we can ask: “What can we do with it?”.

“Rewrite it all” strategy

The most obvious idea is to rewrite it at all. Potentially, it solves all our problems, which is great! And it may look simple, but it’s not. In reality, we saw around 6 big failures, heard about 5 more and finally we know only one, real success story with a rewrite of a complex, enterprise class system. Why were there so many failures and tragedies?

Do you think your rewritten software will look like this? (photo courtesy of www.classicins.com)

The answer is simple — complexity! Both kinds of it — the underestimated and the overestimated. Very often behind a legacy system there are thousands of man-days of work done by different kinds of developers — too lazy, too smart, wannabe smart, geeks, juniors, mids, seniors, part-timers or die-hard’ers. All of them left something behind creating a complex beast. If you ignore this fact, you will underestimate the required effort.

Do you remember what we said at the beginning? Legacy software is a software that nobody likes and knows. It’s easy to find an application with only one developer, who has been working on it for 10 years. If you ask him if it is complex, you will probably hear “it is complex as hell — you need 100 man-days to rewrite this single form with two input boxes and one button”. This kind of estimation leads to the creation of so-called corporate legends — “Don’t touch it, it is too complex”. Have you ever encountered it? Probably yes! And this is one of the examples when we fail to look correctly at a project due to overestimation of complexity based on false assumptions.

So, the question is: how to estimate correctly?

Well, talk is cheap, show me the code, Linus Torvalds said. In our opinion, good estimates should be based on a reference implementation. If you don’t have anything to treat as a reference, code it — do a proof of concept. Rewrite one or two representative functionalities in a new tech stack and / or using a new architectural paradigm and then use it as a reference to estimate the rest of the system. In one of the upcoming posts, we will write more on building effective estimates for complex software development task. The key advice for now is: “Don’t use magic numbers — use complexity.” … and planning poker is welcome.

Let’s assume you’re done with estimating the complexity. At least on the high level. Are you done with estimating at this point? Definitively not! In order to move forward, we need to confront the complexity (which further translates to effort) with the expected gain / value of the rewritten software. What will be the return from this complex investment? Does it make sense? And again — this is not about organizing a series of meeting to discuss your corporate mythology or beliefs of the senior team members (who typically will tell you things like: “I don’t believe that there is a better ERP than the one I’ve been working on for the last 15 years”). This is about facing solid facts and measuring potential income. Look at your strategy, your core business, where does your business unit takes the money from etc.

All this hard work should bring you to a decision point. You need to be discussing facts and figures not legends, feelings or beliefs, and ultimately you need to decide for or against a complete rewrite. From our experiences in many, many cases your choice should go against it! What to do then? This will be the topic of our next post in the series “Back to the future”.

Stay tuned!

This article has been co-authored by: Witold Bołt.