Ownership
Taking over Music Mode and Pods
Two ad features were still in development when I took them over, and one had no documentation at all. By the end I was the person who understood both, from the web app down to the audio path on the box.
What they are
Music Mode
A sound that switches the screen
A tone hidden in a venue's music tells the box to switch the TV to a specific video ad, then return to normal broadcast. Tones come in a 32-slot model: slots 1 to 20 use duration bands, slots 21 to 32 are custom lengths.
Pods
Ads that play in order
A pod is a set of ad videos that play in sequence. An operator builds one variation per venue, so the same pod can look different in two bars. It only works when the web app, the cloud backend, the ad-sync step, and the player on the box all agree.
How I ended up owning them
I had tested these features more than anyone, so I knew their behavior better than the people building them. As they moved toward release I moved into a developer role to finish the work, while still holding the test plans.
Music Mode was the harder one, because nobody had written it down. I reverse-engineered it from its code, its logs, and its behavior on live hardware, then wrote the documents the team did not have:
| Document | What it explains |
|---|---|
| File-format specification | How a Music Mode file is structured and stored on the device. |
| Tone-change specification | What happens, step by step, when a tone arrives or changes. |
| Music-output specification | How audio leaves the box and how music and ad sound take turns. |
| Ad-display notes | How the player picks and shows the right creative. |
| Support document for testing | Everything a tester needs: setup, preconditions, known traps. |
| Test-record template and harness doc | The repeatable way to test it (see the harness page). |
Testing Pods like someone trying to break them
I ran an adversarial end-to-end campaign on Pod content management. It produced 10 defects, 2 more that needed a second venue to confirm, and 4 feature gaps. A selection:
| What I found | Why it mattered |
|---|---|
| A pod length of 100,000,000 took the API down | One bad value from a form could stop the service for everyone. |
| Variations could end up with zero venues | Nobody could edit or delete them. They stayed in the system as orphans. |
| Saving a pod during an in-progress ad-sync was silently dropped | The operator saw "saved", but content did not reach the box until the 02:00 sync. |
| A pod whose last slot was an image never announced its end | The player could not tell the pod was finished. |
| A pod with no creatives fired a random creative | A venue could show an ad nobody chose. |
| Images in a pod always played for 15 seconds | Whatever duration the operator set was ignored. |
| After slot 1, no creative played | Multi-slot pods played only their first spot. |
| No audio on creatives played from pods | Silent ads. The root cause is on the debugging page. |
Fixes, and proving they work on real hardware
Not every fix was mine, but every fix got the same treatment. I reproduced the bug on a box, applied the change, confirmed the fix, and wrote down the result. About ten fixes went through this loop on a production-class box, each with a page that says what was broken, what changed, and what I observed afterward.
Some fixes I wrote myself. The pod that never announced its end is one: I wrote the fix and validated it on hardware before handoff.
A sample of bugs I filed while testing
- Uploaded creatives arrived on the device with their audio track stripped.
- A deleted creative still triggered, because its slot file was never removed from the box.
- The TV played creatives instead of the tone's clip.
- The wrong ad fired when a .mov file had been converted to .mp4.
- Music Mode jumped back to broadcast mode at random.
- A long gap between slots, then a frozen frame, then a black screen.
- Video froze mid-slot and resumed a few seconds later.
- Scheduled content did not download the same way as regular content.
Demos
I run the end-to-end demos for Pods, Music Mode, and the venue game, and I wrote the demo runbook the team follows. A demo is a test with an audience, so the runbook starts from my test results: what to set up, what to say, and what to avoid.
The clearest example is the back-to-back tone finding. If you fire tones very quickly, music can play instead of the ad. I flagged it in my test notes, so presenters know about it before they stand in front of a customer.