Predicting Function Changes: Mining Revision History to Tackle Software Aging

TL;DR

As software systems grow, developers struggle to identify all the "ripples" a single change creates across a codebase. This paper introduces a hybrid framework that mines 12 years of PostgreSQL revision history to predict function co-changes. By combining Impact Analysis with Repository Mining, the authors provide a recommendation engine that knows which files, functions, or historical patterns are the most reliable predictors for a specific code change.

Background: The "Time Bomb" of Inconsistency

Software maintenance is rarely about changing a single line. It's about ensuring that when Function A changes, Function B (which depends on A) or Function C (which historically always changes with A) is also updated. Failure to do so leads to "time bombs"—bugs that stay hidden until a specific execution path is hit.

The authors argue that as systems age, even "native" developers lose their grasp on these hidden dependencies. Existing solutions often fall into two camps:

1. Impact Analysis (IA): Looking at structural dependencies (who calls whom).
2. Mining Software Repositories (MSR): Looking at historical patterns (who changed together last time).

The Methodology: A Hybrid Heuristic Manager

The core innovation is not just using heuristics, but managing them. The paper defines three primary heuristics:

• History Heuristic: Uses association rule mining to find functions that frequently appear together in atomic commits.
• File Heuristic: Assumes functions in the same file are logically coupled.
• Call-Graph Heuristic: Uses the structural static call tree to predict ripples.

The 3-Stage Workflow

1. Data Pre-processing: Transforming raw CVS logs into "atomic change sets" by grouping commits within a 3-minute window and filtering out "General Maintenance" (e.g., indentation changes).
2. Heuristic Application: Applying BFS/DFS and mining algorithms (like frequent pattern mining) to generate sets of suggested changes.
3. Recommendation: Using a "Heuristic Manager" to rank and present the best suggestions based on F-measures (balancing Precision and Recall).

Figure 1: The proposed model for change propagation and recommendation.

Experiments & Results

The authors conducted an empirical study on the PostgreSQL database (31,000 functions, 12 years of history).

Key Insights:

• History is King: The History heuristic was selected as the best predictor 52% of the time. It proved more stable than structural analysis as the project evolved.
• File Coupling is Strong but Noisy: While the File heuristic had the highest recall (often above 0.80), it frequently suggested too many irrelevant entities within the same file, leading to lower utility for developers.
• Call-Graph Limitations: Surprisingly, the Call-Graph heuristic performed the worst. As developers become more familiar with a project, they often deviate from strict ownership or create distributed dependencies that static calls don't fully capture.

Table 1: Performance of various heuristics (HIS, CALL, FILE) over the training years.

Critical Analysis

Why does History outperform Call-Graphs?

The results suggest that evolutionary coupling (MSR) captures "logical" dependencies that are invisible to a compiler. For example, two functions might not call each other, but they might both need to be updated whenever the database schema changes. Revision history captures this human-centric logic.

Limitations

• Cold Start: The History heuristic cannot predict changes for newly added functions since no prior history exists.
• Precision vs. Recall: The precision values (around 0.10–0.15) remain low. This means for every 10 suggestions, only 1 is typically correct. While this is "SOTA" for the era, it still places a significant cognitive load on the developer to filter results.

Conclusion

This work highlights that software is as much a social/historical artifact as it is a technical one. By mining the "wisdom of the past" (revision history), tools can provide much better guidance than by looking at code structure alone. For modern DevOps, this reinforces the value of clean, atomic commit histories—they aren't just for rollbacks; they are the training data for the next generation of AI-assisted coding tools.