A theme running through my book is the idea that efficiency improvements, and the various methods for making products cheaper over time, have historically been dependent on some degree of repetition, on running your production process over and over again.
Well I generally agree with your article, I think you must note that car manufacturers have optimized the manufacturing processes at the expense of maintenance processes. When you have to remove body parts in order to replace a headlight the efficiency of the repair process breaks down completely. I have seen cars like the Ford explorer where it takes about 6 hours of the mechanic time to remove all the parts replace the headlight assembly and replace the rest of the parts.
A second Factor is the manufacturers build things in a way that you can't replace a simple part, such as a light bulb. Instead you have to replace the whole headlight assembly. This is particularly evident if you've ever had to replace a valve body on a Subaru transmission.
Totally agree. I had someone damage the rear tail light of my 2 year old Ranger and instead of having to just replace the lense cover the entire light unit had to be replaced and on top of that all the electronics of lane assist, etc. are built into the light unit which then needs to be recalibrated. Total bill was well over $1,000.
It appears to me your AWS paradigm for manufacturing breaks down in the material handling/transportation issue. AWS may be able to provide a multitude of software solutions, but the delivered product is always electrons traveling down a wire. It's actually delivering a single identical product. Manufacturing delivers a multitude of products requiring a multitude of different material handling solutions.
In the coming decade we might see the golden age of low volume manufacturing and hence a return of the age of the independent inventor like the 19th century.
Car repair should be divided between collision and component failure. For various reasons, cars have gotten much more complex making diagnosis more difficult and time consuming. I would guess that the cost of repairing component failures saw an inflection point when pollution controls and computer control of auto systems began to dominate. My 2002 car had a microprocessor in each door just to control the lock and window!
And don’t forget that dealerships make most of their money on repairs.
I looked at this a little bit more closely. For motor vehicle manufacturing, the BLS does an inflation adjustment to account for quality increase, the fact that cars have more features/functionality over time (I believe this is why inflation says prices have been mostly flat/falling with respect to inflation even though the absolute price of cars has gone up. So the extra complexity/features is accounted for in the "new car" inflation index.
However, it seems (according to Claude anyway) that this sort of quality adjustment is not done for motor vehicle repair overall. This could potentially cause repair inflation to look higher than it is, since a given "repair" is actually restoring more functionality today than it was historically.
BUT, the BLS has subcategories of motor vehicle repair inflation, including bodywork (fixing damaged frames, panel dents, painting, etc.). Trends in the cost of bodywork are basically the same as overall repair, rising at/faster than overall inflation. I think there's less of this sort of creeping complexity/functionality in car bodies over time than there is in the rest of the car (though there's not none, since a modern car body is safer than one historically).
So overall, I agree that rising complexity is part of the reason for high repair inflation, but not all of it.
The problem with a service like car repair is that the first step of the process is always: figure out what is wrong. Every subsequent step depends on the outcome of that first one. That’s not “variability” or low volume production, it’s troubleshooting. Troubleshooting is hard to teach, let alone automate. Car repair and other services that start out with troubleshooting will resist automation a lot longer than anything else.
That said, your subsequent discussion completely ignored the troubleshooting aspect and described processes that all have known starting points, albeit with flexible paths from there. Given that caveat, your discussion is right on.
I would like to see, however, a discussion specific to automating troubleshooting and what kind of automation and processing might be required for that.
"Figuring out what is wrong" is a variability problem. You have the same "figure out what exactly I should be doing" step with high volume manufacturing (figuring out exactly what your process should be), and it historically has been similarly hard to automate, but you can do it once and run the process a thousand or a million times. With repair you need to do the figuring out step each time, so you can't spread those costs thinly.
The difference is that first step as you describe it is done once when the process is defined, then repeated when the process is modified. In the case of tasks such as car repair, that step occurs every time the process is executed. An apt analogy would be that when faced with a car that needs repair, the entire repair process is defined each time.
There have been significant advances in on-board diagnostics, which help with breakdowns and such, but don’t provide much help when an accident caused the problems.
On your discussion of AWS, spinning up infrastructure at a moments notice works very well. In the medium to long term, the nature of that infrastructure may make it more cost effective to bring in-house, but that can be decided later. Need a server and your laptop won’t handle it? Spin one up. Need a different OS than you have? Spin one up. Only the necessity of physical proximity negates that decision.
Great article. Just one request: don't use AWS as your analogy. I get that it's very well known and therefore a great hook but the economics just don't match out.
AWS is far too expensive to be justified based on economies of scale (in hardware at least). The joke is that with AWS, companies buy the hardware every few months. The real benefit of AWS is that it works around two serious market failures:
1/ Company CTOs congenital unwillingness to pay for software. This happens in large part because they are incapable of differentiating between good and bad software. And one slice of said software happens to be extremely bad but also nominally free and that short-circuits people's brains.
2/ large companys and their entrenched bureaucracies that gate-keep basic IT services like new machines and storage drives.
AWS fixes both these problems. It pretends companies are paying for hardware when they are really paying for management software. With products like managed databases, this pretension is even thinner. We can see also that services which offer only colocation (e.g. Hetzner) are only able to charge a tiny fraction of what the major cloud providers charge.
It fixes the second problem because it very loudly advertises it's abilities. When the underlying system is capable of provisioning a new cloud bucket in seconds, it is much harder for the resident incompetent IT department to claim that they need seven pages of docs and four weeks to provide the same service.
Which is not to say that the cloud providers haven't innovated in hardware. They have! But this nets them only around a 2x reduction in cost. And their prices are more like 10x _higher_ than just the underlying hardware.
The economies of scale for AWS happens on Amazon's side: it gets cheaper for them to serve customers the more customers they serve. What they charge for that service is a different question entirely.
That doesn't quite work because software is so easy to distribute (modulo self-inflicted problems like OS design). They could have distributed the software but nobody would have been willing to pay for it. Even now, there are lots of companies (large ones like VMWare but also smaller ones like Oxide) that are trying to. There's a reason customers aren't switching to them despite much lower costs.
Besides, efficiencies in production are irrelevant to purchase decisions unless customers get a share of the savings. Otherwise, why bother using the "lower cost" provider at all? In the case of AWS, customers are paying higher costs than self-hosted hardware.
You are suggesting that much of the value of AWS is that they move costs from a slow bureaucratic approval of capital expenses to a less painful approval of operating costs. That is still a valuable service in the world we actually live in; perhaps more valuable than a reduction in vendor price.
Yes. And more importantly, they eliminate a lot of the processes entirely and replace them with API calls. That too is genuinely valuable. But note that all that is software and process. None of it is hardware which was my point.
A great comparison between manufacture and AWS is how water jeg and laser cutter job shops work now, water jets and laser cutter can cut basically any shape you tell them to, but it’s not practical for every factory to have their own, so job shops nest as many parts as they can into a sheet of steel or aluminum cut out all the parts and process them together before splitting for shipping. In fact more variety of shapes and sizes can make the packing more efficient too, small parts fill gaps in larger parts, more parts means more likely there’s a pattern that fits tightly together
This channels Alvin Toffler's "Future Shock" published in 1970. Even then, the American auto-buyer could specify a score of options when ordering a car, and FRED the Magical Mind made such production-line flexibility possible. Toffler would not have been surprised by AWS and its siblings. Indeed he might have asked, What took them so long?
Skyrocketing auto repair costs are attributable to one factor, bad design. Components frequently accessed at normal service intervals should be accessible, and they're not. The not very subtle denial of the right to repair noted by other commenters here, contributes.
I'm currently working on the notion of blockchain as a simiarly ubiquious "for everything" tech in my academic work. I think a lot of this framing is tied to the braoder imagination of quantification/datafication as the solution to progress that goes along globalisation and the growth of software as the source of capital value. Efficiency here is just as much a construct as a "real" driver of progress.
You might be interested also in the work of value studies and sociology of finance that traces similar histories of "everything" in the economy (financialisation and assetisation "of everything"), such as Bruce Carruthers "Financialization and the Institutional Foundations of the New Capitalism" and Birch and Muniesa "Assetization."
Sendcutsend and JLCPCB are just slapping software on existing processes. Automated PCB assembly looks high mix and complexity but all the parts are standardized in packaging and even the part storage and handling is standardized. JLCPCB makes the scale only by mass prototyping the assembly process. Changes from one component to another just mean changing a reel. Send cut send is just cutting shapes out of rolls of material with a CNC or laser that can cut any arbitrary shape. Sheet metal processing alone is highly automated since every appliance, computer case, locker or bracket is made of sheet metal. Additionally sendcutsend is the same business as Front Panel Express which dates from the late 1990s
But that software layer means the fixed cost/Non-Recurring Engineering goes from prohibitive to affordable. I could design and order a PCB for a hobby project, but I don't need 1000 of them. If the setup fee is $1, I can pay that; if it is $1000 I won't, because I can't really amortize costs across the other 999 copies that I don't need. JLCPCB can collect a per-board fee from dozens of people like me and get enough revenue to make the combined panel worth making, even though _I_ couldn't justify a full panel on my own.
In a sense this already exists. It's called China.
One problem is the broad variety of equipment needed for general manufacturing. Such an "AWS" would have to be able to work with wood, metal, composites, plastics, glass, wiring, plumbing, electronic components and a host of other things. The outfit that did our new kitchen cabinets has a million dollar machine optimized for cabinet work. The capital cost of an "AWS" would be many, many times larger and would have to deal with problems of utilization rate. Any investors would expect cash flow commensurate with the capital cost.
Toll manufacturing has always ben important for not-biggest players. Your theory should then basically mean that toll manufacturing should help the small guys too. That would be great, but it feels like the direction right now is just one or a few companies are going to be the big players and the toll player.
Well I generally agree with your article, I think you must note that car manufacturers have optimized the manufacturing processes at the expense of maintenance processes. When you have to remove body parts in order to replace a headlight the efficiency of the repair process breaks down completely. I have seen cars like the Ford explorer where it takes about 6 hours of the mechanic time to remove all the parts replace the headlight assembly and replace the rest of the parts.
A second Factor is the manufacturers build things in a way that you can't replace a simple part, such as a light bulb. Instead you have to replace the whole headlight assembly. This is particularly evident if you've ever had to replace a valve body on a Subaru transmission.
Yes, this is a good point, there's a tradeoff between manufacturability and ease of repair.
Totally agree. I had someone damage the rear tail light of my 2 year old Ranger and instead of having to just replace the lense cover the entire light unit had to be replaced and on top of that all the electronics of lane assist, etc. are built into the light unit which then needs to be recalibrated. Total bill was well over $1,000.
It appears to me your AWS paradigm for manufacturing breaks down in the material handling/transportation issue. AWS may be able to provide a multitude of software solutions, but the delivered product is always electrons traveling down a wire. It's actually delivering a single identical product. Manufacturing delivers a multitude of products requiring a multitude of different material handling solutions.
In the coming decade we might see the golden age of low volume manufacturing and hence a return of the age of the independent inventor like the 19th century.
Car repair should be divided between collision and component failure. For various reasons, cars have gotten much more complex making diagnosis more difficult and time consuming. I would guess that the cost of repairing component failures saw an inflection point when pollution controls and computer control of auto systems began to dominate. My 2002 car had a microprocessor in each door just to control the lock and window!
And don’t forget that dealerships make most of their money on repairs.
I looked at this a little bit more closely. For motor vehicle manufacturing, the BLS does an inflation adjustment to account for quality increase, the fact that cars have more features/functionality over time (I believe this is why inflation says prices have been mostly flat/falling with respect to inflation even though the absolute price of cars has gone up. So the extra complexity/features is accounted for in the "new car" inflation index.
However, it seems (according to Claude anyway) that this sort of quality adjustment is not done for motor vehicle repair overall. This could potentially cause repair inflation to look higher than it is, since a given "repair" is actually restoring more functionality today than it was historically.
BUT, the BLS has subcategories of motor vehicle repair inflation, including bodywork (fixing damaged frames, panel dents, painting, etc.). Trends in the cost of bodywork are basically the same as overall repair, rising at/faster than overall inflation. I think there's less of this sort of creeping complexity/functionality in car bodies over time than there is in the rest of the car (though there's not none, since a modern car body is safer than one historically).
So overall, I agree that rising complexity is part of the reason for high repair inflation, but not all of it.
The problem with a service like car repair is that the first step of the process is always: figure out what is wrong. Every subsequent step depends on the outcome of that first one. That’s not “variability” or low volume production, it’s troubleshooting. Troubleshooting is hard to teach, let alone automate. Car repair and other services that start out with troubleshooting will resist automation a lot longer than anything else.
That said, your subsequent discussion completely ignored the troubleshooting aspect and described processes that all have known starting points, albeit with flexible paths from there. Given that caveat, your discussion is right on.
I would like to see, however, a discussion specific to automating troubleshooting and what kind of automation and processing might be required for that.
"Figuring out what is wrong" is a variability problem. You have the same "figure out what exactly I should be doing" step with high volume manufacturing (figuring out exactly what your process should be), and it historically has been similarly hard to automate, but you can do it once and run the process a thousand or a million times. With repair you need to do the figuring out step each time, so you can't spread those costs thinly.
The difference is that first step as you describe it is done once when the process is defined, then repeated when the process is modified. In the case of tasks such as car repair, that step occurs every time the process is executed. An apt analogy would be that when faced with a car that needs repair, the entire repair process is defined each time.
There have been significant advances in on-board diagnostics, which help with breakdowns and such, but don’t provide much help when an accident caused the problems.
On your discussion of AWS, spinning up infrastructure at a moments notice works very well. In the medium to long term, the nature of that infrastructure may make it more cost effective to bring in-house, but that can be decided later. Need a server and your laptop won’t handle it? Spin one up. Need a different OS than you have? Spin one up. Only the necessity of physical proximity negates that decision.
How about Anduril? Is this not their pitch?
I don't know enough about Anduril to know what their manufacturing strategy is.
Great article. Just one request: don't use AWS as your analogy. I get that it's very well known and therefore a great hook but the economics just don't match out.
AWS is far too expensive to be justified based on economies of scale (in hardware at least). The joke is that with AWS, companies buy the hardware every few months. The real benefit of AWS is that it works around two serious market failures:
1/ Company CTOs congenital unwillingness to pay for software. This happens in large part because they are incapable of differentiating between good and bad software. And one slice of said software happens to be extremely bad but also nominally free and that short-circuits people's brains.
2/ large companys and their entrenched bureaucracies that gate-keep basic IT services like new machines and storage drives.
AWS fixes both these problems. It pretends companies are paying for hardware when they are really paying for management software. With products like managed databases, this pretension is even thinner. We can see also that services which offer only colocation (e.g. Hetzner) are only able to charge a tiny fraction of what the major cloud providers charge.
It fixes the second problem because it very loudly advertises it's abilities. When the underlying system is capable of provisioning a new cloud bucket in seconds, it is much harder for the resident incompetent IT department to claim that they need seven pages of docs and four weeks to provide the same service.
Which is not to say that the cloud providers haven't innovated in hardware. They have! But this nets them only around a 2x reduction in cost. And their prices are more like 10x _higher_ than just the underlying hardware.
The economies of scale for AWS happens on Amazon's side: it gets cheaper for them to serve customers the more customers they serve. What they charge for that service is a different question entirely.
That doesn't quite work because software is so easy to distribute (modulo self-inflicted problems like OS design). They could have distributed the software but nobody would have been willing to pay for it. Even now, there are lots of companies (large ones like VMWare but also smaller ones like Oxide) that are trying to. There's a reason customers aren't switching to them despite much lower costs.
Besides, efficiencies in production are irrelevant to purchase decisions unless customers get a share of the savings. Otherwise, why bother using the "lower cost" provider at all? In the case of AWS, customers are paying higher costs than self-hosted hardware.
You are suggesting that much of the value of AWS is that they move costs from a slow bureaucratic approval of capital expenses to a less painful approval of operating costs. That is still a valuable service in the world we actually live in; perhaps more valuable than a reduction in vendor price.
Yes. And more importantly, they eliminate a lot of the processes entirely and replace them with API calls. That too is genuinely valuable. But note that all that is software and process. None of it is hardware which was my point.
A great comparison between manufacture and AWS is how water jeg and laser cutter job shops work now, water jets and laser cutter can cut basically any shape you tell them to, but it’s not practical for every factory to have their own, so job shops nest as many parts as they can into a sheet of steel or aluminum cut out all the parts and process them together before splitting for shipping. In fact more variety of shapes and sizes can make the packing more efficient too, small parts fill gaps in larger parts, more parts means more likely there’s a pattern that fits tightly together
Good post!
Topics like Design for Repairability, Right to Repair and Repairability Scores deserve a post - a lot has happened, but not nearly enough.
This channels Alvin Toffler's "Future Shock" published in 1970. Even then, the American auto-buyer could specify a score of options when ordering a car, and FRED the Magical Mind made such production-line flexibility possible. Toffler would not have been surprised by AWS and its siblings. Indeed he might have asked, What took them so long?
Skyrocketing auto repair costs are attributable to one factor, bad design. Components frequently accessed at normal service intervals should be accessible, and they're not. The not very subtle denial of the right to repair noted by other commenters here, contributes.
https://substack.com/@sajibhowlader/note/c-229267562?r=172675
https://substack.com/profile/72324833-mdsajib-howlader/note/c-229268038?r=172675
I'm currently working on the notion of blockchain as a simiarly ubiquious "for everything" tech in my academic work. I think a lot of this framing is tied to the braoder imagination of quantification/datafication as the solution to progress that goes along globalisation and the growth of software as the source of capital value. Efficiency here is just as much a construct as a "real" driver of progress.
You might be interested also in the work of value studies and sociology of finance that traces similar histories of "everything" in the economy (financialisation and assetisation "of everything"), such as Bruce Carruthers "Financialization and the Institutional Foundations of the New Capitalism" and Birch and Muniesa "Assetization."
Sendcutsend and JLCPCB are just slapping software on existing processes. Automated PCB assembly looks high mix and complexity but all the parts are standardized in packaging and even the part storage and handling is standardized. JLCPCB makes the scale only by mass prototyping the assembly process. Changes from one component to another just mean changing a reel. Send cut send is just cutting shapes out of rolls of material with a CNC or laser that can cut any arbitrary shape. Sheet metal processing alone is highly automated since every appliance, computer case, locker or bracket is made of sheet metal. Additionally sendcutsend is the same business as Front Panel Express which dates from the late 1990s
But that software layer means the fixed cost/Non-Recurring Engineering goes from prohibitive to affordable. I could design and order a PCB for a hobby project, but I don't need 1000 of them. If the setup fee is $1, I can pay that; if it is $1000 I won't, because I can't really amortize costs across the other 999 copies that I don't need. JLCPCB can collect a per-board fee from dozens of people like me and get enough revenue to make the combined panel worth making, even though _I_ couldn't justify a full panel on my own.
In a sense this already exists. It's called China.
One problem is the broad variety of equipment needed for general manufacturing. Such an "AWS" would have to be able to work with wood, metal, composites, plastics, glass, wiring, plumbing, electronic components and a host of other things. The outfit that did our new kitchen cabinets has a million dollar machine optimized for cabinet work. The capital cost of an "AWS" would be many, many times larger and would have to deal with problems of utilization rate. Any investors would expect cash flow commensurate with the capital cost.
Toll manufacturing has always ben important for not-biggest players. Your theory should then basically mean that toll manufacturing should help the small guys too. That would be great, but it feels like the direction right now is just one or a few companies are going to be the big players and the toll player.