#The “Spreading Error Effect” of Modularity
I had a fascinating (at least for me) discussion with Julian Ariza Alvarez on modularity today. Julian is an engineer and quality control researcher at TU-Berlin. He was once part of a large research project involving a car company. The idea of the project was to have cars build entirely with modular parts – hundreds of exchangeable parts – so you can customize and evolve more quickly. But when testing the system something strange occurred: When you combine a large number of different modular parts you get an even larger number of potential points of failures.
For example when they combined a certain exhaust pipe with a certain connector to a certain motor after less than two years the motor broke down. Because there was something in the connection that attacked the motor slowly but progressively. And stuff like that happened in other combinations too.
Of course! If you build one product – one car – you chose one motor, one exhaust pipe and one connector. You monitor and debup the connection meaning you optimize the parts step by step till everything works for this particular combination. But if you have exchangeable building blocks the number of tests and optimizations you have to make explodes. 3 exhaust pipes and 3 motors and 3 connectors make already 27 combinations (instead of 3)! And when you test combination number 3 and discover that you have to change a part you have to do the first 2 tests again. And a car has many more parts that all play together. So the number of potential tests to make comes close to infinity. You might end up with a close to infinite number of points of failure.
Julian called this: “Fehler-Ausstrahlungs-Effekt” which is german and beautiful and might be translated with: “Spreading-Error-Effect”.
Here is OSVehicle’s “modularity” video that triggered the discussion.
The car is not the only example he told me about. He also spoke about a machine “to make everything” where you have just exchangeable heads/bits – a driller, a saw and so on. But every time with every new bit on top there are entirely different forces in the machine working. Normally you would optimize the connector between the bit and the rest of the machine for that specific forces. But if the connector and the machine is modular and for every bit the same there is no optimization. The result is a machine that breaks much faster.
I think this is a serious issue for modularity. At least for a number of areas.
I met Julian in the context of a research project that is about creating tools for collaborative open source hardware development. For open source hardware modularity and the use of standard parts is very important. Because if a software is open source I can download and install it in 5 minutes and start using it. If a tractor is open source I can download the building plan but I still have to build the whole tractor! I have to get all the parts and assemble them. It is important to use commonly available parts and structures in the design to make it easier to build the tractor everywhere. Modularity is a big enabler of decentralized open hardware production, development and use.
So one of the obvious ideas we had was that the tool for collaborative open source hardware development could collect errors – errors occurring in modular designs. And make them directly as feedback available for the designer: Every time someone plans this very same connection the software sends a warning. An open accessible database of errors. A huge, decentralized, crowd generated and openly available learning and development process for designing modularity.
This would actually be a really useful tool or feature in the tool.
Publish stuff that did not work! Publish studies that found nothing! This is has always been a demand of the open science community! With the internet we have enough space to make also negative results available. And we should. To prevent people from making the same mistakes again and again and enable us to learn faster and achieve more complex goals.
It could allow us to tackle and contain the “Fehler-Austrahlungs-Effekt” – the “Spreading-Error-Effect”.