Rework Is the Invoice From the Last Deadline

Why does this product need so much rework?

Somebody asked me that a few weeks ago, and I texted my answer a few minutes later: “This same scenario happened on the original product. Rushed, out. Corners cut.” A couple of minutes after that, I sent another one: “Or maybe I’m really the one who’s at fault. Is it my failure? It must be.”

I didn’t want to just blame the deadline. If there was a pattern, I wanted to know whether I’d allowed it.

Walk into almost any engineering organization and find the team that’s buried in rework. Bugs keep coming back, features get rebuilt, and fixes need their own fixes. Ask around about why, and you’ll get the same answer pretty fast: that team just doesn’t ship clean. Maybe it’s the people, maybe it’s the process, but either way the read is that something is wrong with them.

Sometimes that’s true. More often, in my experience, the real story is older than that.

It usually goes like this. A while back there was a deadline. A customer commitment, a board date, a launch somebody announced before the work was scoped. The date was real and it was hit, and the way it got hit was by cutting corners: skipping the tests, hardcoding the thing that should’ve been configurable, shipping the version that works for the demo and promising to come back for the rest. Everyone involved knew it, and everyone said they’d clean it up later.

Then the deadline passed and everybody celebrated. The people who made the call moved on to the next priority. Some moved to other teams, and some left. The cleanup never got scheduled, because cleanup never has a deadline of its own.

Ward Cunningham called it technical debt back in 1992, and the name stuck because it’s accurate. You borrowed time. The loan didn’t go away when you hit the date. It just stopped showing up on anybody’s dashboard, and eventually it comes due.

The part nobody writes about is who it comes due on. It almost never lands on the people who signed for it. It lands on whoever owns that code a year later. They didn’t make the call, they weren’t in the room, and they may not even know it was a call. All they know is that everything they touch breaks something else, and from the outside it looks like they’re bad at their jobs. (I’ve written before about scope that gets absorbed quietly and comes back as defects everyone pins on the developers. This is the same kind of bill, just with a deadline on it instead of a “can you also.”)

So now you’ve got a team getting graded for a decision somebody else made. Leadership wants to know why velocity is down. The team is quietly frustrated, because they know where the bodies are buried and nobody’s asking them. And the fix people reach for is usually more pressure, with tighter deadlines and more oversight, which is how you end up cutting corners again.

There’s a pretty reliable tell: the same product rushes twice. On the product I was asked about, the new work was being set up exactly like the original, with an optimistic two-month estimate for software nobody had started yet. If you see a product that was rushed to launch, then rushed through its rework, then rushed through the rework of the rework, I wouldn’t call that a team problem. It’s a pattern. The organization has learned that dates are real and debt isn’t, and it keeps making the same trade.

If you want less rework, stop starting with the team that’s holding the invoice and go find who wrote it. Look at the history. When was this shipped, under what deadline, with what known shortcuts? Who decided the date mattered more than the finish? I’m not saying that to find someone to blame. Most of those calls were reasonable at the time. I’m saying it because you can’t fix a pattern if you keep pinning it on the last person to touch it.

So instead of arguing about it, I had the project’s full record pulled into a dated timeline, so the conversation could run on the record and not on anybody’s opinion, mine included. That second text is part of why. If I’d let the date win over the finish, the timeline would show it, and I’d rather learn that from the record.

And the next time you’re about to hit a date by cutting a corner, go ahead if it’s worth it. Sometimes it is. Just write down what you borrowed and who’s going to pay it back, because somebody’s going to pay it.