Thread by @evolvable

Had a prod incident today. CPU riding at 100% in a typically sleepy webapp. Eventually tracked down the recent changes and the "offending" code that we think is causing the issue. Had the programmer done something stupid? Unlikely, she was one of our very best. But...

This code we found. It was iterating through two lists using a nested for, and that has a cartesian product computational cost: O(MN). This week, M and N had each jumped 4-6x, so the function suddenly had ~30x the cost of last week. Do I think this was bad code? No, I don't. Why?

The code was written in 2012... 7 years ago. At the time it was written, the two lists would have been about 20 items each, and the plan - the business plan - was that they would grow slowly, maybe a handful of new items being added each year.

But the plan changed. The lists that were meant to grow by a few each year grew by tens each year, and then more. This year, lists which we were told in 2012 would contain ~50 items by now had thousands, and just jumped to tens of thousands.

The code is easily fixed: chuck all the contents of one list into a map, then iterate through the other list once to find matches from the map. Simples.

Why didn't the original developer do it that way? Because even that was too complex for the original requirements. A nested for loop was the simplest thing that could possibly work, and there was no reason to believe it would cause a problem.

Hell, the code lasted 7 years of unpredicted growth before it did cause a problem. Who would have guessed the code would even exist in 7 years? (I know most devs wish this webapp were no longer around! 😝)

No one would have predicted 7 years ago that these lists would grow to 10s of 1000s. (It still doesn't make complete sense that they have.) Writing more complex code to handle an unreasonable future possibility would have been a waste of time.

Well, maybe in this one function it would have saved time. But betting on an apocalyptic future in every line of code - which is what you'd have to do, because you don't know which assumptions will break in the future - that is the path to immense developer productivity waste.

So I applaud the simple code. The code that was based on a reasonable assumption, and continued working for years after that assumption was broken before it complained. And I applaud the developer that was mature enough to just write an O(MN) function cause it worked. It's #agile

There's another takeaway here: The next time you get impacted by some legacy code, don't think to yourself "What were they thinking?!" but instead "What were their assumptions way back then?" It's a good way to instil empathy for those that came before you.

<plug>
If you want to hear more great stories from the Aussie Tech scene, follow @TechDownunder and switch on notifications to hear about my new podcast.
</plug>