Exactly. The legal industry predominantly uses hourly billing and making up "equivalent hours" would be extremely unethical.

It's part of why I encourage everyone I know (particularly developers) to switch from hourly to fixed-price billing. Any efficiencies you gain should belong to you, not the customer. (There's also the fact that I find a lot more people are willing to pay $10k for X than $250/hr for 40 hours.)

The problem with fixed price as a developer is that rarely are requirements exactly understood or detailed enough to actually be able to bid the job. "Export to PDF" ok.. no problem -- that then turns into: "can you add page numbers? Can you support A4 - and US letter sizes?" And you have scope creep-- one more little thing isn't reasonable to say no to, however it quickly becomes a death by a thousand paper cuts. Ok, so now you price in that enevitable scope creep, so now your price is much higher. "$5000 to export to PDF? That's crazy!" -- yes but I am anticipating the fact that you don't know exactly what you want. "But we do, we made it clear!"

You see how that goes. Project pricing leads to a guessing game. Billing hourly is fair for everyone, at least in software. If I am more efficient, I pass that onto the customer. I don't 'lose' money -- it usually results in more work.

Imagine charging $80 for some corn because I want to make the same money as if I had guys hand-picking and hand seeding and doing the entire farming process without machines. That corn only cost me $0.10 to produce but I am charging a price as if I didn't have modern efficiencies. I would sell a lot less corn and actually profit less due to both competition and price elasticity. People would look for alternatives to corn.

In software, not passing on efficiencies means that there would actually be a smaller market for software development. Imagine how bad the market would be for us if we wrote everything in assembly. A simple web site might cost $100m and there'd be exactly 5 people in the world building websites.

Definitely.

I did some fixed price work this summer for a project where I thought the scope was unusually well understood by both sides. About 3 months, 60k USD if done by a fixed deadline (yes - fixed scope, fixed price, fixed deadline!) and as far as I was concerned from the original spec I had it done within about 6 weeks.

Of course, I spent the rest of the project time politely asking the customer to sign it off and doing the odd freebie to try and keep them happy but mostly at home, not working and not wanting to take anything else on in case they turned round and said I'd screwed up somewhere massively.

Perhaps unrelated, but I still haven't been paid for all of it either. Still, if I do eventually get paid it all it will have worked out better than charging per hour.

That's why Scope of Work documents exist: to protect against scope creep.

If a customer demands additional features, you prepare a Change Order and say, "OK, here is how long it will take and how much extra it will cost."

After a while they learn discipline and stop asking for changes half-way (or more) into the project.

Here is another perspective: the vast majority of features I've build as part of Change Orders rarely, if ever, got used. Granted, I make sure all relevant stakeholders are involved in the creation of the initial Scope of Work. That way, there are no late-comers who demand changes/additions.

The way I think about it is that general efficiency gains flow to the customer, while my unique efficiency gains are mine. So if it might take the average developer 100 hours to finish something but I can do it in 80, then I should charge as though it took 100.

The problem with hourly billing is it very poorly aligns incentives. It actually discourages efficiency because the easiest way for me to make more money is to take longer.

Also, psychologically, most clients are not comfortable with the vast differences in appropriate pay between developers. Even in the worst case (where scope was poorly defined and/or I estimated poorly), I'm making more now than I ever did with hourly billing.

If you had a monopoly on modern farming, it would absolutely make sense to charge $40 for corn. You'd soak up all the demand (since you're undercutting the $80 hand-harvesters) while still having massive profit margins.

Getting good at scoping is difficult but by no means impossible.

You can pass some, but not all efficiency gains on for a net win. Windows would cost billions if Microsoft only had one customer.

I chose my accountant because I could record my spendings online. He can just generate my yearly reports on one click in his backend, which he bills €80 for, "per click". He gives better advice because he has more customers, thanks to this efficiency, he doesn't spend time on mundane stuff and spends most his time meeting customers like me who present him various problems to solve, therefore he's more accoustomed to problem-solving.

Comapanies in my coworking space switch one after one. One has gone from a ~6500€ yearly bill to ~3500€ (3 employees), while improving reportability.

Non-industrialized accountants are just as necessary as human cashiers: Not. Lawyers are a bit harder to industrialize.

Yes - it's like Amdahl law, the faster they do their job, the more percentage of work that remains is marketing and finding clients.