**00:00:00 — Maya:** Alex, you have one afternoon. You can tidy an ugly module, or fix an alert everybody ignores. Which gets your afternoon?

**00:00:08 — Alex:** I have a third option. Start a rewrite, discover a framework, and lose the afternoon choosing its logo.

**00:00:14 — Maya:** A strong opening bid for doing neither. Welcome to Development Radio. I'm Maya, with Alex, and this daily pilot asks a useful question: which broken window actually deserves your attention?

**00:00:27 — Alex:** The phrase comes from a tip in The Pragmatic Programmer: don't live with broken windows. We're borrowing the software metaphor here. A visible problem can become something a team learns to tolerate. But that doesn't make every ugly line an emergency.

**00:00:42 — Maya:** Let's put it in a fictional service. A customer asks for a report. A worker times out, retries, and sometimes sends the report twice. There's also an ancient helper function with a name that sounds like a Wi-Fi password.

**00:00:56 — Alex:** I already want to rename it. But duplicate delivery reaches the customer. The helper's appearance might only offend me. We need to trace the behavior before deciding where the actual broken window is.

**00:01:08 — Maya:** And here's the catch: the dashboard says the retry succeeded. Technically true. The report arrived. Twice. So the green dashboard and the unhappy customer are describing the same event from different directions.

**00:01:22 — Alex:** Then fixing the alert alone isn't enough. We'd want evidence about duplicate effects, a recovery path that doesn't repeat them, and a way to see whether that change helped. That's a smaller proposal than replacing the whole worker system.

**00:01:36 — Maya:** Smaller, perhaps. But don't smuggle a miniature platform project into the word evidence. What would you actually do in that one afternoon?

**00:01:45 — Alex:** Trace one example from the request to its visible outcome. Find the moment we forget whether delivery happened. Then propose the narrow repair and a test that reproduces that uncertainty. If the answer needs more time, the afternoon should still leave a better decision behind.

**00:02:02 — Maya:** That's the part I like: useful progress can be a resolved uncertainty. Now take the same proposal to another team. Opening with your code is messy makes them defend the code. Opening with customers sometimes get two reports gives you a shared problem.

**00:02:19 — Alex:** Provided we can show that it happens. And we should ask why the current behavior exists. Maybe the old design was protecting against missing reports. We'd be trading one failure for another if we just suppressed every retry.

**00:02:32 — Maya:** So the staff-level move is to make the tradeoff visible, then help people choose. It isn't to arrive carrying a bigger broom and announce that everything is technical debt.

**00:02:42 — Alex:** My broom has a migration strategy, actually.

**00:02:45 — Maya:** Of course it does. Here's your next move: pick one recurring operational problem. Write its user consequence, the smallest useful repair, and the evidence that would show it worked. Three lines, before a design document.

**00:02:59 — Alex:** And if all three lines are about how much nicer the code would look, keep digging. Clean code matters. Knowing which cleanup changes someone's day is the judgment we're practicing.

**00:03:09 — Maya:** That's Development Radio. Fix one consequential window. The framework logo can wait.