If you're not already subscribed to Jeremy Miller's blog, do so now. I'll wait for you to come back.
Okay, now that you've done that, read his latest post on sunk costs and architectural decisions. I'll keep waiting.
Done? Good.
As I was reading his post, I found myself nodding my head in agreement over and over again because I've been dealing with the exact same issues at work for the past few months. Sunk costs are something that every business deals with. A sunk cost is when you've already spent money on something and you later wish that you hadn't spent that money. The Wikipedia example that Jeremy cites of going to see a bad movie is the classic example of sunk costs.
One of the biggest problems with sunk costs isn't the actual cost involved but the fact that as soon as you admit you're dealing with a sunk cost, you're also admitting that a bad decision was made somewhere. This can lead to hurt feelings, hurt pride, etc. Jeremy points out that there can be political implications of this as well. Management will not be happy to find out that this awesome tool that was supposed to bring world peace, cure cancer, and solve the energy crisis actually is too slow for the masses to effectively use. They're likely going to question more than just the tool afterwards.
However, I submit that these same sunk costs can provide an incredible benefit to developers. One of the quickest and most efficient ways to learn is to make mistakes. If you get burned badly enough, you're not going to touch the hot stove again, because you now know that it is hot. If you're the one who is responsible for the bug that cost your company thousands or millions of dollars, will you make that same mistake again? Of course not!
Learn from your mistakes! I've been fortunate to be a part of a similar process and the results so far have been very positive. Our team has really come together and pushed out some really good code that our users are very happy with. Prior to starting the rework, we had all been dreading continuing to deal with the prior version of the product, because we knew we would be spending our time hunting down obscure bugs and hearing complaints from users. The question we continually heard from users was, "why is this better than before?" We hated the question because we didn't like the system either! Now, we can tell them with confidence that our work is without a doubt better and that we're behind it 100%.
From the management side, I submit that managers who give their teams a chance to fix mistakes and start over can gain a great deal of respect from their team. Our manager had ties to the prior system, but he also knew there were problems with it. The system had gone through three different groups before we had ever been given responsibility over it! No one even knew the system anymore! Not only did we come together as a team more, we also became more familiar with the code and were able to really take ownership of it. A positive response to problems or mistakes reflects a real maturity in leadership.
You can treat sunk costs as a straight loss and accept defeat. The better alternative is to treat them as a training expense. The benefits from training are not tangible, but most companies still spend money on their employees because they can become more efficient. Similarly, when we respond to sunk costs positively, they can provide the same kind of intangible benefits as training. Mistakes were made, but mistakes are an opportunity for growth. We all write bad code. Just be sure you learn from it and become a better developer!
UPDATE: Some clarification on sunk costs - a reader pointed out that a sunk cost isn't necessarily a bad decision or mistake, just an unrecoverable past expenditure. I'm no economist, but it seems that the term typically carries negative connotations.