DevExpress Newsletter 23: Message from the CTO

12 March 2010

Now that we’re doing my Message from the CTO in the DevExpress newsletter as a video, I’ve had a couple of requests to make sure that I publish the text as a blog post. Here’s the Message from Newsletter 23 (the video is here):

Sunk costs

There's a concept in economic theory that's of great importance in software development because it comes up all the time: sunk costs. In fact it's fascinating in its own right because it says more about human reactions and motivations than about economic theory.

Imagine the following situation: you've been running a software development project for 6 months and, for whatever reasons -- could be a competitor has come out with something similar, could be that the implementation is running into difficulties -- you're wondering whether to continue the project given the amount of effort and resources -- that is, money -- you've already put into it. Presumably, another opportunity has presented itself and you're trying to decide between continuing or doing something else.

If you're like most people, you are very hesitant to drop the project. The argument goes something like this: the project has already cost X thousand dollars and it could still be completed in a reasonable timeframe for a certain amount of money and still be worthwhile, that is, make a profit. Ignore the new opportunity.

Economic theory says otherwise. The costs you've already incurred are spent. The money has gone. They are what's known as sunk costs. To make a decision right now between two opportunities, you should only consider the future costs and future benefits of those opportunities.

So, you'd put aside what you'd already spent and look at how much each opportunity (that is, finishing the current project or pursuing the new one) would cost from this moment forth and would possibly make as profit when sold. If it's the new opportunity, economic theory says go for it. Forget your sunk costs.

In software development, oftentimes the new opportunity is "starting from scratch" because for example you've learned a lot about the problem space in the meantime. Indeed, with agile development there are many scenarios that involve "throwing away" what you have and starting afresh. Examples are spikes, where you explore some technology with code you then discard, and prototypes, where you mock up something for presentations but never use it in production. Both of these are great examples of sunk costs and can be difficult to justify to customers. How many times have you heard anecdotal tales of customers who think that the prototype is the finished application and just needs hooking up to their data? And you're thowing away the "finished" application because?

Sunk costs are sunk. They're at the bottom of the sea and you won't get them back. No matter how hard it may be, ignore them, and look forward.

Free DevExpress Products – Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We’ll be happy to follow-up.

True, but the next project can sunk too and the next...and become bankrupt without delivering any product at all. Better is to ask yourself if your neighbourhood is not crowded with pizza shops and if you believe you can bake better pizza than your competitors and make money… In general consumers like choices and the buying process is not limited only by one product characteristic…For example Apple step successfully in the crowded mobile phone market where well known companies like Nokia, HTC, Samsung, Blackberry offered for many years their products.

12 March 2010
Jason Short

This is SO very true.  It is so hard to let go of something you are 'almost' done with because you have spent so much money on it.  You want to see it go into production, but sometimes it is just not worth it.  

Another reason this can bite you:  technology or platform changes.  Sometimes it is hard to drop something on an older technology, or stop it's latest upgrade, because a newer technology has come along and replaced it.

I think a lot of shops nearing production on .Net apps right now are hitting this.  Should we scrap the current code and refactor for .Net 4?  Should we try to do both at one time?  Economic theory says that the .Net 4 version will be most of your new revenue.  The .Net 2 crowd will only shrink from this point forward.  You would be better off to spend your money on where the new crowd will be, rather than your current customers.

19 April 2010

Please login or register to post comments.