Skip to content

When software assets become liabilities

Annually, staggering sums are invested in software development, with the resulting intellectual property often classified as an intangible asset by the financiers. However, the reality can be less than ideal: systems developed at great expense frequently require continual, escalating budgets for maintenance and support.
Jan 16, 2024 1:15:30 PM Mantas Urbonas


As features become more time-consuming to implement and the product struggles to match competitors, the dilemma intensifies. Compounding this issue, talented programmers begin to depart for reasons not immediately apparent, and finding replacements becomes a Herculean task. This exodus is often attributed by both CTOs and HR departments to our code becoming "legacy" – transforming an asset on our balance sheet into a burgeoning liability.

What is a "legacy" source code

In programming parlance, "legacy" refers to projects that are outdated and challenging to maintain, enhance, or debug – in essence, they are cumbersome to work productively on. A synonym often used is "spaghetti code," denoting a convoluted and chaotic structure. The term carries a distinctly negative connotation among software developers.

Yet, how does a project, only a few years old and not fully released, suddenly become antiquated? What precipitates this premature obsolescence of an asset developed by top-tier professionals using cutting-edge technology? Externally, our product may appear functional, garnering customer feedback, yet an insidious decay permeates its thousands of code lines, rendering even minor improvements laborious and time-consuming.

The answer lies in the subtle nature of virtual assets compared to physical ones, which are straightforward to assess. Programmers, under pressure to deliver, may overlook long-term implications, leading to a gradual accumulation of minor flaws. These issues, initially imperceptible, become glaringly evident later when new programmers confront the daunting codebase.

Contrary to belief, not all software is destined for rapid obsolescence. Numerous products, decades old, still boast high-quality functionality and code health. Such longevity is attributable to the original developers' proactive efforts to prevent code decay – a practice, unfortunately, more the exception than the norm.

How to know if a product has source code hygiene problems

If your company owns software intellectual property, chances are it harbors some legacy elements. Early detection signs include:

  • Code Coverage: According to Michael Feathers, if a computer program doesn't have automated quality checks called unit tests, it's a clear indicator that the code is considered legacy or outdated.
  • Utilization of Tools: Continuous assessment of code hygiene via static analysis tools can provide an approximation of the effort required for improvement, alongside quality trends.
  • Feedback from Sales Team: If incorporating new features is increasingly sluggish, it indicates deeper, systemic issues.
You tend to get what you measure. In cases where the development wasn't assessed using internal quality KPIs, the resulting internal quality will naturally be quite random – relying on the professional ethics of each individual team member.

How widespread is it and what are the remedies

Both public and private sectors grapple with legacy code. Public sector software tenders often fail to emphasize internal quality in their specifications, leading to systems that meet functional requirements but become costly to modify. In the private sector, financial constraints often lead to a focus on immediate survival over long-term code health, resulting in accumulated defects over time.

Organizations typically face two paths when dealing with legacy code:

  • Palliative Care: This approach involves maintaining the system as long as feasible. However, poor code quality slows new feature development, hampers security patching, and erodes market share. Additionally, recruiting engineers for maintenance becomes increasingly challenging, upsetting financial forecasts.
  • Complete Rewrite: Starting from scratch is a viable option but costly. It mirrors the original development timeline and can lead to business stagnation. Newly developed systems might omit crucial features, and migrating data and customers presents its own set of challenges. Importantly, a rewrite does not guarantee improved quality.
  • A Third Option – Gradual Modernization: Offers a challenging but rewarding path. This method involves a systematic and planned update of a system while it is still in operation. The idea has gained popularity since Martin Fowler's influential writings on the subject.

Creating a thoughtful plan that combines business needs with a tech roadmap is really important. It means smoothly using both new and old systems at the same time, slowly adding new features to the new system while getting rid of them from the old one. Think of the 80-20 rule – usually, a small part of the code has most of the problems. If we handle the switch carefully, we can quickly move important features to the new system, so customers can start using it sooner.

In cases where the old platform is significantly outdated, a phased transition with a temporary architecture might be necessary. Challenges like data synchronization, interoperability, and library upgrades require advanced software engineering, specialized tools, and professional processes.

The aim is to maintain uninterrupted business momentum while enhancing underlying technology and quality. This approach minimizes business risks compared to palliative care or complete rewrites.

In my experience, a pivotal factor in successful large-scale system modernization is the personnel strategy. The ambitions, career goals, and technological preferences of the team are as crucial as the right toolset or expertise. Modernization projects are ambitious missions requiring specific skill sets at various phases.


Transforming software liabilities into assets is not merely a technical endeavor; it requires a comprehensive approach encompassing technology, strategy, and human resources. By recognizing and addressing the complexities of legacy code, organizations can not only salvage their software investments but also pave the way for future innovations and success.

Related posts