2.3 Opportunistic Programming

Different strategies exist to develop a program. A top-down development strategy starts with decomposing the programming task into subtasks, choosing program plans to achieve those subtasks, and then fleshing out the program plans with reusable software components and program statements. A bottom-up development strategy starts with selecting reusable software components, and then combining them according to the structure of a program plan.

Empirical studies have revealed, however, that most programmers follow neither the top-down nor the bottom-up design strategy. In fact, their programming activities are very opportunistic: They are a mixture of top-down and bottom-up strategies, and which strategy is chosen depends on the knowledge of individual programmers and the particular situation [Curtis et al., 1988,Visser, 1990]. Interim decisions made during the programming process ``often can lead to subsequent decisions at arbitrary points in the [programming] space'' [Hayes-Roth and Hayes-Roth, 1979].

The opportunisticness of programming comes from the difference in each programmer's knowledge of program plans and software components. Simon [Simon, 1996] has pointed out that cognitive activities are determined by the environment in which they take place. The environment includes information present in the workspace as well as information present in the memory of human beings. Information in the workspace, including partially constructed programs, talks back to the problem solvers (programmers) and serves as cues to activate relevant program plans and software components from memory [Schön, 1983]. Due to the difference in programmers' familiarity with program plans and software components, which determines the link strength from cues to the activated knowledge in memory, it is quite natural that the programming process pursued by each programmer is different, and the resulting solutions vary. Taking Figure 2.3 as an example, if the programmer is more familiar with the component swapRanges, he or she may choose the program plan Swap two sets of numbers, and the final implementation will be the one connected with thick dashed lines. Conversely, if he or she is more familiar with the program plan Swap two numbers, he or she may proceed from that program plan and choose the component swapInt.

The lack of knowledge about reusable software components needed to implement a program plan often prevents programmers from considering it. However, if information about relevant reusable components is somehow present in the current workspace, it can expand programmers' solution spaces that are limited by their knowledge. Active component repository systems can complement programmers' insufficient knowledge of reusable components by presenting them with immediately accessible components relevant to the current programming task in the workspace.


Ph.D. Dissertation by Yunwen Ye, April 20, 2001, Department of Computer Science, University of Colorado