The grandparent comment used the term "bad estimate" without acknowledging that the only thing which distinguishes a bad estimate from a good estimate is that bad estimates come back to bite you. My post indicated that the ways in which estimates come back to bite varies based upon the reasons for estimating in the first place, e.g. when the context is "it takes as long as it takes" there isn't a reason to estimate.

The first set of estimates I describe are those in which the estimate comes back to bite you before the work has begun. An example would be an estimate within a publicly traded company which conflicts with the information provided to Wall Street, i.e. the purpose of the estimate is to confirm that all is well so that management can collect their quarterly bonus based on stock price. In another life I participated in those.

The second group of estimates I describe are created to allow management to apply a single big picture fudge factor to account for big picture inefficiencies, contingencies, and information flows such as those which arise from external contracts. When management asks for a best case estimate in good faith, it is uncommon for the inaccuracy to come back to bite the individual providing the best case estimate. The inaccuracy is known going in, and the final estimate is of the third type I describe...i.e. it attempts to account for "known unknowns" and even "unknown unknowns."

The third category of estimate is the only one for which people should be held accountable in regards to accuracy, and any accountability has to be related to the experience and authority to allocate resources of the person preparing it.

Treating accurate estimates as impossible is a cop out. They are done all the time. It just takes experience and feedback and a desire for improvement.

I know companies who are good at estimating because they never change how and what they give a client. The designers are forced to design for the CMS.

If all you need to do is to change things then yes it's possible to project fairly accurate.

But in most cases where time estimation matters you can't just use past experience to estimate how much a new project is going to take you. Those are projects where you are innovating/creating/defining a new solution.

So calling it a cop out is seriously underestimating the problem and discussion where it's most important not to.

One of the issues with article, and perhaps a difficulty with this dialog, is that "estimate" is being used in two senses - "how much work is involved?" and "when will it be done?" (See my top level response to the article for the distinction between billable time and calendar time.)

This confusion is obvious from the first rule in the article's chart - 30 seconds is billable time, one hour is calendar time. The chart translates one into the other (my second estimating scenario).

The argument that accurate estimates of programming time are impossible is a cop out because other creative activities are not only able to produce them but have a tradition of doing so...Michelangelo finished the Cistine Chapel before he died, Einstein had a magical year, and Forest Gump met its production schedule more or less.

Then again, nobody involved was likely naive enough to think that any scheduled task would only take 30 seconds.

You are missing the point completely.

It's not difficult to finish "on time" when you are both the definer of the requirements and the creator of the solution. But that is not the reality for most companies/shops/agencies being hired to help a customer.

You are trying to compare projects where the canvas is known and well established with projects where the canvas is unkown and always changing.

There is a reason whey it's easy to estimate how long it's going to take to print an ad and why it's hard to estimate how long it's going to take to make sure that an ad displays properly on a webpage.

There are many millions (or perhaps a few billion?) webpages with ads. Getting something to display properly is a common problem which has been solved again and again. The canvas is as familiar as that which an architect encounters when sitting down with a client to discuss a building - actually it's probably simpler since it's much easier to sell a hospital on scrapping their existing website and constructing a new one than it is to convince them to scrap their existing building - imagine if you had to provide an estimate to update a Geocities page to HTML 5 and support for iPads.

If there is a fundamental difference between programming and other creative endeavors, perhaps it is the lack of literature Richard Gabriel observes and remarks upon - though I'm not convinced.

I'm more of the opinion, that the difference when it comes to estimating between programming and professionals in other creative pursuits, can be found in the fact that Frank Gehry was in his 50's by the time he started to become a rock star, Michelangelo was in his mid thirties when he began the Sistine Chapel, and Einstein was too old to be a brogrammer in the Annus Mirabilis.

Programming is just one of many fields where one starts with a blank canvas, no matter how much of a true Scotsman one wishes it were.

Again those you mention where hired for their style, a style they spent many years developing. They define the requirements so of course they can meet them.

That not the reality developers no matter how much you insist.

With regards to Frank Gehry. He is using some specialized software from the military to calculate some of those crazy shapes he do. If you throw in the development of that software as part of the scoping you begin to understand the complexity.

Banner ads are much more complex than you think since most of the times designers design, client approve and devs have to put it under 20KB.

You aren't really understanding the problems here.

I understand the problems, like any other business people are paid to solve hard problems.

Gehry doesn't get all those laboratory buildings and museums for the sake of style, he gets them because he can execute complex programs using forms requiring expert detailing within time and budget constraints.

If he didn't have that skill set, he wouldn't be hired by real-estate developers - unlike Venture Capitalists, real-estate developers expect to make money on every project. What's more, the reason he is able to bring projects in profitably or in line with institutional requirements is because he spent the "three lost decades" between undergraduate studies and the project which put him on the map (his Santa Monica home) working for the Army Corps of Engineers and the developer James Rouse. It's not the software, he started using Catia in 1992, and then only for a small project.

The difference between software and other endeavors is that Zuckerberg is the iconic practitioner not Spolsky and when someone runs their business like Gates or Ellison, they tend to be looked down upon.

Incidentally, no canvas is quite as one of a kind as real-property...except perhaps a block of marble.

So why do all those architects who can't meet the budget constraint get hired again and again?

Of course it's the style.