Ghost Raisins

product legacy frameworks

My daughter hates raisins. Last week at her favorite restaurant, she ordered their famous cinnamon apple crumb cake. First bite stopped mid-chew. Raisin.

I watched her spend 15 minutes performing surgery on that cake, picking out every raisin while her ice cream melted into soup. The family next to us ordered, ate, and left while she was still picking.

When I asked the chef why they use raisins, he paused. “That’s how my mentor taught me. Based on a British pudding recipe.”

“Do you still serve British pudding?”

“Haven’t for fifteen years.”

The raisins were ghosts—remnants from a dessert they don’t even make anymore. But here’s my daughter in 2025, picking out raisins that made sense in 1987.

Sound familiar?

The Requirements That Aren’t

Tomorrow I’m reviewing “requirements” for an important quality metrics reporting system. But they’re not requirements—they’re raisin-picking instructions:

  • “Export to Excel to remove duplicates from Source B”
  • “Add flags for when date logic fails so we can manually correct”
  • “Build reconciliation reports for vendor file mismatches”

When you ask why these workarounds exist, you discover:

Legacy raisins: We validate 17 fields from a 2008 federal mandate. The mandate ended. We still validate.

Acquisition raisins: Company X’s data structure, inherited 2016. Sold Company X in 2020. Fields still mandatory.

Compliance raisins: Complex validation from a 2015 audit. Regulation changed 2018. Auditor left 2019. Validation remains.

We’re picking out raisins from desserts we stopped serving, for restaurants that closed, following regulations that expired, using systems we decommissioned.

The Real Cost

My team spends 72 days per year picking ghost raisins. Smart people doing archaeological excavation instead of innovation. While competitors who started fresh are shipping clean code.

Worse—some teammates built careers on efficient raisin removal. They know every raisin’s origin story. When you suggest eliminating raisins, you’re not challenging process. You’re challenging identity.

“We’ve always included raisins.” “They’re there for a reason.” (What reason? “There must have been one.”)

The question nobody asks: Which requirements are actually required? By whom? As of when?

Instead we keep picking. It’s safer than questioning why they’re there.

Tomorrow’s Conversation

“What if we designed our system without any raisins? Not ‘how do we pick better’ but ‘what if there were zero raisins to pick?’”

The new analyst will get it immediately. She doesn’t have muscle memory for problems that predate her career. The veterans will struggle—some raisins are load-bearing in their mental models.

That’s okay.

Sometimes the most powerful requirement isn’t adding another workaround for a 2007 rule.

Sometimes it’s having the courage to say: “No raisins, please.”

The customer never wanted raisins. They just wanted cake.