Research First, Code Second: Building Scoring V2's Foundation

Building the Foundation: How Scoring V2 Started With Pure Research

The task was ambitious but deceptively simple on the surface: implement a new scoring methodology for trend analysis in the trend-analysis project. But before a single line of algorithm code could be written, we needed to understand what we were actually measuring. So instead of jumping into implementation, I decided to do something rarely glamorous in development—comprehensive research documentation.

The approach was methodical. I created a six-document research pipeline that would serve as the foundation for everything that came next. It felt like building the blueprint before constructing the building, except this blueprint would be reviewed, debated, and potentially torn apart by stakeholders. No pressure.

First came 01-raw-data.md, where I dissected the actual trending items data sitting in our databases. This wasn’t theoretical—it was looking at real signals, real patterns, understanding what signals actually existed versus what we thought existed. Many teams skip this step and wonder why their scoring logic feels disconnected from reality.

Then I moved to 02-expert-analysis.md, where I synthesized those raw patterns into what experts in the field would consider meaningful signals. The key insight here was recognizing that popularity and quality aren’t the same thing—a viral meme and a genuinely useful tool both trend, but for completely different reasons.

The methodology crystallized in 03-final-methodology.md with the dual-score approach: separate urgency and quality calculations. This wasn’t a compromise—it was recognizing that trends have two independent dimensions that deserve their own evaluation logic.

But research without validation is just theory. That’s where 04-algorithms-validation.md came in, stress-testing our assumptions against edge cases. What happens when a signal is missing? What if engagement suddenly spikes? These questions needed answers before production deployment.

The research revealed gaps, though. 05-data-collection-gap.md honestly documented what data we didn’t have yet—velocity metrics, deeper engagement signals. Rather than pretending we had complete information, 06-data-collection-plan.md outlined exactly how we’d gather these missing pieces.

This entire research phase, spanning six interconnected documents, became the actual source of truth for the implementation team. When developers asked “why are we calculating quality this way?”, the answer wasn’t “because the lead said so”—it was documented reasoning with data backing it up.

The educational bit: Git commits are often seen as code changes only, but marking commits as docs(research) is a powerful practice. It creates a timestamped record that research existed as a discrete phase, making it easier to track when decisions were made and why. Many teams lose institutional knowledge because research was never formally documented.

This meticulous groundwork meant that when the actual Scoring V2 implementation began, the team wasn’t debating methodology—they were debating optimizations. That’s the difference between starting from assumptions and starting from research.

Why is Linux safe? Hackers peer through windows only.