No, delivering software is not factory work, but it IS engineering work, just like any other. All engineers have expectation of quality, reaching deadlines and finishing their solutions.
Developers aren't special snowflakes in this regard.
Even artists have to be accountable for their pieces of art.
This is engineering, and just like in all other branches, accountability is part of the rules of the game.
Any software package that doesn't work should be returned and paid back for, this teaches software houses to pay more attention before dumping stuff into stores.
Proper consulting work contracts already have warranty clauses for support, on contractor's own costs, after delivery.
It seems that until goverments wake up for it, most companies won't care until they have a law falling on their heads, but as the recent US cybersecurity act and ongoing EU regulations show, it is slowly but surely coming to arrive.
It's complexity, not creative work. There are entire industries based on delivering creative work on strict deadlines. The quality of the products is often unpredictable due to the nature of creative work, but the people doing the work can meet the deadlines reliably. In a complex project, the unpredictability affects both the quality and the functionality of the product.
The transition from accountability to predictability was rather unmotivated. I guess accountability is a strategy of optimization. You want to identify when sufficient gains can be made by unilaterally adjusting the process of an individual or team or organizational unit, and reinforce that adjustment with reward/punishment ranging from feelings of usefulness to monetary reward to continued employment.
If you model your productivity as hierarchical composition of dynamical systems, then I guess predictability would be a rapid step response, unilaterally in each parameter, in each system. Losses in productivity could then be traced back each system and form a low-latency feedback loop.
This model is cold and calculating and probably wrong. I just want to try make it more concrete.
Software development is inherently unpredictable because the software target landscape is intrinsically chaotic (a very small change in target can introduce a very large change in effective resulting energy needed to reach the target), and every new project inevitably means a new target (if not no software development would be needed as you'd already have the software).
And the tension, where it exists, is from bean counters trying to model everything as an assembly line.