Almost any organization that develops software for internal or external use will sooner or later have to face the issue of technical debt. That’s especially the case if the organization depends on legacy apps for some of its critical business processing. Because technical debt makes it extremely difficult for a company to maintain and update its apps to meet changing requirements, it can significantly diminish the organization’s ability to achieve its business goals. A report from McKinsey puts it this way:
“Poor management of tech debt hamstrings companies’ ability to compete.”
But before a company can deal effectively with its technical debt, there are several questions it needs to answer: what, exactly, is technical debt, why is it so problematic, where does it come from, and what can be done about it? Let’s take a brief look at these issues.
What is Technical Debt?
TechTarget explains technical debt this way:
“Software development and IT infrastructure projects sometimes require leaders to cut corners, delay features or functionality, or live with suboptimal performance to move a project forward. It’s the notion of ‘build now and fix later.’ Technical debt describes the financial and material costs that come with fixing it later.”
And the financial costs can be substantial. The cost to companies of “fixing” their technical debt is about $361,000 for every 100,000 lines of code, and that number is even higher for Java applications.
As with financial debt, an organization can carry its technical debt load for a while. But because it severely limits the ability of apps to integrate into today’s cloud-based technological ecosystem, sooner or later the debt must be dealt with. Otherwise, the company won’t be able to keep up with the rapidly evolving demands of its marketplace.
Where Technical Debt Comes From
In a recent Ph.D. dissertation, Maheshwar Boodraj of Georgia State University determined that there are five major sources of technical debt in software development projects. Let’s look at each of them.
1. External Factors
This technical debt arises from outside the organization due to conditions or events that are beyond its control. For example, developers may inadvertently introduce technical debt into their applications by using or integrating with external technologies the team doesn’t control and may not fully understand. Technical debt can also be introduced by contractors who work to standards that are different from those adopted by your organization.
2. Organizational Factors
Deficiencies in a company’s organizational structure or practices often generate technical debt. Here are some factors that may cause that to happen:
- Misalignment between business and technical stakeholders. Business representatives, who may not fully understand the technology, sometimes exert undue influence over technical seo decisions. Requirements statements may be incomplete, constantly changing, or worse, missing altogether. Additionally, developers may feel they don’t have the freedom to push back against requirements that violate their budgetary, schedule, or programming practices constraints.
- Inadequate resources. Technical debt can result when developers lack the financial, human, or technological resources they need. An inadequate budget can limit the acquisition of needed talent or technical tools, leading developers to take short-sighted shortcuts.
- Inadequate leadership. Technical debt may result when leaders don’t provide a clear vision, careful planning, and a long-term rather than short-term focus. Such conditions often lead to high staff turnover, resulting in a loss of institutional knowledge that will inevitably be reflected in the codebase.
- Not prioritizing technical debt. Technical debt will persist if the organization fails to devote enough time and resources to managing it.
- Unrealistic schedules. When the pressure of meeting unrealistic delivery schedules causes developers to take shortcuts, the incorporation of significant amounts of technical debt is inevitable.
3. People Factors
Software development teams function most effectively when members understand and abide by appropriate coding standards and best practices. To consistently implement those standards, team members need the requisite skills, experience, training, and commitment.
If any of these are missing due to inexperience, inadequate leadership, bad team dynamics, self-serving attitudes among team members, or low morale due to stressful conditions, the team won’t have the cohesion necessary to successfully manage technical debt.
4. Process Factors
Effective development teams consistently follow a process that enforces appropriate standards and practices. Minimizing technical debt requires a process that enables:
- Adequate focus on both business requirements and non-functional requirements such as usability, reliability, scalability, performance, and security
- Appropriate coding standards that ensure proper code reviews, adequate documentation, comprehensive testing and QA, and ongoing refactoring as necessary
- Proper definition of the minimum viable product (MVP) for each release
- Adhering to the Continuous Integration and Continuous Delivery (CI/CD) paradigm
- Avoiding morale-draining team dynamics, such as too frequent or over-extended meetings, lack of proper communication among and between teams, and inflexible procedures that make responding to unanticipated conditions difficult or frustrating for team members.
5. Product Factors
An application that has a substantial amount of technical debt will usually be marked by one or more of these characteristics:
- Complex Code that’s difficult to understand, maintain, and upgrade
- Duplicated Code that appears in multiple places in the codebase
- Bad Code Structure resulting from the use of inappropriate development frameworks, tools, or abstractions
- Undisciplined Reuse of Existing Code (including code from open-source libraries) that may be carrying its own load of technical debt
- Monolithic Architecture that is by nature difficult to understand, adapt, or refactor
- Ad Hoc Code Fixes added over time (and often inadequately documented) as bug fixes or new feature implementations
- Poor Architectural Design resulting in a codebase that’s fragile, complex, opaque, not easily scalable, difficult to maintain, and too inflexible to integrate into the modern technological ecosystem
Related: How to Measure Technical Debt for Effective App Modernization Planning
Techniques for Managing Technical Debt
The place to start in managing your technical debt is to first understand what you want to accomplish. Then you must ensure that you have the organizational structure, people resources, and proper coding standards and practices to get you there. Finally, you’ll need to implement a process for refactoring your existing apps. Let’s take a brief look at each of these issues.
What Needs to be Accomplished
In essence, eliminating technical debt in existing apps is about refactoring those apps from the monolithic structure that typically characterizes legacy code into a cloud-native microservices architecture, thereby producing a codebase that can easily be adapted, upgraded, and integrated with other cloud resources.
How Your Organization and Teams Need to Change
In 1967 computer scientist Melvin Conway articulated what’s come to be known as Conway’s Law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Since the microservices your teams will implement consist of small units of code that do a single task and operate independently of one another, you’ll want to structure your software development organization as a group of small teams, each loosely coupled to other teams, and each having full responsibility for one or more microservices.
The Refactoring Project
Start by analyzing your application portfolio to determine the architectural complexity and technical debt load of each app. You can then prioritize which apps should be refactored (modernized) and in what order.
That analysis will also provide the information you need to determine the budget, schedule, and required team member skill sets and experience levels for the project. And that information will, in turn, give you the ammunition you need to secure the required budget and resources.
Related: Using Machine Learning to Measure and Manage Technical Debt
Expect Pushback Against Dealing With Technical Debt
Don’t be surprised if you receive some pushback from other stakeholders in your organization. In a recent survey of senior IT professionals, 97% expected organizational pushback to app modernization proposals. As the survey report declares,
“Organizational pushback can hamstring projects before they start.”
The survey respondents were primarily concerned about cost, risk, and complexity. And that concern is warranted—modernization projects cost an average of $1.5 million, require, on average, 16 months to complete, and 79% of them fail to meet expectations.
That’s why being able to present comprehensive and accurate information about those cost, risk, and complexity factors to senior management is so important—it’s the best way to give them confidence that the benefits of dealing with the technical debt in your application portfolio will far outweigh the costs and risks of the project.
You Need the Right Analysis Tool
Trying to manually assess a legacy application portfolio that may contain multiple applications, some with perhaps millions of lines of code, is a losing proposition. That process is in itself so time-consuming and potentially inaccurate as to inspire little confidence in the estimates produced.
What’s needed is an automated, AI-enabled analysis platform that can perform the required static and dynamic analyses of your applications in a fraction of the time required to do the job manually.
And that’s exactly what vFunction provides. The vFunction Assessment Hub can quickly and automatically analyze complexity and unravel dependencies in your apps to assess the level of technical debt and refactoring risk associated with each app and the portfolio as a whole. Then, the vFunction Modernization Hub can automatically refactor your complex monolithic apps into microservices, substantially reducing the timeframe, risks, and costs associated with that endeavor.
To see first-hand how vFunction can help you manage your technical debt, request a demo today.
