The geometric model of maintenance

Software engineer kqr tested James Shore's claim that a month of new code costs ten days of maintenance in its first year and five days every year after, fitting a geometric decay model to eight open-source project histories from tmux to VSCode and deriving a planning rule of three hours of maintenance per hour of new development spread over six years. The labels came from a bag-of-words classifier on commit messages with an LLM fallback, sampled rather than exhaustive, so the resulting ratios — nginx at 1.5 maintenance hours per development hour and Neovim at 5.3 — cannot distinguish quality problems from environmental drift. kqr argues the ratio only becomes diagnostic once maintenance is decomposed into bug fixes, environment drift, and misclassified rewrites.

kqr at Entropic Thoughts https://entropicthoughts.com/ read James Shore's claim that a month of new code costs ten days of maintenance in its first year and five every year after https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs , and did something rare: checked it against git https://entropicthoughts.com/geometric-model-of-maintenance . He took eight open-source histories, tmux to VSCode, each commit labeled new development or maintenance and weighted by diff size. Shore's threshold model fit the lifetime totals reasonably and the timing badly, so kqr replaced it with a geometric decay fitted per project and got a planning rule out of it. Three hours of maintenance for every hour of new development, spread over six years, with the first year alone costing more than the original work. A one-week project is a two-week project before the year is out. The method is reproducible, and it passes the smell test - it looks right . But it's also worth knowing what the number is made of, because kqr documents it in a companion piece https://entropicthoughts.com/cheaper-llm-labeling and not in the one that draws the conclusions. The labels come from commit messages, not code: a bag-of-words classifier on the message text, with an LLM behind it for the cases the fast path isn't sure about. The commits are sampled , not exhaustive. The label is binary, and the maintenance half bundles bug fixes with performance work, security hardening, observability, and removed features. Validation was the author checking a small set by hand. The author's up front about it, and it's not an unreasonable attempt. It does mean the measurement is "what committers said they were doing, weighted by how much they touched," and that the word "maintenance" in the result covers at least four things with different causes. That affects how you read the ratio: it's not a verdict. kqr lands on nginx at 1.5 hours of maintenance per hour of development and Neovim at 5.3, and offers two readings of each without choosing: nginx either accepts only high-quality code or lives in a predictable environment; Neovim either carries more defects or has to meet every workflow there is. Those are opposite diagnoses with opposite remedies, and the model produces the same number for both. A project with many callers at its boundary absorbs more change than a project with few, and nothing in a binary label distinguishes that from sloppiness. So the planning rule is usable, and better than the nothing most teams budget. The ratio only becomes diagnostic once it's decomposed. Bugs in new code should decay the way kqr fits them. Drift in the environment should track the world, not the project's own history. Rewrites should show up as new development the classifier called maintenance. Three curves, three shapes, and the one that dominates your repo is the number that says something about quality and intent. That's the next piece, and kqr says he has ideas for it. This one answered how much. It can't yet answer of what. And the most important thing in all of it is that it highlights something that developers can consider measuring for themselves; you don't have to use his methodology, because you can determine what's being done as maintenance, and which kind, against what's being done as a new feature, and you can use that to allocate effort on your own codebase. If the maintenance costs you three times what a new feature does, what does that mean for you ?