In the software industry until the 1980’s, programs were developed on a procedural model. This led to extremely complex, unmaintainable solutions. A change to one part of the program usually required changes throughout the program.
This ‘tight-coupling’ is still pervasive in automotive designs. A change to the suspension requires a change to the chassis, which requires a change to something else, with eventually impacts the design of the entire car.
Today software developers use “information hiding” and object-oriented design patterns to create loosely coupled, highly modular solutions. So you can change for instance the login process without having to modify other parts of your system.
At the X-Prize competition, many of the competitors dropped out. Why? As it became clear that there would be many entrants, the organizers planned to hold a race on city streets to determine the overall winner. This was changed to a coast-to-coast rally, and finally they settled on a race over a very demanding, closed course racetrack. Each acceptance scenario posted very different demands on the suspension. These changes posed huge challenges for teams that could not embrace change rapidly.
The WIKISPEED car is designed as 8 modules, with simple interfaces between the modules. Due to its modular architecture, WIKISPEED was able to switch suspension systems with a minimum of fuss. WIKISPEED has also discovered it can apply related patterns, like inheritance and code reuse, to its advantage.
Embracing change is a core agile value. The ability to adapt rapidly meant WIKISPEED did better in the X-Prize competition than the nearly 100 entrants who dropped out without producing a car.
How do you achieve an object-oriented, modular architecture? The next two principles will help you: