If software developers want to be then seriously as a profession, they need to be able to provide and justify estimates for their work.

Everything you said could apply to a new bridge, building, pharmaceutical compound, or anything else that is the result of a process with some known and some unknown steps.

▲

wild_egg a day ago | parent | next [-]

> Everything you said could apply to a new bridge, building, pharmaceutical compound

"Everything"? So

> predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0.

Also applies to bridges? Bridges require a ton of manual human input at every stage of construction, regardless of how predictable and repetitive the work is. With software, we can write software to make those tasks disappear. I've yet to see the bridge that can build itself.

▲

bpt3 a day ago | parent [-]

1. When you have meaningful software that can build itself (and I'm not talking about the compilation process), let me know.

2. You can estimate the duration of each step of a process, regardless of how much human involvement is required.

▲

kragen 16 hours ago | parent [-]

You should be talking about the compilation process, because that's the thing that puts the cost of non-novel software at near zero, and you can't recompile a bridge for free.

Estimating the duration of each step of a process only works when you know what the steps are.

	▲	bpt3 13 hours ago \| parent [-]
		Effectively free distribution is what makes the cost of non-novel software so low. Compilation isn't even needed for executables that can be used as is. That said, implementation is one part of developing software. Design and test are also necessary and can take a non trivial amount of time. And yes, you need to know what the steps are to build something. If you don't, you don't know what you're doing, which is a bad thing.

▲

kragen 16 hours ago | parent | prev | next [-]

Drug discovery chemists do not, to my knowledge, provide estimates on how long it will take them to discover a marketable drug.

	▲	bpt3 12 hours ago \| parent [-]
		You think the pharmaceutical industry just gives a bunch of resources to chemists, says "godspeed", and waits around for the chemists to report back at their convenience? In my limited exposure to the industry, that's not how it worked. They have budgets, timelines, and progress is tracked as it is determined whether there is a viable path to a marketable drug.

▲

XorNot a day ago | parent | prev [-]

Pharmaceutical compounds frequently don't make it to market after significant investment.

No one in that industry is giving estimates based on developing brand new drugs - they're giving estimates related to manufacturing lead times, unalterable physics time lines, and typical time to navigate administrative tasks which are well known and generally predictable (but also negotiable: regulations have a human on the other end). All of this after they have a candidate drug in hand.

Same story with bridge building basically: no one puts an estimate on coming up with a brand new bridge design: they're a well understood, scalable engineering constructions which are the mostly gated by your ability to collect the data needed to use them - i.e. a field survey team etc. - and also once again, regulatory processes and accountability.

▲

bpt3 a day ago | parent [-]

Yes, that's my point. There's way more uncertainty in trying to bring a new drug to market or build a new bridge than creating yet another CRUD app, yet somehow they are any able to break these efforts into tasks that can be estimated and tracked and many software engineers think they should be exempt from any accountability to schedule or budget.

▲

Aeolun a day ago | parent [-]

And do you think those things are delivered on schedule any more often than software projects?

	▲	bpt3 a day ago \| parent [-]
		Take a look at the top of this thread and see what we're talking about. The fact that people in many industries are not good at estimating doesn't mean that it's impossible in software development specifically and uniquely, as was originally claimed.