> Someone has a great new design they want to implement which is leagues better than what exists, and the existing design is just so awful. Only, it’s going to

> Someone has a great new design they want to implement which is leagues better than what exists, and the existing design is just so awful. Only, it’s going to require some duct tape here and there, but that’s totally acceptable because overall it’s better. Until it becomes apparent that it’s mostly duct tape, but you’ve gone all-in on this and you can’t go back. > Solution: Start over. The sunken cost fallacy is real. You’ve made a mistake, and that’s ok, you can take those learnings and build something better. Don’t settle for chaos. Seems like a smart solution, and yet I almost never hear “throw it out and start over” as an option for dealing with unforeseen problems. Perhaps as programmers we should take some lessons from writers, who will often throw out all their work from the past day/week/month, because once it goes into production (a published book), you can’t change it. In software, you can change it, yes. But if it doesn’t add anything useful, complicates existing things, or will slow development in the future, there is a clear reason to just drop it and move onto the next approach. One way to make “just drop it” a more palatable option is to give yourself a grace period from the outset. Something like “if we can’t get this to work in a week, we’ll drop it and reevaluate.” This is when it helps to have at least two people (engineer + manager, or engineer x2) because it eliminates “developer pride” as a variable in decision making and holds someone accountable for making that decision after a week. As a manager, often the most important decisions are not what to build, but what not to build.