The effects of time pressure on quality in software development: an agency model.

Publication: Information Systems Research

Publication Date: 01-JUN-01

Bookmark this article Print this article Link to this article Email this article Digg It! Add to del.icio.us RSS

COPYRIGHT 2001 Institute for Operations Research and the Management Sciences

An agency framework is used to model the behavior of software developers as they weigh concerns about product quality against concerns about missing individual task deadlines. Developers who care about quality but fear the career impact of missed deadlines may take "shortcuts." Managers sometimes attempt to reduce this risk via their deadline-setting policies; a common method involves adding slack to best estimates when setting deadlines to partially alleviate the time pressures believed to encourage shortcut-taking. This paper derives a formal relationship between deadline-setting policies and software product quality. It shows that: (1) adding slack does not always preserve quality, thus, systematically adding slack is an incomplete policy for minimizing costs; (2) costs can be minimized by adopting policies that permit estimates of completion dates and deadlines that are different and; (3) contrary to casual intuition, shortcut-taking can be eliminated by setting deadlines aggressively, thereby maintaining or even increasing the time pressures under which developers work.

(Agency Theory; Principal-Agent; Software Quality; Software Measurement; Software Estimating)

1. Introduction

Time pressures induced by development schedule constraints are an often-cited source of quality problems in technological systems (DeMarco 1982, 1995; PateCornell 1990; Staw 1982; Brooks 1975). Problems arise when developers, feeling that they are under pressure to meet task deadlines, take shortcuts in dealing with unanticipated complications. "Shortcuts" are decisions made in private that are motivated by a desire to stay on schedule, but are not in the best interests of the project. At the time such a decision is made, it may not be certain that adverse consequences will ensue, and it is unlikely that the possible consequences are fully known to the developer. What is crucial is that a developer who is concerned about quality would have made a different private choice if perceived time pressures were somehow alleviated. Shortcuts are not necessarily due to guile (Brooks 1975), nor are they necessarily the result of a deliberate decision process. Rather, they reflect a developer's tendencies to hope for the best, to leave potential sources of difficulty unexplored, and to interpret requirements conveniently when faced with time pressures.

Developers take shortcuts without fearing personal consequences because it is difficult for nonspecialists to trace complex system problems to causal sources. Such difficulties in software development are well documented (e.g., DeMarco 1995, Iansiti and Gill 1990). They arise from developers' often profound advantage over supervisors in job-related knowledge (Curtis 1984, 1997), from the inherent "incompleteness" of measures for complex activities (Austin 1996, Holmstrom and Milgrom 1991, Blau 1963), and from the particular characteristics (e.g., intangibility) of software (Brooks 1987).

1.1. How Shortcuts Happen--An Illustrative Example

Developers at a manufacturing company were working toward a deadline for installing software in a plant. The software would be critical to plant operations, so failures would be expensive. Because of the complexity of the overall system (a large client-server application that interacted with many other machines), only the three members of the software development team understood its detailed inner workings. Although complex, the software was not new; it was running successfully in other plants. Most development work was, therefore, oriented toward improvements and correction of discovered problems. Two weeks before the installation date, a new requirement surfaced.

Unlike other plants where the software was already running, this plant had no shutdown period each day. It was usually idle between 4:30 A.M. and 5 A.M., but on some days operations would continue right through until 5 A.M. During peak production times, this could happen several days in a row. The software, however, required 15 minutes of shutdown time each day to perform an automated backup. The backup process was built into the design. There was no option in the standard application for postponing a backup.

To address the new requirement the three-person development team considered options ranging from a simple on/off switch for the backup process, to more elaborate designs that reminded operators to turn the backup process back on, or that automatically turned the process back on. The chief concern was that plant computer operators might use the "off" option too often or forget to turn the backup process back on. If backup was postponed for more than a week, the system would fail (a file would expand to fill all available disk space). Failure might well occur at the worst possible time because plant personnel would be most likely to forget about the backup when they were straining to meet peak demand. Thus, the development team agreed that the best solution would be a redesign of the backup process to allow backups during plant operations. However, there was no way to complete and test such a substantial redesign before the deadline for installing the software in the plant.

Despite their concerns, the team chose a simple on/ off switch design. The sole reason for their choice was their reluctance to delay installation plans. A few months after the software was installed, it failed in exactly the way they had anticipated. The resulting unplanned shutdown was much more expensive than a delay in installation would have been. If they had not had time pressures, the development team would have eliminated this problem. In effect, they chose to incur potential, shared consequences (a possible future failure for which blame would be shared with others, e.g., plant personnel who forgot to turn on the backup) rather than immediate, certain, personal consequences (blame for delaying the project).

1.2. Evaluating Policies to Solve the Shortcut Problem

One way managers try to reduce the risk of shortcuts is by making systematic adjustments to estimates in setting deadlines. A common method is adding slack to project schedules at the time that deadlines are set (Tomayko 1987). Project managers often follow deadline-setting guidelines like "take your best estimate and double it" (DeMarco 1997, Yourdon 1997). The underlying rationale is that adding slack provides developers with needed "qoreathing room," allowing them to be more thorough and quality conscious.

This paper uses an agency framework to derive a formal relationship between deadline-setting policies and software product quality; it provides recommendations concerning how deadlines might be set to preserve the quality of software development products. The major findings of this paper are that: (1) adding slack does not always enhance quality, thus, systematically adding slack to alleviate time pressure is, at best, an incomplete strategy for minimizing costs; (2) costs can be minimized by adopting estimating and deadline-setting policies that permit estimates of completion dates and deadlines that are different; and (3) contrary to casual intuition, shortcut-taking can be eliminated by setting deadlines aggressively, thereby maintaining or even increasing the time pressures under which developers work.

Although King and Wilson (1967) suggested separating planning estimates from deadlines, and setting the latter more aggressively than the former, it is not common in modern development environments (DeMarco 1997, Yourdon 1997). DeMarco's (1997) comments state a case for this approach and lament the scarcity of its practice:

I have advocated for years that we ought to conduct projects with both an estimate and a goal. After all, the two words mean quite different things, so that a good estimate is necessarily a bad goal, and a good goal is a bad estimate. It would be perfectly reasonable for a project to adopt a one-year goal, for example, but have everyone...

Read the full article for free courtesy of your local library.