In my last blog entry, I discussed Software Quality for Acquisition Valuation and identified that acquiring companies can negotiate lower valuations for software companies who do not follow early testing practices.
The positive corollary to how these practices affect acquisition valuation is that early testing practices have material impact of the value of software assets. In fact, early software quality practices add critical components that dramatically increase the value of software assets for an organization.
In software engineering, we think mostly about problems and solutions, leaving the questions of business value to our fellow executives. A simple illustration of what developers tend to do is shown below:
|
In traditional manufacturing, the business value of “process” is well understood. Even lay people can appreciate that the value of an automobile manufacturer is not in the ability to produce a single instance of a car. It is in the reliable and repeatable ability to create high-quality cars at a predictable cost.
The actual business value of source code is related to its ability to reliably produce quality executable programs as requirements evolve. A primary factor in valuing source code as an asset is its independence from the developer who authored it.
Early testing practices have appreciable positive impact on the quality of executable programs. But, much more than that, they add artifacts to the source repository, which help build independence from authorship.
|
Using continuous integration practices and ensuring that code complexity, test coverage, source dependency and other metrics are maintained at reasonable levels helps increase the value of the source code assets.
Many software organizations discuss strategies that include a sale of their organization to a larger entity. Shouldn’t the engineering team consider the impact of their process decisions on the evolving value of its source code?
July 3rd, 2006 at 8:23 pm
I like this approach to looking at the value of software assets. Obviously, there is more to the equation (requirements matching, documentation, etc.), but he makes a good point that code is just another artifact of the process and that the value for the company is in its ability to leverage all of the assets independent of particular personnel.
July 6th, 2006 at 8:19 am
I’m not sure I fully buy into Burke’s premise that the asset is valued on its ability to make it independent of the people who authored it. It seems that the people are an important part of any sale of a company and most of them would be part of any transaction.
July 6th, 2006 at 1:09 pm
I did not say that the full value of the software asset is based on its independence from the people who authored it. However, with any acquisition, there will be issues about key strategic people leaving because they are disgruntled, because they’ve “cashed out” or just because the acquisition event gives them a point in time to make a change.
Regardless, the non-sourcecode resources (unit tests, component tests, build scripts, deployment scripts) that are in SCM and are automated to simplify the creation of deliverable product cleary increase the value of the sourcecode asset.
It goes back to my earlier blog about the acquirer using the lack of these non-sourcecode resources as a technique to lower valuation.
Thanks for your comment; your point that acquirer’s often “buy” people when acquiring a company is well taken.
July 10th, 2006 at 8:29 pm
Great article Burke. Could you expand on the “Using continuous integration practices…helps increase the value of the source code assets.”? As an industry, what economic drivers prevent organizations from turning artifacts into assets?
July 21st, 2006 at 9:44 am
Over at JNetDirect, my software business, we just ran into this problem. A customer wanted a change to an old product; one that we had not yet applied Stelligent early testing practices.
At first, we were only able to accurately build the product on the authors machine. The lack of test assets caused us to face *much* more testing than necessary for the relatively minor change the customer requested.
The point is that had we invested in the Continuous Integration practices early in this product lifecycle, these later costs would have been greatly reduced.
Further, we count ourselves lucky that this was an enhancement and not a defect. Our customer was patient as we worked to meet their requested change. Had it been a defect, their patience would have been much shorter and our costs would have been much higher.