Code Ages Like Milk

A bold ti­tle, no? But it’s true, and it’s some­thing that I (and most other main­tain­ers) have to deal with on a reg­u­lar ba­sis. Failing to ac­count for this re­al­ity can slow down de­vel­op­ment and dis­suade con­trib­u­tors from stick­ing around.

As the chief main­tainer of Harper, one of my main jobs is to act as qual­ity con­trol. I re­ceive a num­ber of PRs each week, both from new con­trib­u­tors and old. Given the di­verse pool of con­trib­u­tors, it makes sense that I re­view a di­verse pool of code of vary­ing lev­els of qual­ity.

When I have my head down on tech­ni­cal and at­ten­tion-in­tense pro­jects, I have less time to re­view code. When I have less time, I need to set pri­or­i­ties. The ques­tion be­comes: Would I rather let code from high-qual­ity, re­li­able sources pile up, or code from sources of un­known qual­ity?

I usu­ally end up re­view­ing the high-qual­ity sources first, since they’ll likely re­quire fewer re­vi­sions. Fewer re­vi­sions means quicker merge means im­prov­ing the user ex­pe­ri­ence faster. Whether or not this is a good de­ci­sion is some­thing I’ve been think­ing about all week.

Code Ages

As code sits stag­nant in a PR, it ages. You might say I’m crazy, that there is no way the code it­self changes as it sits still in an un­merged and un­mod­i­fied PR. I’d say you’re right, ex­cept for one teeny-tiny de­tail: Code only has mean­ing when it sits within a broader con­text. If that broader con­text changes (for ex­am­ple, when other PRs are merged) the mean­ing of the un­mod­i­fied code does too.

Let me put it an­other way. If the patch from a PR re­mains stag­nant, but the code it gets patched onto changes, the ac­tual im­pact of the patch does too. This can cause all sorts of prob­lems, from merge con­flicts to er­ro­neous test fail­ures.

The longer code sits in a PR, the more time it usu­ally ends up tak­ing me to get it merged (when I fi­nally have the time to get to it), just from the merge con­flicts alone. It’s the Lindy ef­fect rear­ing its ugly head once more.

Features Age Too

Not only does code age when left un­touched and un­used, so do the fea­tures they rep­re­sent. If a user re­quests for a but­ton that marks some text as bold and they don’t re­ceive that fea­ture promptly, they’ll find an al­ter­na­tive so­lu­tion, pos­si­bly from a com­peti­tor.

The rest of the app can evolve too. If you’re an in­di­vid­ual con­trib­u­tor, it’s in your best in­ter­est for your code to make it to mas­ter. If that does­n’t hap­pen quickly enough, an­other con­trib­u­tor (or, if the soft­ware is ex­ten­si­ble, like Obsidian or WordPress) or plu­gin au­thor might beat you to the punch.

What Can I Do About It?

I be­lieve the way I’ve been han­dling this un­til now has been en­tirely wrong. I should be al­lo­cat­ing more of my time to train­ing new con­trib­u­tors and field­ing PRs from es­tab­lished ones. Open sources is a team ef­fort.

As for you, dear reader, that’s for you to fig­ure out. The worst way code can age is if it stays in your head. Don’t let your ideas go to waste. Open that PR, or re­mind your re­viewer to take an­other look if you haven’t al­ready.