A subject that’s been on my mind lately is technical debt, and how it connects to business issues. Code quality is directly related to a business, in the same way that the maintenance of industrial equipment relates to that business’s ability to continue producing widgets.

The thing is, software can quickly and easily get more complex than any industrial machine. Comparing software to a single machine might actually be a bad analogy – a complex application is more like a whole supply chain than any individual machine. This analogy works if we go a bit deeper.

The functionality in a single application may actually come from combining separate applications, in the same way that a company might buy a supplier to bring their supply chain under a single roof.

This actually relates to a trend in the software industry. There are many applications that are extensions of (or complementary to) other services.

This trend in the industry tends to encourage companies buying one another to bring a more complete feature set to the market under a single marketing/sales/branding umbrella (with the goal of increasing shareholder value).

For example: Summize provided search capability for Twitter, then Twitter acquired them. UberVu provided additional social media functionality that complemented HootSuite’s offering, then HootSuite acquired them. Klout provided functionality complementary to Lithium, then Lithium acquired them.

When one SaaS buys another with the intent of integrating with each other, there are a number of factors that can affect the purchase price. Some of these factors are based on technical due diligence – if the code is good and will be easy to work with, that can increase the value of a deal. If the code is bad and hard to work with, that means more budget must be allocated for post-acquisition costs.

One of the things that can make this acquisition/integration process easier is by having a great API. Having an API that is well designed (we engineers describe this as being abstracted correctly) means that an integration can be done quickly. Large applications are already designed as smaller systems that communicated via API, so this can set the stage for a great integration as part of a merger.

And all this on top of the day-to-day benefits of a good API anyways!