The thing that annoys me most about project estimation is when the micro-managing types don&#x27;t let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be &#x27;x days&#x27; with &#x27;x&#x27; being greater than the time one expects internally so backside is covered, yet that is not really a true answer.<p>At the moment I am putting together a &#x27;simple&#x27; feature on a website, where I have been able to explore the problem space first. For the $content there actually needs to be half a dozen date fields that were not in the original brief, I doubt I would have discovered this had I not rolled a little bit of code first and explored &#x27;prior art&#x27; in the area.<p>I need to put together a semi-working prototype to discover such things - particularly when UX is involved. Yet, far too often, the opportunity to do actual preliminary dev work is denied by those that &#x27;know best&#x27;, preferring a spec. in a Word document (or something else equally 1990&#x27;s) instead of a rough working prototype in code (with back-of-envelope sketch).<p>My current feature-being-added will need to be re-factored at some stage, once users have started using it and problems&#x2F;features overlooked in the original brief catered for. It is not as if the users of my new feature will know that &#x27;actually they wanted it to work this way&#x27; until they have something to see. So why we have these silly cast-in-stone processes I do not know.<p>I also must say that I find the metaphor of painting a room is quite a poor one, I would not need to paint &#x27;an alcove first&#x27; to get a handle on how long the whole room would take.