"In software you're always balancing risk. If you have some working software, but it has some flaws that doesn't mean you should abandon it." I've yet to see a

"In software you're always balancing risk. If you have some working software, but it has some flaws that doesn't mean you should abandon it." I've yet to see a project where throwing out the old software because of its flaws saved effort. Of course, that's partly due to not having had any projects where I was inheriting software written by competent developers in the first place, but the management can't tell the difference. Every single time that I've seen that argument used as a basis for selecting the refactor approach, it's ended up being a death march because we had to re-write nearly the entire thing anyway. And when we were done, we STILL had a tangled mess of tightly-coupled components that didn't quite work. It's exceedingly rare in software to find a situation where abandoning the old software is a mistake. With any luck, I'll find one of those projects some day. But I doubt it, since the trend I've seen is that software quality is decreasing, and more and more components are tightly coupled together because the developers are too rushed and/or burned out to realize it. If you ask me, the article isn't worded strongly enough. In fact, it describes the government contracting industry almost perfectly. The entire industry is based on using the sun cost fallacy to reward failure, because in government contracting the LAST thing you want to do is finish a project early and under budget. If you do, you get a smaller budget on the next project.