Since rationale is so essential for project success, one would expect it to be highly regarded and captured carefully. However, that is seldom the case, as Chap. 1 states in some detail and with reference to the literature. Due to its perplexing nature, I call this observation the “Rationale Paradox”:
The Rationale Paradox:
When most rationale is created, chances to capture it are lowest.
−Rationale is created when key decisions are made.
−During decision-making, participants are very attentive.
−Rationale is considered important and “evident” at the time when it is created. At that time, no one can imagine how it could ever be forgotten.
−Usually, further decisions are based on earlier ones, so there is pressure to continue fast in the project. New decisions overlay old rationale.
−Csikszentmihalyi [5] talks about the flow state in which knowledge and experience come together easily and knowledge workers seem to “flow” through their highly demanding work. During the flow state, knowledge workers are typically not willing to switch tasks and take care of rationale.
−Schön [19] and Fischer [7] discuss how practitioners need to be interrupted in their professional activities in order to become aware of the tacit (internalizedd [ 14]) expertise they currently apply, including experience and rationale. However, interrupting their flow (as in [19]) might endanger motivation and will slow down work. To avoid this, the team tends to focus on “essential constructive tasks” in the project
–while capturing rationale is deferred.
When the project gets into a slower phase, rationale will already be partially forgotten (see above), so there is again little motivation to document it. Most software developers prefer doing what they consider “productive work” like designing or programming over documentation. They will rather make new decisions and continue designing or implementing than capturing rationale. As a consequence, rationale is least likely to be captured when it would be easiest to grab.
