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

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.