Known exactly, maybe. But when I was a consultant we had a pretty good idea of how long it took to do a good job on a project.

We'd add in some padding because you don't know if something will need a bit more research or if the lead is going to come down with the flu or whatever. You write deadlines that are under the client's control, rather than yours, into the contract.

So you don't know exactly. But if you have a decent handle on the scope of work and aren't trying to solve wide-open problems, you can usually get pretty close.

Certainly, a lot of people don't have this level of experience in a domain. When I do similar work internally at a company now, people are often surprised that I can come up with time estimates (and meet them) pretty easily.

You know how long your budgeted for it. Which is fine up to a point, but when things go over budget then corners get cut. And that costs in time further down the road.

I suppose you can always spend more time but the type of work I did didn't create downstream dependencies. There was no maintenance. (It was reports, competitive analysis, and the like.) Although I can't ever recall a situation where we were like:"It's not good. But it's good enough. Ship it."

That’s the kind of work that can be automated. You’re arguing with people who are doing new feature development almost exclusively. These are apples and oranges.

And frankly if you get too smug about it in a work environment you’re going to antagonize someone into scripting your job out of existence. So I wouldn’t pull on this thread too hard if I were you.

When a task is of known length is the time to automate it.