You're describing Copy Exactly (CE!):

https://www.extremetech.com/computing/127987-deliberate-exce...

> Intel began working on CE! after it had trouble at the 0.5um (500nm) node and refined the process through each successive generation. The green line shows the initial product ramp at its first fab — after an early spike, yields cratered and only recovered over a period of months. Once Intel had Fab 1 working well on 0.5um, it started ramping Fab 2 only to run into new problems. As Copy Exactly! was developed and deployed, the company’s yields synchronized across the various fabs.

Because they don't know enough to predict the process effects of variations in humidity, barometric pressure — or pipe length! — they eliminate those variations instead. Presumably they would learn more if they didn't do that, but they would also take longer to ramp up production. Since they started doing CE! in the 1980s, it's probably not a primary cause of their late-2010s decline.

I used to work in R&D for developing the machines used in the fabs. Sometimes the trivial details make a difference in the results and you don't always have to time to isolate and analyze each little thing. If you have a proven recipe, don't change it unless you have a reason.

To a first-order approximation, engineering is about minimizing costs, and a large fraction of the cost of creating and running a fab is the cost of the time of the employees able to understand things from first principles. So, just because they decided to avoid that cost doesn't mean they are unable to redesign the pipes from first principles.

I don't think it was cargo-culting in the case of that fab. A fab isn't like your mother's ham, which she cut in half because her mother cut it in half, only to find out that her mother had a small oven. A fab is like that tricky piece of code that has a comment on every line, but instead of one function it's 20,000 lines of that. On top of that, it takes several weeks before you know if your wafer came out okay. So when you duplicate your fab, the last thing you want to do is add more potential problems. Think of it like using a software library; you don't go rebuild the library each time you use it, you just copy it into your project. Sure, there's unnecessary piping, but you don't care. If you cared you'd write your own library in assembly language and it would be a shining example of efficiency and understanding. But maybe you just want to solve your problem and ship.

How many R&D engineering hours do you think the extra 1m of piping equals in cost?

I'm actually surprised they didn't go and put a column there, too, just in case.

The point is that they probably have no idea what else they would have to change/retune in that process to account for the pipes being straight. It makes sense that they would seek to avoid changes to the greatest possible extent, given the costs involved.