“If a builder builds a house for a man and does not make its construction firm, and the house which he has built collapses and causes the death of the owner of the house, that builder shall be put to death.”
Clearly, the Babylonians understood that the builder will always know more about the risks than the client, and can hide fragilities and improve his profitability by cutting corners—in, say, the foundation. The builder can also fool the inspector (or the regulator). The person hiding risk has a large informational advantage over the one looking for it.
-- Nassim Taleb and George Martin, How to Prevent Other Financial Crises, SAIS Review, Winter-Spring 2012
The interests of buyer and builder of any asset are fundamentally divergent. The builder, who has to keep workers engaged and cash flowing into the business, has a shorter horizon than the buyer, who enjoys the fruits of the asset for a long period of time. The buyer knows only whether the asset appears to do what it is expected to do after it is delivered, whereas the builder has more knowledge of the care that has gone into the asset: the quality of raw materials and the thoroughness of the workmanship. By necessity, there is a fundamental trust relationship between buyer and seller. The Babylonians understood the criticality of this trust relationship to society and thus set a very high expectation that it would not be violated.
In software development, information is highly asymmetric between buyer and seller. The buyer knows a particular business such as selling toys or flying people from place to place, while the seller knows how to develop and deliver software. A buyer knows whether software is functionally complete (can I transact business using this software?) but most buyers are not experts at software or software development. Few know the questions to ask relative to non-functional requirements, or how to validate that the answers to those questions are satisfactory. How does a buyer know that a solution is being developed so that it is highly secure from attack? or will perform reliably and satisfactorily? or will scale? Buyers assume the asset will have these characteristics. Yet buyers tend to find out whether they do only after the fact, and it is the buyer who is stuck with the outcome: delays due to unforeseen technical work, or higher than expected hardware costs. Most buyers of custom software are underwriting risks which they do not fully appreciate.
There is not an equivalent in software development to the ancient Roman practice of bridge engineers spending nights sleeping under their construction. The closest thing we have are commercial clawbacks and the threat of long and painful slogs to rescue a distressed investment. Clawbacks can be painful for a selling firm, but unless both parties contractually agreed a definition of a possible "rescue" state and set as a term that the seller is responsible for all costs incurred during rescue, the full force of the clawback is easily blunted through negotiation. Rescue operations are painful for the individuals involved in them, but are not not often led or staffed by the people who created the mess in the first place. Thus the builders responsible for the slipshod quality rarely feel the full force of the consequences.
Therefore, Mr. Kay sensibly suggests that active investors should have concentrated portfolios. This encourages long-term thinking, and detailed research. Such a concentrated investor will be an active steward of the company, making life difficult for the management if it errs. In short, such managers may behave like "owners" of the stocks in the portfolio.
-- John Authers, writing in the FT
If we can't get builders more closely aligned with buyers, perhaps we can get buyers more closely aligned with builders. Investing in custom software is active by nature. There are no passive IT investments, no index funds or ETFs through which we can invest in software. Investing in custom software is a business of picking winners. The things that Mr. Authers and Mr. Kay point out about financial investing are applicable to IT investing. We benefit when buyers or buyer's agents (e.g., IT portfolio managers) behave as "active stewards" of the investments they make.
To be effective stewards, a buyer must do their research on the things they are investing in. Part of that research is knowing the domain of software and software development: about technologies the team is using, about the level of confidence behind progress reports (can we validate results or can we merely validate effort has been expended?), about the fullness of the solution (what specific NFRs matter to us and how specifically are we validating that they are satisfied), and above all about the people responsible for delivery (do we have people with sufficient capability on the team). Where the buyer may not have the knowledge, they can assemble a board to oversee their investments, consisting of vested stakeholders and independent directors with expertise in areas where the buyer's knowledge and experience are lacking.
This puts the buyer closer to the builder while the asset is being produced. Not in the weeds of technical decisions, but in a position to set and reaffirm expectations with the team, and to validate that results are consistent with those expectations. The buyer trusts, but verifies.
As Mr. Authers points out, such a buyer will "[make] life difficult for the management if it errs." Better for an errant management to be corrected while there is value in an investment to the buyer, not after that value has been lost by the builder.
