A hard problem is specified, in order to make it tractable it is broken down into software components. These components get reified into human and managerial structures in the organisation responsible for building the system.
Overtime these abstraction or managerial boundaries impede the development of new features and ideas. In a user focused organisation, communication between the teams tends to lead. New human connections are formed, followed or coupled with new technical connections. These lead to exciting new user-facing innovations.
More hierarchical, less user-focused, organisations tend to be incapable of supporting the new social dynamics, and so try to enforce their socio-technical boundaries, occasionally with security mechanisms. The only benefit they reap from this, is that rather than incrementally adapting, they are replaced wholesale by a different organisation that views the separation differently.
As such, the oscillation that is typical in large business between horizontal and vertical orientation is reflected directly in the oscillation in software structures as new ideas are negotiated around the abstraction boundaries (see e.g. the oscillation between objects and aspects, or mocking). The lack of such oscillation doesn’t imply that the design was somehow ‘right’ to start with, only that the organisation was too inflexible to adapt to the needs of its users.
The oscillation cycle is both healthy, and endemic across technical aspects of IT systems. See for example:
- The separation between processes in an operating system, first hard, then IPC, then DMA, then Virtual Machine Monitors
- The separation between the ‘compile’ and ‘execute’ phases of a language. Then dynamic class loading and dynamic languages. Then NEX bits.
- The separation of browser from operating system. Then ActiveX. Then Windows Isolation Mode. Then Chrome. Then Native Client....
This isn’t a failure, it’s a design process. The question is, we oscillating enough? How can we oscillate faster?
