This isn't specific to software. This works for pretty much anything large and complex (i.e. electronics).
First, there are two milestones of complexity.
- Size - Designing an item which cannot be designed by a single individual.
- Knowledge - Designing an item which cannot be understood by a single individual.
The first often shows up in typical "business app" developments. The second, however, is much more rare (in my experience). I would guess it's typically exemplified by large code bases (greater than 500 KLOC) or complex problem domains (military and scientific domains, some finance, etc).
Regardless of whether we are talking about software or some other complex artifact, there is one shared economic factor. Given either milestone, there becomes a need for a coordination mechanism among the designers.
The economics of designing a complex artifact are directly tied to the efficiency of the coordination mechanism of its designers.
If you want to reduce the cost of producing complex artifacts (i.e. software), you have to focus not only on raising the productivity of the individual designer but also on the efficiency of coordinating those designers.
In small development teams, this comes mostly in the form of communication. Better and more frequent communication typically provides better coordination among designers (developers).
You see this embodied in many of the practices of a highly efficient development team: the team room, the information radiator, kickoff meetings, retrospectives, and customer demos (to name a few).
When remote developers are in play (i.e. offshoring), the economics and coordination mechanism change (unless the entire team, including stakeholders, is offshore).
When multiple teams of developers are in play for a single artifact, this also changes the coordination mechanism. A good architect will know that based on the communication obstacle associated with having multiple teams, each team will work better if loosely coupled from the others. This means employing a loosely coupled design boundary between the design artifacts owned by each team.
That's an odd thought the first time it comes across. The communication structure of the designers should be embodied in the design of the artifact. But after a while, it quickly appears to be common sense. This could actually be phrased more as a law than a principle, because the communication paths of the designers will be reflected in the work they produce. Either account for it in the architecture, or let it show through later (in the form of bugs and issues).
Another interesting area to explore in software is readability. In codebases and teams steeped in Domain-Driven Design, for example. The code itself becomes a communication mechanism. This is where qualities such as readability and comprehensibility are both prioritized.
posted @ Sunday, October 05, 2008 6:26 PM