And when these mergers happen, there's always an issue that arises. Sometimes that issue is about competitiveness, like during the recent acquisition talks between Sprint and T-Mobile. Other times it's about integrating disparate IT, HR and other systems, such as immediately following United Airlines’ acquisition of Continental.
The SEC and other regulatory bodies have strict rules in place guiding the types of information that both the acquiring and target companies must provide to ensure stockholders of public companies are fully informed when voting for or against a potential acquisition. Among private companies, the regulatory guidelines are somewhat less stringent, but they still do exist.
But while financial, operational and competitive disclosures are required, where are the regulatory requirements about disclosing technical debt?
Objects Closer than they Appear
In a recent post on ReadWriteWeb, Jon Brockmeier highlights the acquisition saga of Xmarks, a cross-platform bookmark sync service, which was acquired by LastPass, a password management service. Instead of touting the new capabilities, customers and opportunities Xmarks would bring to LastPass, there was silence. LastPass’s CEO Joe Siegrist noted that plans for Xmarks were significantly hampered by the amount of technical debt LastPass developer teams inherited from Xmarks. While LastPass has announced a few new features, the pace of innovation is dramatically slower than expected and plans to merge LastPass and Xmarks are on hold.
As software assets continue to become an increasing part of a company’s valuation, buyers should insist on conducting a technical debt assessment as part of the due diligence process. When this assessment is complete, the buyer should deduct a monetized version of the technical debt figure from the acquisition price or require that the target organization mitigate the technical debt to the buyer's satisfaction.
This is also true when purchasing software. Buyers should understand the technical debt embedded in the code they are purchasing. This technical debt can result in application crashes, degradation of hardware and software performance and potential corruption of critical data.
Traditional enterprise software vendors don’t often provide technical debt information for the apps they sell or license; but for open source, a purchaser can carry out an assessment of technical debt straight off the open source code. While the purchaser may find bad news in the form of significant technical debt, at least the company knows exactly what it is getting into. The uncertainly of not knowing what technical debt is embedded in traditional enterprise software can lead to crashes down the line.
Along these lines, it is also worth noting that when taking technical debt into account, open source software actually underscores its true value because the purchaser knows exactly the amount of technical debt embedded in the applications of the organization being purchased.
Taking the High Road
Measuring and improving software quality, especially complex multi-platform, multi-language and multi-sourced applications, is a critical cornerstone of identifying and quantifying technical debt. Making the investment in solutions to ensure high-quality software may not immediately translate into return on investment and is not always obvious because it is like trying to disprove a negative; nevertheless, it is paid back many times over. In addition to providing high availability and lower latency, developers can modify high-quality software to meet a pressing need more quickly, and quality software is more able to repel security attacks.
As I've discussed before, eliminating all technical debt just isn't feasible, but in today’s business environment, where both speed and quality are critical success factors, analyzing and measuring the structural quality of an organization's applications to ensure they carry only a small, manageable sum of technical debt could mean the difference between a smooth merger and a horrific accident.