[marginalia_nu]

There's real problems applying assembly-line optimizations to things that are not assembly-lines. Those problems are mostly related to the need for turning the operation into a sort of assembly-line before the optimizations can be performed, regardless of how poorly that model fits the reality of the work.

[psunavy03]

Ultimately, in a big enough org, software becomes an assembly line. Lean used right protects people and stops management from enforcing bullshit on the rank and file. But at a macro level, the only reason any dev has a job is because an end user says "I need the software to do this thing it can't already do." So how do you get it to them right with a minimum of fuss? That's Lean.

[Jensson]

> Ultimately, in a big enough org, software becomes an assembly line

Only when badly managed, if software production is like an assembly line it means the software produced is mostly worthless because there is no freedom for anyone to diverge or improve anything, meaning they don't add any real input so you don't actually need a programmer there.

Anything that can be structured as an assembly line of programmers should be automated or abstracted so that a large group of programmers don't need to touch the same change serially (assembly line), instead that assembly line of programmers can be much better done by a single programmer that does all the serial work himself, that way you can gain the benefits of programming.

Large scale software organizations should focus on parallel workflows, not assembly line workflows (serial). Serial team workflows in software just leads to worse products.

[marginalia_nu]

I'd argue that assembly lines create large organizations, rather than the other way around. Large organizations are not a positive thing in software development, as it scales very poorly with org size.