Transcending Brook's Law
Transcending Brook’s Law: Modular Development
The seminal book, The Mythical Man Month (ref) discusses Brook’s Law - the paradox that at a certain point of complexity in project development - adding more developers delays a project even further. This gets in the way of development scalability, which is a prerequisite for large-scale collaborative projects like OSE. So how do we achieve the capacity to build a team and design a new civilization from scratch in 1 year with 10,000 developers?
The simple answer is modularity: breakdown of a large project into small parts. Modularity applies on 2 levels: modularity of the technology, and modularity of the process architecture for development.
Modularity of machines means that we break down the machines into modules, say 10 modules. We can further break these modules into 10 submodules - which may be closer to the universal mechanisms that make up all artifacts. As long as we also define the interfaces between these modules - then development can occur completely in parallel for all the parts. As such - we have achieved a 100x development velocity increase potential - which can be realized if we recruit 100 people to work on the tasks in parallel.
Fig. Modularity of GVCS hardware Design affords 100x development velocity increase.
Can we really achieve 100x development? There are tricks to that. Test-driven-design, rapid iterations must be applied to test every piece of the development so that when a product is assembled, it is already pre-tested, and the final product actually works.
For the 100x to be realized, the breakdown of the product must be strategic, its interface design must be strategic, and its testing protocols must be strategic. All of these must be designed such that they minimized dependencies and maximize the ability to work on many steps at a time. Understanding of the hardware is required, and understanding of the development process is required.
Modularity of the development process architecture means that just as we have broken down the machines into parts, we have broken down the steps for developing each part into many steps. Development process architecture involves technical product development, enterprise development, and development of the development framework itself. Roughly speaking, there are 100 such items that must be attended to - and which can all be done in parallel as well. Therefore, a modular process architecture affords a further 100x development acceleration.
Fig. Modularity of the hardware development process affords another 100x development velocity increase.
Thus, we have effectively achieve a potential 10,000x development velocity increase. This is mind-blowing acceleration potential It should be noted that such a large-scale process assumes open boundaries - where everyone has immediate access to information, tools, repositories, roadmaps, and all supporting resources for zero-waste development. As such, this development process can be carried out only within a collaborative, open source framework.
Linux has achieved about 400x development acceleration.
But the potential of open hardware development does not stop there. When we reframe development as a construction set approach, we gain significant further development acceleration. A construction set approach means that instead of treating modules and submodules as dedicated parts of machines - these parts become interchangeable by design. While this is clearly true for simple parts such as a bolt - which can be used in many different machines - the same design principle can be used for more complex parts/modules/submodules. The challenge there revolves around interface design which allows a part to be used in many different contexts. If we put more attention to the interface design, we can end up with more flexible-use parts. For example, instead of designing modules for a tractor, we can extend our requirement to make those modules multipurpose. The key is understanding what is parameters are acceptable such that a design gives adequate performance. The concept of robustification (ref) arises here - ie - parts are designed to be robust - or fit for multiple uses in different conditions - by design. In sum - when we design the parts for a tractor - the same parts can essentially be used to build a microtractor, a bulldozer, a truck, and a car - and if we use a few more additional modules - we can build a backhoe, loader, cement mixer, haying equipment, a combine, and others. We can nominally say that instead of making one machine - we are really designing 10 machines - thus we are now extending our development velocity acceleration potential to 100,000x over linear development.
Thus, designing a new civilization from scratch with 10,000 people should be a piece of cake in an open source project.
