Observations

In the case study, we observed that both concept location and change propagation are an overhead of the change, and the overhead is the same whether the change is large or small. For example, if we introduced just credit card payments in an incremental change without also dealing with payments by check, the same concept location and change propagation would have to be done to implement that smaller change. Small changes lead to the repetition of the overhead tasks and result in decreased efficiency and increased likelihood of errors.

On the other hand, changes that are too big and deal with too many issues at once may overload the cognitive capabilities of the programmers and again lead to increasing the likelihood of error. Thus, there is an optimal size of the incremental change. In this case study, all the incremental changes introduced one to five new classes into the program, examined three to seven old classes, and modified up to four of them.

As we stated earlier, change propagation is a process that requires a check of all the neighbors of a changed class. To miss a change propagation means to introduce a subtle error into the code that will be hard to find later [Yu+2001]. Therefore, in our case study, we chose to be cautious and inspect more classes than absolutely necessary. However, there is a practical limit to how far to carry out change propagation; otherwise, every class of the program would be checked for every incremental change. In our case study, we used the following criterion: We inspected all classes that are direct neighbors of changed classes. Also, we inspected all classes that participate in a data flow with a changed class and checked whether the meaning of the data changed. If so, we made the appropriate changes. If not, we no longer propagated the change. This criterion worked well in all instances in our case study.