The example is bad in that it compares income forecasting with expenses. In reality you would have an expected distribution of revenue, some probabilities etc. You can fix the example by imagining it as contract work where you get paid the mentioned $7000 on delivery, with no penalty for non-delivery.
The problem you see is the point of the sunken cost fallacy. Current »you« should ignore the money already sunk, and just look at the options presented. Therefore sinking more money into the project to complete it is worthwhile as long as the money sunk is less than your payout.
If in the future you are even only 1$ away from finishing the app it does not matter how much you put into it already. The money is gone, sunken. You get to invest the 1$ and reap the benefit or not.
I agree that if the numbers given in the example were trustworthy, then it would be a good example. The part that confused me was that there would be no incentive to start the project unless the original estimate of the cost was significantly less than $7000. It seems reasonable to expect that the next $4000 you spend will have a similar effect on your expected cost to finish. If you perpetually think “Just another $5000 and I will be done”, then you are no better off than if you think “I already spent so much, I can’t just quit now.”
The more money that is sunk into it, the stronger the evidence that you are bad at estimating the cost. I assume that this evidence is implied to be included in the new cost estimate, but I think a general audience would not immediately notice this.
I think you broke the example. The point as I see it that the surrounding conditions can change. Availability of coders, legal situation. Needed items from external sources etc.
It should be made more clear.
The example is bad in that it compares income forecasting with expenses. In reality you would have an expected distribution of revenue, some probabilities etc. You can fix the example by imagining it as contract work where you get paid the mentioned $7000 on delivery, with no penalty for non-delivery. The problem you see is the point of the sunken cost fallacy. Current »you« should ignore the money already sunk, and just look at the options presented. Therefore sinking more money into the project to complete it is worthwhile as long as the money sunk is less than your payout. If in the future you are even only 1$ away from finishing the app it does not matter how much you put into it already. The money is gone, sunken. You get to invest the 1$ and reap the benefit or not.
I agree that if the numbers given in the example were trustworthy, then it would be a good example. The part that confused me was that there would be no incentive to start the project unless the original estimate of the cost was significantly less than $7000. It seems reasonable to expect that the next $4000 you spend will have a similar effect on your expected cost to finish. If you perpetually think “Just another $5000 and I will be done”, then you are no better off than if you think “I already spent so much, I can’t just quit now.”
The more money that is sunk into it, the stronger the evidence that you are bad at estimating the cost. I assume that this evidence is implied to be included in the new cost estimate, but I think a general audience would not immediately notice this.
I think you broke the example. The point as I see it that the surrounding conditions can change. Availability of coders, legal situation. Needed items from external sources etc. It should be made more clear.