Software Modernization For Legacy Software

Originally published on Forbes Technology Council.

The term “modernization” holds diverse meanings for different organizations. To some, it means buying new software or developing a custom solution. For some others, it means taking a strategic shift towards cloud-based solutions like Salesforce.

Regardless, the pivotal question here is: When is the right time for an organization to embark on such a transformation? To understand this better, read on.

Overview

Writer Michael C. Feathers stated, “To me, legacy code is simply code without tests.”

Why would he say this? Software without tests inhibits its ability to change fast. Today when SaaS software is so common, it’s not only the software without tests but software that lacks any continuous integration and deployment (CI/CD), infrastructure as code, coding standards, incremental changes, observability and practices like test-driven development (TDD), pairing, refactoring and small releases.

In my experience, I’ve found that the following company archetypes typically struggle with technical debt:

• The well-established: Stable companies with software expertise and tech-savvy staff that typically resist change
• The people pleaser: Companies that prioritize feature additions and neglect implicit software needs
• The new kid in the town: Funded, growth-focused companies that neglect non-functional requirements
• The dependent: Companies that lack in-house expertise, work mainly with vendors and listen to internal experts.

Legacy System Symptoms

Technical debt issues are neither directly nor easily visible, nor do they appear as bugs. They enter the ecosystem so slowly that you don’t know when they become a way of life or a way of functioning. Here are eight of the most common symptoms found when working with legacy systems:

1. End users finding bugs

2. New changes that introduce unexpected bugs

3. Slowing down changes seems to be the only option

4. Because released changes break things, there are change approval committees and boards (CAB) that slow down everything by “reviewing” all software changes

5. High team attrition

6. The feeling that everyone is running around but nothing moves

7. Time spent waiting for something to happen

8. Lots of manual processes, including email writing

When To Act And Find Experts

If you feel you need help with tech debt-related pains, I’ve come to find that, most probably, it’s already too late in these scenarios. However, consult with an expert if you see the following in your system:

• Dipping customer happiness because of bugs

• Customers resisting upgrading versions

• Customer needs are not being met because it takes time to release new changes

• Long manual QA cycles

• Painful new engineer onboarding

• Frequent hotfixes

Causes Of Technical Debt

Technical debt is accrued due to various issues ranging from organizational behavior to technical choices and shortcuts. A company must respond to market needs, and sometimes it makes sense to take shortcuts, making choices that may not be the best tech decision but may be best for the business.

Remember, poor-quality code is not technical debt. That’s just bad programming. Companies get into a cycle of accruing technical debt because they never make a list of all such historical shortcuts and never get back to them to pay them off.

Just like financial debt, you must repay it month to month and account for it every time you make any expense (in this case, when you write code).

Let’s go through six examples of decisions that may increase technical debt.

1. Writing duplicate code while you could use existing code from the codebase

2. Using an older version of third-party libraries.

3. Ignoring coding standards

4. Bypassing testing before committing new code

5. Lack of collaboration and code review

6. Ignoring non-functional development

Risk Factors

Additionally, there are some factors that may increase your risk of accruing technical debt fast. All of this starts early in the product development lifecycle because people may be chasing the initial illusion of speed.

What behaviors increase tech debt? This could be a lack of engineering discipline, a bias toward a “quick and dirty now, clean it later” approach, or accelerated hiring, just to name a few.

Complications

While it may seem that the technical debt only has to do with the time to develop it, many other complications are raised because of it. This includes security issues, dependency on end-of-life components, manual errors and loss of money.

Prevention

To prevent these risks, adopt engineering disciplines and practices like:

• TDD

• CI/CD

• Issue postmortem

• Mob reviews

• Trunk-based development (this only works if you are a very disciplined team)

• Prioritizing non-functional requirements

• Continually improving and refactoring

• Promoting a culture of continuous learning

Treating Legacy Code

Treatment of legacy code is more like exercise, as opposed to a painkiller. One must consistently prioritize non-functional requirements directly impacting one of the following DORA metrics:

1. Deployment frequency

2. Lead time for changes

3. Mean time to recover

4. Change the failure rate

Remember, technical debt has to do as much with organizational behavior as it has to do with technology. To start treating it, start with the following:

1. Decrease the batch size. It has the highest impact on all these measures

2. Increase psychological safety

3. Decrease work in progress (WIP)

4. Promote pairing, as it will decrease the change failure rate

5. Get skilled at flawless deployments

Conclusion

In the ever-evolving landscape of technology, modernization is a complex and multifaceted endeavor that encompasses much more than merely adopting new software or moving to cloud-based solutions. It is intricately tied to an organization’s ability to manage technical debt, align its processes with contemporary practices like CI/CD, TDD, and refactoring, and foster a culture of continuous improvement and learning.

The signs of technical debt may be subtle, but they are insidious, impacting not just development time but also security, reliability and financial stability. Treating legacy code and technical debt requires tools and techniques and a shift in organizational behavior and values.

Whether you’re a well-established company or the new kid in town, acknowledging the risks and embracing the disciplines to prevent and manage technical debt will be paramount to your success in this era of rapid technological change. The time to act is now because waiting until the symptoms become painful might be too late.