Contract-First Design

From Open Source Ecology
(Redirected from Contract First Design)
Jump to: navigation, search

About

http://www.scrum-breakfast.com/2013/06/xm-principle-4-contract-first-design.html

This means design the interface between modules first - not the modules themselves.

When designing a solution:

  • Design the interfaces based on outside parameters, e.g. load factors, or communication and power requirements.
  • Only architect the connections up front, not the individual components.
  • Leave room to grow, i.e. over engineer these interfaces, because changing these fundamental contracts may be expensive.

Challenge of Contract-First Design

Challenge: emergence. Some interfaces may not be recognized. That is, it may not be recognized that a specific interface exists or is needed. Thus, interface design may be an iterative process within the design process.

Indeed, at the limit of specificity of interface design - the actual design emerges. When an interface is designed in practice, the result is a 'complete design.' If we start with the 'complete design' - then interfaces can be extracted, and documented.

Thus, the interface design and design-proper design processes can be highly iterative.

An interface design may be considered generative in the sense that it is a definition of a boundary, and many such instances can exist in an overall design. Thus, knowing one interface design can result in significant amount of design-proper (actual overall design of the artifact in question) being generated.

The design-proper is generative in the sense that replicable interfaces can be extracted. These interfaces are thus generative. In this sense, the design-proper may be considered generative.

Which is more generative, the interface design or the actual design? If the interface design is correct and verified, then clearly the interface design may be more generative. However, if the interface design is improper, then design errors propage throughout, and the interface design can be de-generative and not useful - calling for rework.

This calls for ongoing, iterative cycling between interface design and design-proper. This is naturally part of Iterative Design aka Test-Driven Design.

Links

More