Mate. I think their comment was a joke poking fun at how difficult it is to estimate something as (typically) defined as software is compared to something as novel and difficult as fusion.

I too was joking about how we must pass that estimate failure on like a hot potato as our duty. It was an ironic joke because it is usually true.

If I can divert from the joke; software development is like any development work which includes that such as fusion tech; is either progressing because the current task is running over tracks already laid and relatively easy to progress over or progress requires new track to be laid to proceed further on to completion. The difficulty of task is irrelevant to the process of development just the scales of everything, cost|time|reward might be larger or smaller.

Just because fusion is novel or difficult is irrelevant. It's a project with tasks todo. Those tasks may be mundane: akin to running over existing track or to proceed further: new track must be laid.

Laying new tracks includes over many problems with unknown dimension. The problems needing overcoming might be like voids, uneven terrain, unknown stability, on, under or around water.

All this takes time, which is arguably the most expensive resource as without any time invested towards a project task, none of any other material resources get manipulated into solutions.

So a project is always speeding along the tracks to the end of the line with a goal of laying more new track from the constantly shifting current position until the track is at the point of success/completion.

A project might find it necessary to backtrack due to an seemingly insurmountable / not worth it to continue this direction situation. It also can make progress in parallel. It's always laying new sections - some might be used for the final, some might be only used as scaffolding, some might be deemed a failed branch of track and not used in the final.

It's all just project management. Time and resources cost, how to use them. Accept when it didn't work as expected, the most important thing is to keep your failures small. Small failures typically take small efforts to correct, larger failures unacknowledged for longer typically take far longer to fix.

A good PM will have a way to keep pulse of the project without bothering the track layers constantly. The track layers might say, yup, usually it takes 10 min for the machine to put a new section down, you can't/shouldn't get disappointed when the machine may breakdown unexpectedly and doesn't lay the next track in 10min. As PM, it's your task to get that machine operational asap. You don't get to get upset the track layers cannot continue in that case - but many do. Many PMs also lay track where they think a customer wants the track to go but are in fact oblivious because they don't keep the stakeholder|customer updated with progress. Frequent communication is better. Not too much, perhaps, but certainly not too little so issues and ramifications are stacking up with stakeholders unaware.

Another analogy: Development, R&D, is all sprinting straight into the next wall. Over and over again.

Some walls are easier to proceed past. Some walls are planned and expected for, others are not. Again, the size and composition is irrelevant: it's just another wall. A decision is required on the implementation method. Do we go through, over, under, or can somehow just go around it - not taking that wall on altogether. So spec. the how, get the team onto perhaps researching the situation first, get to implementing.

Just because a wall comes up isn't necessarily a "fault" of anyone, the sprinter or management. It's fact of life and process. Accept it. Handle it.

Blaming doesn't actually cause progress to be made - all it does is assign blame, justly or unjustly. Accident investigations might not even assign blame, they seek to understand the situation to learn from it so the industry can learn and not make repeat mistakes. Even in the case of say a pilot suicide, there's more to learn than: that pilot killed everybody on purpose. I'd hope in that case, a framework and processes would be mandated to prevent that happening easily again.

That's all where management should be concerned. In my opinion.