SaaS Resolves the Software Prisoner’s Dilemma
Posted by Bob Warfield on September 9, 2007
I read an interesting piece the other day about The Prisoner’s Dilemma in Software Development. Others have stumbled on the same idea. It was a sad piece really, because it dealt with the view that the relationship between the software developer (or ISV) and their customers is extremely adversarial, hence the “Prisoner’s Dilemma”. Wikipedia says, “In game theory, the prisoner’s dilemma (sometimes abbreviated PD) is a type of non-zero-sum game in which two players may each “cooperate” with or “defect” (i.e. betray) the other player.” You can begin to see the parallels. Does the ISV and its customer successfully cooperate, or does one or the other betray? The name derives from the idea that its about two prisoners, accused of a crime, separated, and asked to betray one another for a lighter sentence.
Ironically, the game theorists conclude that rational choice leads both players to betray each other. Anyone that has been in the IT or ISV game for long enough will have seen this happen. The ISV over-promises what can be delivered, secure in the knowledge that the further the customer gets before discovering this, the harder it is to back out. The customer minimizes the complexity and difficulty of what the ISV has to accomplish, secure in the knowledge that the further along the ISV gets, the harder it will be for them to back out. New requirements never heard of before materialize at the last minute just as the finish line was starting to be visible.
Each side strives to minimize its risk through various legal mechanisms as well as due diligence. Acceptance clauses, SLA’s, and all the rest fit perfectly against the fabric of the Prisoner’s Dilemma. Apparently, one of the best strategies to use in the game is Tit for Tat. Start out trusting, and if the other side betrays you, then you should betray them.
Is this any way to do business?
Software as a Service (SaaS) eliminates the Prisoner’s Dilemma aspect of the whole relationship by deferring payment until the solution is delivered and then charging as the solution is consumed. The customer’s risks are then properly matched to the vendor’s rewards. The fact that its much easier to get a SaaS solution running helps as well.
Clearly, SaaS is a much better game for customers and vendors alike than Old World On-Premises with perpetual licenses.