Maintaining Legacy Apps: Problems and Solution

Maintaining

Let’s start with a couple of true short stories from my first hand experience:

Stories about Maintaining and Enhancing Legacy Applications

Story 1: Aparna’s ERP

Aparna is a senior programmer from Pune. She has single-handedly wrote an ERP application for a dairy. Those who understand how complex an ERP is, can understand how much dedication and self-discipline such an accomplishment would need. Her client uses the application on a day-to-day basis, and is happy with it. As with any ERP application, enhancements are needed from time to time. Aparna also wants to scale up by implementing her ERP solution for other clients. She has a ready prospect. But they need some customizations before they could use the ERP.

After years of solo fight (with all the dedication and self-discipline that we talked about), Aparna has recruited some junior programmers to help out with these enhancements and customizations. But, is she able to offload the work to her developers successfully? The answer is a big no. Aparna needs to be involved for every small change, working out the minutest details. Is she stuck with it for life, she wonders.

Story 2: Kommbox

At Acism, we developed Kommbox a decade ago. The original developers who developed it are no more with us. With intent to replenish it and sell it in the market, we ran some initiatives in the past — such as adding new features, improving UI. Those initiatives were completed some times, and got shelved halfway some other times. There is a lot of code debris that Kommbox has amassed over the years. Recently, there is a renewed interest in Kommbox, and opened our closet again.

What we find isn’t pretty. The UI is disturbed in some places. Some pages look inconsistent with the rest of the application. The back-end functionality, which ran flawlessly before, now fails in some places. To our shock, we are now encountering some blank pages. Our QA engineer is reporting blockers after blockers. Ouch!

Fortunately, there is a method in the madness. I can intuitively sense the reasons why something must be broken, and can usually find a quick way to diagnose and correct the problems.

… However, the same cannot be said about our junior developer, Shubham. Shubham is new to the team. He does not have the benefit of being around when the code was getting developed. Figuring out every small thing (small thing for me!) takes him eons. His productivity shoots through the roof when I help him. I guide him primarily at the logical level. We find that some small things I know about the product make a huge difference.

Common Problem

Be it Aparna’s ERP or be it Kommbox, these cases are representative of the millions of legacy applications that are out there. Their maintenance and enhancement are highly dependent on the availability of someone who has worked with the system for long — such as Aparna or I. When such a person is not available, it becomes very difficult for the team to make changes. For this very reason, applications whose maintenance is transferred from one team to another face huge challenges in continuing to satisfy customers.

The knowledge that the long-timers possess is termed as tacit knowledge. It cannot be captured completely in documentation. It is some kind of neural structure that gets built brick-by-brick (or should we say, neuron-by-neuron?) over the years as one works with the code. The process of building this tacit knowledge is accelerated significantly when someone having this knowledge is available to guide.

If it is any consolation, this is a global problem. Your company is not alone in it. Your carefully designed codebase degenerates into a monster that’s difficult to tame, sooner or later. People having the tacit knowledge serve as a great asset in these situations. However, they become rarer and rarer as time goes by — creating a risk to your application.

Xsemble to the Rescue

This problem vanishes completely, if the system were built with Xsemble. Here is another true story on that…

Story 3: Maintaining Xsemble based Applications

Prior to Kommbox, the same Shubham worked on two other applications that were created with Xsemble. (Kommbox is not). The original developers who created these applications are not around. Yet, Shubham did not need this kind of assistance on them. Once he figured out how to understand the visual model of an application in Xsemble, after that he can just walk in and out of applications at will, fixing and enhancing them as needed. His technical skill level is the only limiting factor now. Lack of tacit knowledge is not.

Why It Works

So, what difference did Xsemble make in case of the other two applications?

There is a visual model that shows you the internal working of the application. This visual model is guaranteed to be current with the actual working. Using the model, one can visually identify the component(s) to change.

The code template is generated / re-generated as per the definition of component. That saves effort, and eliminates any productivity loss due to manual typos. Changes to the business logic are done within the generated code template. The developer is thinking of a single component at any time, which boosts productivity and improves speed and accuracy.

No developer has to worry about working out the wiring between the components. The glue code which does that gets generated automatically by Xsemble. In case of legacy application, it is the coordination of different moving parts in the code that takes much time and energy of senior programmers. That effort is completely eliminated now, along with all the manual errors that accompany it.

Primarily: the tacit knowledge that existed only in the heads of long timers, now gets captured as the visual model. It helps even a new developer, like Shubham, to quickly figure out the flow of the application and make changes.

Final Words

Here is a shout-out to all companies maintaining legacy applications. We know the challenges you face, and we also know the cure. Wouldn’t you want your applications be easy to maintain and enhance – in spite of inevitable team changes?

Let us modernize your existing legacy application to Xsemble. In case you have an application to be developed from scratch, then let’s do it with Xsemble from the beginning. Write to us and let’s figure out the best course of action.

[Attribution: Cover image by Elchinator from Pixabay]