Simplicity Versus Contracts


The central coding practice of Design by Contract is the addition of contracts expressed through preconditions, postconditions, and invariants to classes and methods. On the other hand, two of the most important coding practices in XP are "Do the simplest thing" and "You ain't gonna need it." The crucial question when discussing Design by Contract from an XP perspective is, "Why would you want to add the complexity of contracts to your system?"

In XP, only user stories can justify raising the complexity of a system. So the question can be restated as, "What user stories require the addition of contracts to a system?" In many software projects, two such stories could be the following.

  • User story 1: We have several teams working on different subsystems, and we want to protect their interfaces against mistakes and misinterpretations. Also, our corporate quality assurance strategy requires such protection.

  • User story 2: We want to automatically generate some documentation on the semantics of the interfaces of each subsystem for example, for use by other teams and projects.

A brief explanation of why the two are reasonable and how they connect XP and Design by Contract is given in the following section.

Subsystems in XP

XP is usually viewed as applicable only in small teams of up to ten or 12 developers. Although this is not a definitive upper limit, most people regard it as a practical rule of thumb for the team size. A team of 20 developers is regarded as too large for effectively applying XP. In his well-known work The Mythical Man-Month, Fred Brooks says, "Adding more men … lengthens, not shortens, the schedule" [Brooks1995]. This is viewed as justification for XP's call for small teams. But in the same book, Brooks also mentions, "This then is the problem with the small, sharp team concept: It is too slow for really big systems." Quite often, systems are just too big to be developed in time by a single XP team.

One possible solution is to partition a large set of requirements into subsystems that interact only through well-understood interfaces. This may seem hard to do, but in practice a lot of business domains do have such interfaces. They are either company or industry standards, required by existing architectures, or they are imposed by third-party software, such as SAP. The interface between payroll and financial accounting is an example, as are industry standards such as SWIFT for interbank messaging, or separate front-office and back-office systems. Whenever such interfaces exist, they can be used to partition a system into subsystems.

In environments like that, the stories like user story 1 (described earlier) can be satisfied by introducing Design by Contract. According to our understanding, contracts are most beneficial to XP projects when used for interfaces between subsystems. Through preconditions and class invariants, they force calling subsystems to provide the required environment to use an interface. At the same time, the calling subsystem can rely on the interface semantics that are enforced by the callee's postconditions (and class invariants).

System Documentation

Besides runtime enforcing contracts and error notification, contracts also serve well as semantic subsystem interface documentation. They explicitly state the expected context in which an interface can do useful work. Additionally, they even specify the results that can be expected, to a certain extent.

Documentation like that when done manually is notoriously incomplete and outdated. Besides, qualified team members usually are needed to produce it, and as part of the workforce, they are often indispensable. In contrast, contracts can be picked up by using suitable tools, and up-to-date documentation can be created anytime it is needed for example, to satisfy corporate quality assurance policies (see user story 2).

Thus, contracts make code even more self-documenting, a goal that is clearly expressed in the XP core practice "The source code is the design." Meyer also mentions this aspect of contracts, for example, in [Meyer1997].



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net