Caution: Merger Ahead
Posted By Jonathan Bloom on January 23, 2012 | Technical Debt
Our economy goes through periods of intense merger and acquisition activity, which often reshapes entire industries dramatically in one fell swoop.
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.
Tags: acquisition, Application Quality, application security, automated analysis and measurement, M&A, merger, software analysis, software measurement, Software Quality, structural quality, Technical debt
Enjoyed this post? Subscribe to our RSS Feed, Follow us on Twitter or simply recommend us to friends and colleagues!
Posted by Jonathan Bloom
Jonathan is an experienced writer with over 17 years in the technology industry. Jon has written more than 500 journal and magazine articles and other materials that have been published throughout the U.S. and Canada. He has expertise in a wide-range of subjects within the IT industry including software development, enterprise software, mobile, database, security, BI, SaaS/Cloud, Health Care IT and Sustainable Technology. Jon holds a B.A. in History from Gettysburg College. He enjoys attending sporting events, cooking, studying American history and listening to Bruce Springsteen music.
One Response to “Caution: Merger Ahead”
Hello, there is some business to do around IT asset assessment using technical debt.
I met with an organization that uses Function Point estimations (BackFired, COCOMO, …) to assess the overall development cost of an application then compute a ratio of embedded technical debt.
Their early findings encouraged them to go on with this activity as they could spot some applications that were clear outliers.
While most applications averaged at 20% of technical debt, some jumped to 120%.
After the initial shock due to the sheer amount and to the cognitive dissonance (teams were known to be serious and skilled), an analysis of the findings concluded that the debt assessment was even underestimated: the application lacked virtually all basic errror and management handling.