A Developer cannot keep up with a constantly changing base of implementation code.
Context:
A system with mechanisms to document and enforce the software architecture, and developers to write the code.
Forces:
Something that's everybody's responsibility is no one's responsibility.
You want parallelism between developers, so multiple people can be coding concurrently.
Most design knowledge lives in the code; navigating unfamiliar code to explore design issues takes time.
Provisional changes never work.
Not everyone can know everything all the time.
Solution:
Resulting Context:
The architecture and organization will better reflect each other. Related patterns include Architect Also Implements, Organization Follows Market, and Interrupts Unjam Blocking.
The pattern Review the Architecture helps keep Designers and Architects from developing tunnel vision from strict application of this pattern.
Design Rationale:
Lack of code ownership is a major contributor to discovery effort in large-scale software development today. Note that this goes hand-in-hand with architecture: to have ownership, there must be interfaces. This is a form of Conway's-law-in-the-small (see also Architect Also Implements).
Arguments against code ownership have been many, but empirical trends uphold its value. Typical concerns include the tendency toward tunnel vision, the implied risk of having only a single individual who understands a given piece of code in-depth, and breakdown of global knowledge. Other patterns temper these problems (see Review the Architecture, and Engage Customers).
Tim Born argues that there is a relationship between code ownership and encapsulation, in the sense that C++ protection keeps one person from accessing the implementation of another's abstraction.
Law is property, and the lack of identifiable property leads to anarchy (Rousseau et al.).
It has been argued that code ownership should be applied only to reusable code. Such a constraint would be worthy of consideration if someone comes up with a good distinction between usable code and reusable code.
Next: Application Design is Bounded By Test Design
Last updated
Thu Mar 23 09:00:44 CST 1995
Copyright © 1995 AT&T