Software demand curve

Returning to my series of posts applying the tools of economics to software development - Supply & Demand in software development, Software supply over time and Software supply & demand - this time its Agile - it is time to turn our attention to the demand curve. First a reminder of how things start...

First I need to explain why I believe there is so much demand for software and why I believe the curve is inelastic, i.e. why a higher price doesn’t reduce demand very much. The reasoning here breaks into five groups: technology progress, separation of demand from cost, separation of benefit from delivery, lack of evaluation and the effect of “fixed” work - although the last in that list doesn’t always play a part.

It is important to remember in all this discussion that software is a derived demand. Nobody wants software for its own right, they want it to achieve some other aim.

Technology Progress

Moore’s Law implies that processor power doubles every two years (give or take a bit). Consequently the ability of computers to tackle ever more complex problems and fill more needs constantly increases. Supply creates demand, we want it because we can.

For example, I’m hoping Farther Christmas will bring me an activity tracker for Christmas, I didn’t know such devices existed until recently but I can see it solving one “problem” in my life. These devices didn’t exist until recently, I didn’t need one because they didn’t exist. The underlying problem existed but had been put in the “thats life” bin.

At a company level this means the benefits computers can bring to our companies are constantly increasing and there are new opportunities to save costs or generate revenue. And if the incumbent company doesn’t take these opportunities then Amazon, Google or some start-up will.

Moore’s Law is not alone, Metcalfe’s Law compounds the effect. The more devices we enable and the more devices we connect to the internet the greater the value and opportunities from connecting these and more devices.

Separation of Demand from Cost

Traditional development process - and even Agile processes - tend to separate the demand for software technology from the supply, consequently those requesting technology are isolated from the cost of that technology.

Many practices in software development make this problem worse. We send Business Analysts to talk to “users” about “What they Want” i.e. what is their demand. These BAs are sometime little more than order takers, waiters. People are encouraged to ask for more and more. Indeed, some of our practices incentivise people to ask for more and punish them for not asking for it.

Even if “users” don’t ask for it Analysts may be encouraged to include any need they can comprehend. I once had a BA tell me “If we miss a something in the requirements document it is seen as a black mark against the BA.”

Separation of Benefits from Delivery

To make things worse its not just demand which is separated from costs but so too are the benefits. Nobody wants IT for IT’s sake, they want it for some benefits. But achieving the benefits may well take time, it might be months or years after an IT system is delivered before the benefits are seen.

That is, if the benefits are ever seen, IT alone is not enough to bring about benefit. Users may need training, changes to processes may be needed, customer agreements may need to be changed and so on.

Although it is a few years old now Wired for Innovation contains a good, short, discussion of why IT benefits don’t appear in the way we would like them too (i.e. quickly and easily) and what can be done to help.

Lack of evaluation

Ideally companies would evaluate the benefits delivered by IT work but all too often this fails to happen. Instead companies may rely on the original claimed benefits. But this might the result of optimistic thinking itself: “38% of businesses openly admit benefits are overstates in business cases in order to obtain project funding” - from a Cranfield Business School study I reported in October 2010.

And when one manager exaggerates benefit to get his project funded it creates an incentive for the next manager to exaggerate the benefit of the next project and so on. Benefit inflation cascades through the organisation.

This isn’t helped by vendors who claim benefits for their product which might not apply to a particular business or in a particular context. If company A used product B to save $C millions then surely company X can use product B to save about $C millions, right?

In our personal lives we have become accustomed to technology getting cheaper and more powerful and we expect the same in business. But consumer technology is paid for by millions of people buying millions of products while business technology may have one customer. Consequently we don’t appreciate the costs involved in creating new software.

Goal Displacement: Floorded contracts, projects and governance

In an effort to control IT, to maximise the return organizations frequently fixate on controlling the costs. They demand things like price, time and scope are decided in advance and fixed. Sometimes this is done internally - projects are approved and must be finished according to some set budget or date. And sometimes it is done by finding a supplier who will agree to fixed price/time work. (I’ve written about this before in Dear Customer on this blog and on Agile Connection/TechWell.)

The problem is, when you put these arrangements in place the objective becomes: meeting the fixed criteria, not delivering value. It is what psychologists and management students call Goal Displacement.

Options to reduce scope, time and cost are lost in the process. The things which were meant to be maximums, ceilings, become minimums, floors. Opportunities to reduce costs are lost to more features and more software.

Net effect

Taken individually, together and in combination with other forces we end up with a demand curve which is very high and inelastic. Changing the price of the technology doesn’t reduce the demand by much, Moore and Metcalfs Law mean there are always new opportunities, failure to capture original benefits mean they are still there for the taking, and lack of evaluation means nobody is counting, boys will always make arguments for more toys.

In the next instalment of this series I intend to look at what Agile can do about this and whether Agile makes things better or worse.