Monday, May 12, 2003

The Lie of Modularity

One of the first things taught to a computer science student is the idea of modularity, that a problem can be cut into smaller problems, and those smaller problems can be cut into yet smaller problems, and so on, until the sub-sub-sub-problems are so incredibly simple that even you! can solve them. Now there are good reasons that software design is taught this way: it makes for easier design, and in theory it makes for less buggy software.

The basic idea was articulated by computer scientists like David Parnas back in the early 1970s. Modularity, also known as separation of concerns, was based on the idea that by separating parts of the programs into separate pieces, the total number of interdependencies would drop. Otherwise, the complexity of programs would be too large to effectively design or debug.

The problem with this idea, however, is that it's basically flawed. The goal -- reducing dependencies -- is reasonably, but it's also an illusion. Those dependencies are there, like it or not, and as software is called upon to accomplish more complicated tasks, it will be easier to see through the illusion.

This illusion was most powerfully revealed to me by a computer scientist named Daniel Dvorak, who works at the NASA Jet Propulsion Laboratory, designing software for spacecraft. When a program running on a deep space probe wants a file, it reads it from a hard drive, pretty much like an earth-bound computer would. However, when that disk drive spins up, not only does that account for a significant amount of the spacecraft's available power, not only does it generate heat and vibration which might interfere with scientific instruments, but it actually imparts a gyroscopic stabilization along the axis of spin! Now all of these side-effects are present on earth as well, we just don't need to worry about them because our available resources -- electricity, cooling fans, the entire mass of the earth -- so overwhelmingly swamp the size of the side effect.

But as we build more complex software, responsible for handling larger and more significant tasks, we are becoming more like that spacecraft: the side effects of running our software will spill over into other modules. The object-oriented programming pillar of "encapsulation," the principle that state can be isolated and owned by a single object, will no longer accurately model the behavior of complex systems.

Fortunately, there's a set of technologies that are solving at least part of this problem, and I'll talk about them later in this series.