The geometric model of maintenance

James Shore proposes that each person-month dedicated to writing code leads to 10 days of maintenance in the first year, then 5 days annually thereafter. Although this threshold-based model may seem oversimplified, its simplicity is intriguing if proven accurate. The argument surrounding robot-generated code does not hinge on specific numbers, so Shore's figures are derived from a hypothetical aggregation rather than concrete data.

However, hypotheticals are not necessary here, as we have git, a tool that allows us to categorize each commit as either "new development" or "maintenance." Assuming that necessary maintenance has been performed, we can count the number of commits of each type per month. This article presumes that maintenance deemed necessary is indeed performed, as users continue to engage with the software even when issues persist.

To measure effort, we count gross commit size, which includes additions and deletions. Plotting the cumulative effort into the development of tmux reveals that only about a third of the total 660,000 lines of effort was spent on maintenance, although this proportion has varied over time. We observe four distinct regimes in the project's history.

The threshold model predicts a continuous increase in maintenance fraction, represented by the dotted red line. While the model correctly predicts the maintenance fraction for the tmux project from 2008 to 2022, it fails to account for the project's actual maintenance demands, which remain lower than predicted. Other projects, such as nginx, Rust, VSCode, and Go, also demonstrate overestimation of maintenance requirements by the threshold model.

Conversely, Neovim underestimates the required maintenance, with 83% of its work being maintenance, compared to the model's 70%. The threshold model's flaw lies in its assumption of constant new feature development, which does not align with the observed constant level of new development in many projects. Instead, maintenance grows exponentially without following the actual maintenance curve.

This issue is exemplified by Syncthing, where the model predicts maintenance correctly but fails to follow the actual maintenance curve. Shore suggests refining the model by acknowledging that new features should slow down as maintenance takes over, but this adjustment may still not fully address the model's shortcomings.