Despite the many approaches to DR suggested and the many software systems devised, DR has not found ongoing use in real-world design. There are cases where DR has been applied successfully; but these often depend on special circumstances, such as the presence of a “DR champion” , that cannot be expected to exist in the majority of cases.
There are a number of ways in which DR methods can fail to be used in practice. One is the use for eliciting and recording rationale from designers, which is generally known as capturing DR. The other way is for retrieval and display of recorded rationale, what we shall call providing access to DR. We will focus here on the former, because it has been the central obstacle to the practical applications of DR. In fact, so little DR has been captured to date that has been relatively little opportunity to investigate the problem of DR access in real-world settings.
The Capture Problem
There seems to be a broad consensus that DR capture has generally not worked in practice. Designers have typically resisted rationale capture. Why they resist is a central question in research on DR capture and one of the most important issues in the DR field. If we were certain of how to answer this question, we would know the conditions, if any, under what the capture problem is solvable and how to begin solving it.
There are a number of possible explanations for resistance to DR capture. Some researchers point to its intrusiveness as the problem. One kind of intrusiveness is due to the work required for capture. Most capture involves designers writing up their rationale in a given DR schema. This requires a great deal of work in addition to the normal work of design.
Other reasons for resistance to capture can include political and legal factors. Designers might not want their bosses or the public to know the real reasons for their decisions. They might also want to protect themselves from potential law suits. There is also the problem that any argument can be a double-edged sword that provides others with a way to attack decisions made.
For descriptive approaches, the extra work of DR capture can be a fundamental problem. Since such approaches do not aid design, those who record the rationale are unlikely to be the ones who use it. Designers might thus have little motivation to do the capture. Descriptive approaches run afoul of Grudin’s principle that collaborative systems tend to fail when those who do the work are not the beneficiaries of that work [24, 25].
Grudin argues that in developing commercial off-the-shelf (COTS) software DR capture might not pay off at all for later phases. COTS projects are failure prone, because (1) most products fail commercially and (2) up to 90% of projects are not completed. Failed projects do not need DR, and using resources for its capture could make failure more likely.
Grudin also suggests that in COTS development design decision making is often highly distributed. Experts and stakeholders of many types shape the design. There is often no way of compelling these individuals to share their rationale, much less to use a DR software system.