"Error-Spread-Out" Effect in Modularity
- This topic has 1 reply, 2 voices, and was last updated 5 years ago by .
I stumbled across this article and discovered that modular projects, since they add an exponential number of combinations, also tend to increase the potential points of failures of a product.
Here is an example the article gives on a modular car:
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.
A solution they suggest would be to develop a tool to collect errors, so they can be quickly optimized.
It would be great to expand on this topic and see what other projects have come across this challenge, and if they have been able to tackle it in some way.
Has this already been discussed in this forum?