> In my opinion the way around this is to deliberately stop and do an estimation exercise. First think about how long the refactor will take, and be extremely

> In my opinion the way around this is to deliberately stop and do an estimation exercise. First think about how long the refactor will take, and be extremely generous (e.g. double your first estimate) That isn't estimation. That is pulling a number out of your ass. Try something for me. For each of these data points, write down a low estimate and a high estimate that give you a 90% probability of being within that range. Surface Temperature of the Sun: Low [___] -- High [__] Latitude of Shanghai: Low [___] -- High [__] Area of the Asian continent: Low [___] -- High [__] The year of Alexander the Great's birth: Low [___] -- High [__] Total value of U.S. currency in circulation in 2004: Low [___] -- High [__] Total volume of the Great Lakes: Low [___] -- High [__] Worldwide box office receipts for the movie Titanic: Low [___] -- High [__] Total length of the coastline of the Pacific Ocean: Low [___] -- High [__] Number of Book titles published in the US since 1776: Low [___] -- High [__] Heaviest blue whale ever recorded: Low [___] -- High [__] Now, you might think this is a silly exercise because you don't have experience with the scale of these things, but how often do you estimate the time it takes you to build a product you aren't yet familiar with something using a tool you're not yet familiar with or people you aren't familiar with? The answers are here: http://my.safaribooksonline.com/book/software-engineering-and-development/project-management/0735605351/answers-to-chapter-2-quiz-ow-good-an-estimator-are-you/app02 http://my.safaribooksonline.com/book/software-engineering-an... (This quiz is taken from Software Estimation by Steve McConnel (Microsoft Press, 2006) and is copyright 2006 Steve McConnel. All rights Reserved. Permission to copy this quiz is granted provided that this copyright notice is included.)