Hacker News Reader

Comment by csours | Hacker News Reader

> "Technology people sometimes get this worldview that they are the sun, and the universe revolves around them. Hate to break the news, but no."

I've worked construction and at a manufacturing plant, and tech is a genuinely different business, with a different mindset than other businesses. Yes, they are failing the business, but they are failing the business in a new and interesting way, which is what this post is about.

Tech is the engine that accelerates business. Acceleration used to be slow. If you don't have an engine that accelerates quickly now, and you don't have a HUGE moat, you won't survive.

View on HN

Can you give some examples of the mindset of construction and manufacturing businesses? It would be interesting to me, and I think to other people here too.

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.

Well, for one, TPS is attempting to optimize the manufacturing of a fixed design.

With software the design-made-code, where software is what in automotive would be considered the design process is 100% of the cost, the shipping of bits is 0%. In automotive, it is more like 5% design vs 95% building the car, goes the other way.

When people apply manufacturing methodologies to design practices, it rarely works out. "Design" is messy, but people expect to be able to apply a manufacturing-like "LEAN" process to it. They are mixing goslings and goats.

a lot of "LEAN" is about making work pieces smaller. This not only reduces waste, but allows quicker reaction time when you do need to change something.

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).

Reply on news.ycombinator.com