How do you know when YAGNI?

YAGNI is an acronym that stands for "You Ain't Gonna Need It", a software engineering principle meant to speed up delivery and reduce tech debt by only building software that addresses your current needs. At the same time architecting a simple solution that can't scale also results in technical debt and slow delivery. Finding the "just right" solution is a skill built through experience, research and lessons learned from getting it wrong

At Site Impact, we work with a vendor that takes our audience data and uses it to build display campaigns. Because of how that vendor's own infrastructure works, sending them data came with strict limits: a cap on how much we could send per request, how many requests per hour, and how many per day.

I collected data on our current behavior to answer one question: were we at risk of exceeding the daily limit? I looked at the average and median display campaign audience size, along with the range of display campaign orders placed daily. During our busiest times, we would significantly exceed the daily limit, putting orders at risk of missing their scheduled start date.

To avoid this, I designed a priority queue where audience upload requests would get a priority score based on how large and how urgent the order was. I wrote the formula to derive the score and ran several simulations against historical order data to see how the queue would perform during peak ordering times.

The priority queue was elegant and sound. We moved forward and built it. Months later, we discovered the priority queue was rarely in use.

Taking a retrospective look at what happened: when we first learned about the vendor limits, we evaluated several solutions to keep orders starting on time. One was the priority queue. But after talking to the vendor, we learned that switching the type of data we sent would avoid those limits entirely. Only certain audience types had an alternative format available, so we switched those over and left the rest on the original, limited pipeline.

My calculations and simulations, however, assumed all order audiences would still be going through the limited pipeline. Had I gone back and rerun the simulations and calculations, I would have found that we were no longer in danger of reaching those limits, even during our busiest times. The priority queue that I was so proud of architecting? We weren't going to need it.

Keeping track of the decisions made and going back to revisit them as new context comes in, is part of what keeps you from building things you don't actually need.