![\"induced-maintenance-demand-01.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-01.svg\")
James Shore posits that each person-month spent writing code results in 10 days\nof maintenance in the first year, then 5 days every year after that. Naïvely\ninterpreted, this is a threshold-based model for induced maintenance, and its\ninteresting because it’s so simple.
\nIf it could be shown to be true, that’d be useful. The argument Shore is\nmaking about the effects of robot-generated code does not depend on the specific\nnumbers, so Shore’s numbers come from a hypothetical wisdom-of-the-crowds\naggregation rather than concrete data. But no hypotheticals are necessary here.\nWe have a thing called git.
\nLet’s say we have a way of labeling each commit as either “new development” or\n“maintenance”. Then we can count how many commits of each type there are in a\nmonth.[1] Possibly better, we can count how much\ncomplexity has been handled in a month.[2]
\nThe following plot shows the cumulative effort that has gone into the\ndevelopment of tmux since its beginning to the day I start writing this article.
\nWe will look first at the black curve, which represents effort spent adding\nfeatures to tmux. From left to right:
\nIn the first month of the repository, a few thousand lines of feature work are
present almost from the start.
From the start in 2008 to 2010, tmux saw rather intense activity at
around 30,000 lines of new development effort per year.
Then new development slowed down, and between 2010 and 2026, it happened at a
fairly steady pace of 8,000 lines of effort per year.
As of today, tmux stands at just over 230,000 lines of effort of new
development that have happened throughout its history.
To see how much effort has been spent on maintenance, we perform the same\nexercise but with the red curve instead.
\nMaintenance started dipping behind new development early on, but then traced
fairly closely to new development between 2008 and 2014.
After that, maintenance took off at a rate of 30,000 lines of effort per year,
continuing at that pace until 2022.
In other words, of the total roughly 660,000 lines of effort spent on tmux, only\nabout a third has been on new development. This has changed over time, and we\ncan find roughly four regimes in the project’s history.
\n2010–2014: Total effort is 16,000 lines per year. About 50 % of that is
maintenance.
2014–2022: Total effort is 38,000 lines per year. About 80 % of that is
maintenance.
2022–2026: Total effort is 18,000 lines per year. About 55 % of that is
maintenance.
This is not quite the continuous increase of maintenance fraction predicted by\nthe threshold model. To be sure, we should also check visually. The prediction\nof the threshold model is represented by the dotted red line.[3]
\n![\"induced-maintenance-demand-02.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-02.svg\")
All the way from 2008 to 2022, the simple threshold model does actually fairly\nclosely predict the amount of maintenance tmux has required. But the exponential\nnature of the threshold model means its prediction eventually goes up faster\nthan actual maintenance performed.[4] This means the model fit will likely worsen as time goes on.
\nThe threshold model is also not a great fit for some other projects, where it\ngenerally overestimates the amount of maintenance performed. As one example,\nmaintenance work has made up 63 % of the effort spent on nginx to date, but the\nthreshold model suggests it should be 81 %. Other projects where the model\noverestimates the maintenance requirements are Rust, VSCode, and Go.
\nIn contrast, the model underestimates the amount of maintenance required for\nNeovim. The Neovim project has been maintenance-heavy from the start, and\nthrough its history, 83 % of the work on Neovim has been maintenance, but the\nthreshold model suggests it should be 70 %.
\nHowever, the more general problem with the threshold model is one of timing. This is\nbest illustrated with Syncthing.
\n![\"induced-maintenance-demand-03.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-03.svg\")
The threshold model lands close to the correct lifetime maintenance fraction\nhere (70 % vs. the real 67 %) but it is nowhere near following the actual maintenance\ncurve.
\nAn apologist could argue that the lack of curve-following is not because the\nmodel is wrong, but because the Syncthing project is an outlier that decided to\nfront-load a bunch of maintenance. Unfortunately, Syncthing isn’t the only\nproject where this happens, and it’s actually a symptom of the big flaw of the\nthreshold model. Given a constant level of new feature development, it predicts\nmaintenance will grow exponentially.[5] That doesn’t seem to be what happens in practise in the\nprojects I’ve looked at.
\nBut maybe we can rescue the model by refining it. The original threshold model\nsays that the 100 lines of effort I spend on new development today contributes\nat least 5 lines of maintenance effort per year until infinity. That’s probably\nnot true, in part because old code tends to be more stable, but also because\ncode is gradually rewritten, so the 100 lines I made today might not even be\naround five years from now.
\nWe can tweak the threshold model to account for this, by adopting a geometric\ndecay on the maintenance induced by new development. If we pick numbers\nconsistent with what Shore proposed, we’d say that maintenance starts at 5 % of\nthe work performed[6], and decays\nwith 3.6 % per month.[7] However, these numbers\nwould yield results very similar to what we’ve already seen: the maintenance\ncurve doesn’t track actual maintenance performed.
\nHowever, we can pick other numbers. For example, if maintenance starts at 4 % of\nthe work performed, and decays with 2.6 % per month, we get a maintenance curve\nthat tracks fairly closely to the new development curve. This happens to work\nwell for nginx, which is light on maintenance:
\n![\"induced-maintenance-demand-04.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-04.svg\")
For a project that needs more maintenance, like tmux, the same numbers don’t\nwork. They produce a curve that underestimates the maintenance required.
\n![\"induced-maintenance-demand-05.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-05.svg\")
We can ask our computer to pick out the numbers that produce the\noptimally-fitting modified geometric curve for tmux. This happens at the same 4 %\ninitial value, but decaying with 1.4 % instead of 2.6 %. Here it is,\ngraphically:
\n![\"induced-maintenance-demand-06.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-06.svg\")
If we continue to do this for all projects we have data for, we get a set of\nnumbers with large variation.
\n| Project | Up-front maintenance | Decay |
|---|---|---|
| nginx | 4 % | 2.6 % |
| tmux | 4 % | 1.4 % |
| Neovim | 20 % | 3.8 % |
| Syncthing | 29 % | 14 % |
| React Native | 7 % | 3.2 % |
| Go | 3 % | 0.7 % |
| VSCode | 48 % | 19 % |
| Rust | 12 % | 3.6 % |
These numbers are not intended to tell us anything causal about how maintenance\ncomes to be. Rather, they’re the just-so numbers we are forced to pick to make\nthe geometric curve follow the actual maintenance performed closely, for each project.
\nWe can take these numbers and extend the maintenance curve ten years into the\nfuture, and predict how much maintenance will be needed in these projects even\nif they completely stop all new development. Here’s nginx.
\n![\"induced-maintenance-demand-07.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-07.svg\")
The curve illustrates that nginx is already fairly close to their current\nmaintenance saturation point, and rather little maintenance remains if they\nfreeze all new development now. We can contrast this with something like tmux,\nwhich, when extended a decade forward, has a long way to go until their\nmaintenance curve plateaus.
\n![\"induced-maintenance-demand-08.svg\"](\"https://entropicthoughts.com/image/induced-maintenance-demand-08.svg\")
Although it’s neat to be able to reproduce maintenance curves for projects, we\nshouldn’t really project these curves into the future because that gives viewers\nthe idea that the curves are predictive, when in reality they should be thought\nof as descriptive. But! These plots indicate that maybe there’s a more\nhuman-friendly way to present the numbers, that say something more intuitive\nabout the projects.
\nHere’s one way to interpret the numbers of the geometric model. With a\ngeometrically decaying series, the sum of all numbers is computed by dividing\nthe starting value by the decay factor. The sum, in this case, represents the\ntotal amount of maintenance performed relative to the new development effort.
\n| Project | Total maintenance |
|---|---|
| nginx | 1.5× |
| Syncthing | 2.0× |
| React Native | 2.1× |
| VSCode | 2.5× |
| tmux | 2.6× |
| Rust | 3.2× |
| Go | 4.3× |
| Neovim | 5.3× |
This is so interesting. According to the geometric model, each hour of\nnew development on nginx produces 1.5 more hours of maintenance work over the\nlifetime of the project. That is the lowest figure of these projects. It could\nmean that
\nThe nginx developers only accept high-quality code, since it needs so little
maintenance going forward, or
nginx runs in fairly predictable environments where few assumptions can be
incorrect, and thus few assumptions need to be revised.
The opposite on this spectrum might be something like Neovim, where each hour of\nnew development produces over five hours of maintenance over the lifetime of the\nproject. Neovim likely needs to adapt to a varied set of environments and\nworkflows, where all sorts of edge cases show up.
\nIsn’t this such a useful rule of thumb already? Now the developers of e.g.\ntmux know that for every hour of new development they plan, they’ll have to\nbudget around 2.6 hours of maintenance. You can do this for your own\nprojects! Even if you haven’t fitted the curve to your project’s history (or you\ndon’t have a project history to fit to), it seems that 3 hours is somewhere in\nthe middle of the range, so you can assume three hours of maintenance per hour\nof new development.
\nBut when should you plan to do that maintenance? That’s another thing we can\nquery of the geometric model.
\n| Project | Elimination time |
|---|---|
| Syncthing | 2 years |
| VSCode | 2 years |
| nginx | 4 years |
| React Native | 5 years |
| Rust | 6 years |
| Neovim | 7 years |
| tmux | 8 years |
| Go | 13 years |
The amount of maintenance needed from new development shrinks over time, as bugs\nin the code are ironed out. The elimination time in this table is the amount\nof time it takes until a hundred lines of new development effort need less than\none line of maintenance work per month.
\nWe can tell that some projects get through their maintenance fairly quickly\n(Syncthing, VSCode), but for others it takes longer to find the bugs and sort\nthem out (tmux, Go). The average is six years.
\nThis completes the planning guideline: if we start up a new project, for each\nhour of new development we plan, we should budget for three hours of maintenance\nspread out over six years, geometrically decaying. Here’s a handy table.
\n| New development planned: | 1 day | 1 week | 1 month |
|---|---|---|---|
| Maintenance same year | 10 hours | 6 days | 26 days |
| " year 2 | 7 hours | 4 days | 18 days |
| " year 3 | 5 hours | 3 days | 13 days |
| " year 4 | 3 hours | 2 days | 9 days |
| " year 5 | 2 hours | 1 day | 6 days |
| " year 6 | 2 hours | 1 day | 4 days |
I’m actually surprised that in this average case, just the maintenance induced\nin the same year as the original new development exceeds the new development\ntime. Thus a one-week project is not a one-week project, it’s a two-week project\neven when it includes only maintenance performed in the same year. (It’s a\nfour-week project when considering all maintenance borne out of it.)
\nWhile yes, I believe that table is better than nothing – and possibly better\nthan what many are doing today – the geometric model is not realistic. For\nexample, it says that one day of new development has the same elimination time\nas a month of new development. It also does not account for the size of the\nexisting code; I would think adding more features to an already-big code base\nshould produce more maintenance than adding features to a small code base.
\nAnother thing that bugs me about the geometric model is that the amount of\ntotal maintenance produced by a unit of new development varies greatly across\nprojects, as does the elimination time. In order to use the geometric model\nfor planning, we should really fit those values for each project specifically,\nrather than use these rough averages. These averages happen to work great for\nprojects like Rust, VSCode. They are pessimistic for projects like Go,\nSyncthing, tmux, and nginx. And they still underestimate the maintenance\nrequired for a project like Neovim.
\nI don’t think we’ll ever get a model of induced maintenance that is completely\nfree of estimation – some projects simply need more maintenance than others –\nbut perhaps we can get an slightly better fit? Perhaps we can find a model where\nsome parameters are stable across projects and don’t need re-estimation? That\nwould tell us something deeper about how software development works.
\nI have some ideas for how to go about this, but that’ll be another day.
\nI am grateful to James Shore for reviewing a draft of this article. He had very\ninsightful suggestions for improvements. In particular, some of the detailed\nsidenotes clarifying the methodology are entirely to his credit. As always,\nmistakes are my own.
\nHe also noted that my presentation of his application of the threshold model was\nbased on a flawed reading of the spreadsheet. To clarify, I must emphasise that\nthe primitive application of the model we use here – where all new development\nadds an absolute level of maintenance – is not the model Shore presented, nor\nthe way he used it in his article.
\nThe way Shore uses the model, he lets past new development drive both\nmaintenance and hypothetical new development, and we cannot do that, because we\nalready have the actual new development that happened. I would argue the\napplication in this article makes for a better test of general fit and validity,\nbut it says very little about the way Shore applies the model, which is in\ncompletely different circumstances.
\nI strongly recommend reading his article series, and digging into the details of\nthe spreadsheet, if you’re curious about that.
\nThis article will assume that necessary maintenance gets performed,
and if maintenance is not performed, that’s because it wasn’t strictly\n necessary from the aggregate users’ points of view. I know a lot of people\n would object to that assumption because maintenance they think of as necessary\n is not performed, but try to suspend your disbelief. If you keep using the\n software even when that thing is not getting fixed, how necessary is that thing\n really to keep you around as a user?
In this analysis, I am counting the
gross commit size, i.e. additions plus deletions, as the amount of effort that\n went into the commit. One can argue that this is a bad measurement of effort,\n but it’s the best I have, and in my experience, on longer timescales like the\n ones we look at here, it’s not so bad.
Note that we
are not using the threshold model to predict the fraction of maintenance here,\n but instead applying it primitively for what it says about the absolute size\n of the maintenance demand. In Shore’s original application, he was able to\n predict the fraction of maintenance through the threshold model, because the\n model was allowed to also determine the rate of new development (through a fixed\n monthly work rate.). We don’t do that, because we have the real new development\n rate of the tmux project. It wouldn’t make sense to impose on the data an\n assumed new development rate that we already know isn’t true.
If new development had been reduced to
make room for the maintenance work, as Shore argues is the case for many\n corporate projects, then maintenance would have leveled off as new development\n grinds to a halt. But clearly, in the tmux case, new development does not reduce\n that much to make room for maintenance work. And the same is true for all\n projects I surveyed, including corporate-backed ones whose primary contributers\n are on a payroll.
Shore would argue that we cannot base
our judgment on a constant level of new feature development because new features\n should slow down as maintenance takes over the total work effort. But in the\n projects I’ve looked at, new development seems to happen at a relatively\n constant level.
The reason the geometric model starts at 5 % rather than
the 0.8/21.7=3.8 % the threshold model has is because the decay starts happening\n immediately, and proceeds monthly through the first year. Thus, the total\n maintenance the first year will still be 10 days in this geometric model. (Or\n nearly so, 11 days is what you get with these rounded numbers.)
That means after one year, the maintenance required
for 100 lines of work is shrunk to 3 lines of effort per month. After five\n years, it’s down to half a line of effort per month. After ten years, it’s\n barely noticeable, at a twentieth of a line per month.