[jaggederest]

Somewhat heretical, but I generally don't.

I usually explain that development is an iterative process, and that I generally deliver work as soon as it's done.

We talk about the knobs that are available to tune the work to the goal, and how to measure goals. We talk about containing costs, and working together to deliver good value.

I find that in general, estimates are rarely, if ever, accurate to any significant degree, and thus are usually dishonest when presented as a way to assuage client anxiety over "when will it get done" or "how much will it cost".

[crispyambulance]

Completion estimates may be dishonest but that's how things are done almost everywhere, yes, even shops that use Agile, complete with burn-down charts, stand-ups and sprints. I've seen "Agile" teams that go through all the motions of a modern sw development team BUT STILL have to give the completion date of the whole project! Before the work starts!

FWIW, it's not as bad as it sounds, it just means that the PM's see red in their charts and end up bugging people with "urgency attacks". Slippage is common and that's OK.

The vast majority of the time, an estimate is just an estimate. Passing a deadline isn't fatal, nor is it failure (regardless of whatever it says in the Project Management Book of Knowledge).

[rossdavidh]

The only right answer. If they cannot accept a diplomatic, reasoned and carefully explained "we can't know, but I'll finish as quickly as I can" answer, then they probably won't be very understandable when things turn out to take longer than expected. Or if they change their mind about what they want and expect you to nonetheless finish on the original schedule because it's just a small change. Politely and gently refusing to provide an estimate for the unknowable, is a good way to avoid working with clients who will be not worth working with anyway.

Hard as this is up front, it's harder to explain afterwards why your estimate didn't work out, and it's harder to eat the cost difference yourself. Be gentle and polite, and accept that they may or may not be willing to work with you on trust that you will do your best to finish as quickly as you can.

[novembermike]

I think you can usually say if something will take hours, days, weeks, months or years. Anything more detailed runs into problems.

[ryan-allen]

I find estimating dishonest too. I tell clients that a project becomes late 'one day at a time' and that the higher clarity there is in the objective, the more creative we can be about trying to solve the problem. so there is less work to undertake to reach it.

I don't think a developer's salary is high enough to justify taking on any moral risk on the basis of estimation of any project.

In Australia, even the highest budget software projects have major cost and time blow-outs, often in years and often in 100s of millions of dollars. If this were a solved problem then this would not be the case.

I think the best thing you can do is retrospective analysis of work completed for a given individual and a team, and use that to project, but I am yet to find a client who is vaguely interested in such a thing, e.g. Joel on Software's Monte Carlo estimation solution [0].

I'm cynical because it's early!

[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

[shireboy]

This sounds great. How the hell do you get customers to buy into it though? I often wind up falling into this sort of situation with old customers once they're confident in my work and fairness. But for new customers, how do you tell them "don't worry about how much this will cost or how long it will take"? How do you build that in a contract?

[jaggederest]

I personally guarantee my work. If they don't like the work, I'll refund their deposit, revert the merge(s), and be on my way. I never bill for work that doesn't satisfy the client.

[shireboy]

Don’t some still balk at an open ended contract though? They have budgets etc that limit what they can spend.

[shubb]

This is the best way, especially if you are freelance and might carry some of the risk or a drop dead deadline.

If you do this, some people will work with you,

some people will not.

If you work with those people, this will not work.

Sadly

[ncphillips]

I don’t think this should be heretical. I’m pretty sure all the evidence is in favour of your view.

[williamdclt]

> development is an iterative process, and that I generally deliver work as soon as it's done

You're kinda arguing against yourself. I agree that dev is an iterative process and that estimating is a lost cause, but "deliver work as soon as it's done"? The whole point is that a "done" project doesn't exist. Deliver all the time (every day, every week at worst), iterate and stop the project when the client is happy with what they have

[mikekchar]

I think the key is that showing progress early and often lets the customer start to get a feel for how long the entire process is going to take. This is one of the reasons for XP's idea of trying to do "vertical" but narrow slices of the application. Each story you work on should work through as many layers of the application as you can manage.

It's easy to write stories that are "do the UI for X", and then "do the back end for X". But often the UI (at least the first cut) is easy to code and comes out quickly, giving the customer the impression that everything will be quick. Then you work on the back end and it goes a lot more slowly, leading to mistrust. Alternatively, working on really complicated things up front (while generally a good idea) can give the customer the impression that the project is stalled and that it's never going to finish.

When you are doing iterative development, I think the real art is in choosing your stories. It's difficult, but when done well it removes most of the political friction in development.

[jaggederest]

I really mean done as in "creates any positive change for the customer". Obviously if a file has syntax errors you don't push that to production. I usually do CI/CD really aggressively. Deliver as soon as the PR is approved or equivalent, assuming you have enough assurance in the form of test or qa. I would consider daily to be a little slow for my tastes.