This Is Why We Test
Software developers need to test their work. My colleague at work pushes “small changes” to production without even running the code locally, and gets exactly what they deserve at times. Broken code (although their reputation remains intact as they’re “a good devloper” so what do I know?).
The reasons to test still apply whether it’s your code, or the code of a third party. Because the consumer experience is important whether you wrote the code, Uncle Bob wrote the code or some YouTuber wrote the code. Our users don’t care.
Can someone write a corporate memo to Amazon detailing this please?
Wimps all round
If you’ve got kids you know the issue. You might need to get some work done, but your child will simply not go to sleep at 3pm to allow you to get this bug fixed.
You’ll need to entertain a child while simultaneously keep working. That’s a multitask challenge where the only race condition is one that will give you an aneurysm.
So you might put on a movie (or two). Who is going to judge, especially if the movie is appropriate for the child.
So when parents fired up “Diary of a Wimpy Kid” (a film about growing up, cartoons, and middle school drama) they were shocked their child got served up “Love & Other Drugs” with Jake Gyllenhaal’s abs.
Predictably, Amazon fixed the error “within 48 hours” after not responding to phone calls. Way to go, Amazon.
How does this happen?
We do know that Amazon don’t care about customer service, and that has been borne out by this story.
Yet in this case they’ve shared a technical reason, thinking that technical incompetence is a good way to justify a poor customer experience.
So they claim that both films had been assigned the same internal identifier by the third-party company responsible for licensing. It’s like Walmart claiming they’re not responsible for their inventory because it comes from a third-party supplier. Clearly nobody checked, management didn’t adequately fill in their risk assessment spreadsheet and Amazon could care less, other than (probably) docking some dev’s bonus for being unable to prevent the incident.
Which is why software developers don’t sleep well at night.
The Lesson Here
This is a classic metadata error. A backend screw-up. A tagging catastrophe. It’s the sort of issue no user should ever see, but every developer fears. Why?
Because metadata isn’t just backend clutter. It’s not just “extra” data. It drives the whole system.
Put the wrong label on a product in e-commerce? Someone orders a toaster and gets a hair dryer. Annoying, but fixable.
Mislabel a video in a streaming service? In this case the UK regulator is involved and the press are enjoying the fact that Amazon are making these stupid mistakes over and over again. Children and sexually explicit content does not go together well, which is to say please don’t mess up your metadata.
And yet companies do. All the time.
Broken Processes
Metadata, permissions, and tagging are often afterthoughts. But they are the glue that holds modern systems together. Especially in complex, federated systems with microservices, APIs, and third-party integrations. When the glue fails, things fall apart, sometimes in headline-making ways.
Tagging isn’t just about safety. It’s about accessibility, personalization, and user trust. If you can’t get a simple movie classification right, why should anyone trust your recommendations, parental controls, or (heaven forbid) payment logic?
In software, small things have big consequences. The devil lies in the defaults.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.
The Secret Developer mocked their own metadata for a demo. So they had nobody to blame when it all went wrong.