In my experience, software estimation's biggest problem is piss-poor management. A few years ago, I worked at a company that needed to move off of a legacy sys

In my experience, software estimation's biggest problem is piss-poor management. A few years ago, I worked at a company that needed to move off of a legacy system. They had 5 years notice and the contract from the old legacy system had a hard stop (IE: after this date, we could no longer use the system). This system was running our entire business and had lots of moving parts. Management dragged their feet until there was 1 year to go. Our entire team ended up working nights and weekends and holidays From August->January. Most nights didn't end until 1am and we were expected to come in the next day at 8am for work. We would have worked Christmas day, but the director thought the company would get sued because it was a religious holiday. Management didn't have to work any of these long hours. There also wasn't any automated testing (and the company didn't want to dedicate any resources to it), so you needed to send in these hundred-column .csv files with various pieces of information on it and had to hope that after you got it all working correctly, that the next change to the system didn't break everything (this happened constantly, which also contributed to the longer hours). The deadline was overshot by about a month, but they somehow were able to get a contract extension. Management said this wouldn't happen again, but of course, they tried to do it again with a different project. At this point, I left.