November 29, 2009

A game theory analysis of software development

Being a founder of a software firm is odd. Since I’m also an Econ major, I thought of something. Game theory creates emergent features in a product category.

Well, why don’t people use Word to draw? It would make a lot of sense to include a full graphics add in to word about equal to Expression Design. Many times, people want an area with a figure, and vector drawing makes more sense than bitmap. But word only hosts MSPaint when you try to draw in it, and even then, usually as a way to modify an inserted image. Game theory explains this nicely.

In a software project I’m currently working on, I completed all features I wanted for a v1 release. Other than artwork, I would say we’re good to ship. However, I decided to do a last minute competition check for similar products and features. I noticed a couple of features in a similar product that ours didn’t have. I then hunted down why the author added them. Seems like they got a lot of feature requests for these, and so I decided that to be competitive, I would also add those features. They’re pretty small — maybe a day’s worth of work for me to add them all.

And that’s where Game theory comes in. I have no idea what people want — we’re speculating in software. Once we realize that we’re speculating, then any information I find that a feature is a good idea in a product like ours, I’m likely to consider adding myself. As a player in the game, I know customer expectations will be set by the “supplier group”. If I don’t have parity with the supplier group, then my product won’t go anywhere.

This made me realize that features emerge in a product category through a game until Nash equilibrium is reached. First mover defines a product area. Market responds with a “Yay/neigh” on the product. If market says, “yay”, then the product gets copied by competitors, looking to supply some of the demand. Each competitor tries to differentiate, since they want a greater share of the market. Each differential that drives sales( or not ) gets copied. This happens until the marginal cost of features = the marginal demand of features, and Nash equilibrium is achieved.

Now the (or not) aside comment I made. The (or not) is that information is imperfect. Often, the transaction cost for a firm to determine if the new feature has marginal demand is higher than the cost of just implementing the feature. So, there’s a lot of blind copying of any idea whose marginal cost of implementation is low. This is a bad.

Why? Because resources are used to implement a feature that may have no demand, and those same resources could do something that has demand.

In my example of the software I’m writing, I’m not sure the features are important. The author of the software I hope to compete against believes it is. Me doing a market research survey on this would take more than a day. The cost of parity is a day. So, I make the same game choice as a larger firm would make.

The other funny thing — the cheaper the software, the more likely for its features to get blindly copied. Anyone who wants to sell software wants to show a “value add” over any free software. So, if free software has a feature, then anyone wanting to compete with it will have parity, then add onto it. At least, in a commodity market.