Caution: Merger Ahead

by

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.

Filed in:
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Jonathan Bloom
Jonathan Bloom Technology Writer & Consultant
Jonathan Bloom has been a technology writer and consultant for over 20 years. During his career, Jon has written thousands of journal and magazine articles, blogs and other materials addressing various topics within the IT sector, including software development, enterprise software, mobile, database, security, BI, SaaS/cloud, Health Care IT and Sustainable Technology.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|