The feature that had never worked

I had taken over the backend of the In-Person module after its initial build. The module is the in-centre side of bbSlate: test weeks, test logs and progress reports, and what teachers, centre staff and parents each see and can do.

My job was to get the module through its production release and own it afterwards. That meant reading every feature end to end, not only the parts I was changing.

Test weeks never showed up as test weeks. Every week behaved like a normal week, so the test-report feature could not be reached at all. Because it had never worked, there was no working version to compare against.

I followed the data instead of the screens. The module decided whether a week was a test week by reading one database column. The next question was simple: who writes that column?

The schedule is set up in the Portal, a separate application. I traced what the Portal writes when a test week is configured, and the column the module relied on was not part of it.

The module was reading a column the Portal never writes. The two systems disagreed about where "this is a test week" lives, so the value the module saw was always the default. The feature had been built and tested against data that production would never produce.

I changed test-week detection to use what the Portal actually records, and I did it everywhere the module made that decision: 6 separate read sites. Fixing only the screen where the bug was visible would have left the other five to fail later.

It was a release blocker, and it was found and fixed before the release, not by users after it. Test weeks became visible, and the test-report feature worked in production for the first time.

Check the data the code depends on, not just the code. Passing tests prove the code agrees with the test data. They do not prove the test data looks like production. For anything that crosses a system boundary, I now check who writes the data before I trust code that reads it.