Sure, automation is a smart move. But by same-y I mean:
* We need a website. It will have these 5 pages. How long will that take?
* We need an iphone application. Here are the dozen or so screens and a few pages of what it needs to do. How long will that take?
Automation is actually a diminishing multiplier on the estimate -- it doesn't make estimation itself as a problem go away. If anything it reduces variance, making estimates more useful.
Take the website example. It might have been that originally you did everything by hand but now you have a collection of templates, generation tools, snippets and so forth. This has brought your development time down substantially -- but you still get asked for estimates. What used to take weeks might now take days; fine.
But the end product still has some degree of size and therefore takes some amount of time to develop, even if that size is a hundred thousand lines of code and the time is however long it takes for your code generator to spit out Generico Inc's new website from the you-beaut inhouse system.
If you are making a 5-page website and you have effectively no code to write, the reason you can make an estimate cleanly is that it is no longer programming. At that point you are estimating how long the content will take to produce, get signoffs, graphics, etc, and those are quite estimable. The worst case you're looking at there is CSS incompatibilities. An iPhone app that is just layout out some UI elements and doing something very simple (or just pulling up existing webpages) will similarly mostly not be programming.
Of course if you remove most or all of the programming elements, the programming no longer screws your estimates up.
There's a whiff of No True Scotsman in my post here, so let me nail this down a bit more and say that in this case I see programming as requiring some sort of logic in it. Laying out a form for your iPhone app may occur in a programming tool and with another definition may even be part of the "programming", but for the purposes of this post I am not including that. And while having, say, a conditional panel that only appears when certain things is true is indeed programming, if your project is dominated by content and forms and just has a trace of logic, your exposure to the chaos of programming is limited and negligible. It's a continuum, of course, not a binary thing.
I think it was good of you to cite No True Scotsman.
I still think any estimate, even hilariously broad ones, are useful. Watts Humphreys put it this way: when is an estimate going to be most accurate? When you've just finished. When is it most useful? When you're just starting. In between is a tradeoff between usefulness and accuracy. You accept that estimates are inaccurate -- that's why they're called 'estimates'. But even if you narrow estimation variance from +/- 400% to +/- 200% over time, that is still a valuable improvement.
When I'm working with clients I explain the cone of uncertainty and so far they've all been understanding of the fact that software work contains profound uncertainties that other lines of work won't.
* We need a website. It will have these 5 pages. How long will that take?
* We need an iphone application. Here are the dozen or so screens and a few pages of what it needs to do. How long will that take?
Automation is actually a diminishing multiplier on the estimate -- it doesn't make estimation itself as a problem go away. If anything it reduces variance, making estimates more useful.
Take the website example. It might have been that originally you did everything by hand but now you have a collection of templates, generation tools, snippets and so forth. This has brought your development time down substantially -- but you still get asked for estimates. What used to take weeks might now take days; fine.
But the end product still has some degree of size and therefore takes some amount of time to develop, even if that size is a hundred thousand lines of code and the time is however long it takes for your code generator to spit out Generico Inc's new website from the you-beaut inhouse system.