Exposing unforeseen consequences of software change

Changing source code can have unintended effects on a program's behavior. Seemingly trivial changes have incurred significant cost, distress, and catastrophe: that is, the concern about the consequences of a change is not merely theoretical. At the same time, many -- perhaps most -- software changes do not cause problems in practice, instead improving the program's behavior in intended ways. The changes that improve program behavior clearly collectively outweigh those that harm it. Nevertheless, nobody would argue that programmers make changes with certainty about the future behavior of a program. This is in part due to Dijkstra's observation from decades ago about the conceptual gap between the static program and the dynamic execution process. This observation led to many aspects of structured programming, most notably the aggressive use of one-in/one-out control structures such as if-then-else statements and while loops. However, for a number of reasons, the source-behavior relationship has become more opaque rather than less so, leaving programmers with relatively little help in distinguishing between changes leading to intended versus unintended behaviors. To aid programmers facing these difficulties, we have developed an approach that takes a pair of program versions, models each version's source code as static call graphs and each version's behavior as dynamic call graphs, partitions these four dependence graphs based on their set intersections, and identifies partitions that tend to expose changes that are likely to have unforeseen consequences on the program's source-behavior relationship. This is joint work with Reid Holmes.