(Meta: Post is part of Mifacori’s research project on 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 an exhaust pipe with a connector with a 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 debug the connection, meaning you optimize the parts step by step till everything works in 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 and test cases (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 at work. Normally you would optimize the connector between the bit and the rest of the machine for this 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 (not necessarily for furniture I guess).
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 the tractor with them. It is important to use commonly available parts and structures in the design to make it easier to get the necessary parts and build the tractor everywhere. Modularity is a big enabler of decentralized open hardware development, production 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 when developing modular designs. And make them available as direct feedback for the designers when they create something. Every time someone plans something that is known to fail the software sends a warning. And designers teach the software by letting them know about points if failure. An open accessible, crowd created and intelligent database of errors. A huge, decentralized 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 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 over and over 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”.