Construction and manufacturing are usually about cookie cutter replicas, with log degrees of customisation. There isn't a feedback loop in the manufacturing line to product development once you have a stable product.

This is roughly analogous to corporate IT operations. There's a set of standard services which everyone uses, and there's no innovation on the desktop by most users.

On the other hand, with software and R&D, the feedback loops are primary drivers of generating information (and value). This is why so many of us preach about "testing in production" for web services.

The core of these two philosophies is pretty much summarised by two books: The Goal, by E. Goldratt (ISBN: 9780884271956 ). The Principles of Product Development Flow, by D. Reinertsen (ISBN: 9781935401001).

Construction and manufacturing are very much about following defined instructions and processes and not updating or deviating from them without good reason. (Obviously there's a lot of Get Stuff Done too, where people ignore the above rules).

Manufacturing Management is also all about metrics and counting productivity. Trying to apply similar metrics to tech leads to things like counting developers lines of code or defects.

---

Edit: another aspect of manufacturing is limiting waste. In Toyota Production system this is called Muda - https://en.wikipedia.org/wiki/Muda_(Japanese_term)

Waste of overproduction (largest waste)

Waste of time on hand (waiting)

Waste of transportation

Waste of processing itself

Waste of excess inventory

Waste of movement

Waste of making defective products

Waste of underutilized workers

You can look at the other goals of TPS and see how they may or may not apply to software engineering: https://en.wikipedia.org/wiki/Toyota_Production_System

I'm not saying these are bad ideas or don't apply to software engineering, but I am saying that they don't apply in the same way.