, 12 tweets, 3 min read Read on Twitter
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.
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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Graham Lea
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!