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.
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.
Conclusion