The approach uses an existing task to capture rationale, called the “focus task”. This refers to a selected task or activity that is part of the usual software process – not one inserted for the favor or rationale capturing or rationale management. Many experiences in real projects support the Ra-tionale Paradox: during interesting project phases, even the slightest addi-tional “task” will not be accepted. Therefore, no additional task is inserted.
Section 4.2 mentions different kinds of decisions made during different project activities. Principle 1 requires focusing on one such focus task in which the desired type of rationale is created or discussed. Rationale is said to surface when it is discussed, documented or communicated, either in phone calls, meetings, orr prototype demonstrations.
In the terminology of Chap. 1, the approach is concerned with descriptive rationale, and there is a clear commitment to avoid intrusions during that selected project task. Approaches like ibis [4] impose argumentation structures and extra tasks on project personnel. That is carefully avoided in the By-Product Approach.
Capture Rationale During that Task
It is important to capture rationale where it surfaces. Waiting to capture it later will probably fail: Much will be forgotten, and project pressure will force people to prefer project tasks over rationale management duties.
This principle may seem to contradict the previous one: what is the difference between inserting an extra rationale task (above) and capturing rationale during an existing task?
An important psychological issue is the need to schedule and carry out an additional task in the first case, while in the second case there may only be a small percentage of extra effort during the existing task, with no additional time slot needed. Of course, this principle by itself does not reduce the effort of capture, it just increases acceptance. However, the next principle calls for reduction of this extra effort as the main optimization goal – even at the cost of sophisticated preparation and lengthy follow-up work. Once again, this may not reduce overall effort, but it does reduce effort during the rationale-prone project task.
It has been argued (see Chap. 1) that IBIS captures rationale “on the fly” [13], just capturing the history of rationale as it occurs. While the By-Product Approach is descriptive in that same respect, it puts far more emphasis on low effort.
