Notes

3 min read

"We'll fix it after launch" is a lie everyone in the room already knows.

A known problem should either block the launch or be accepted without a promise to fix it later.

Pulp poster reading "We'll fix it after launch": engineers duct-tape a spraying leak on a rocket mid-launch while a manager gives a thumbs up and checks his watch. Bottom line: everyone in the room knows.

The sentence

"We'll fix it after launch." I've heard it in planning rooms at every company I've worked at. There is a known problem, and the room agrees to put it on the other side of launch.

I've spent twenty years shipping software and have run engineering teams for a long time. I've watched this happen enough to stop treating the sentence as a plan. In my experience, the fix never comes.

Nobody has to be lying on purpose. The room agrees to something everyone already knows is false. It ends the meeting.

The ticket has a future, allegedly

The problem goes into the backlog. The next launch comes along, and the ticket gets re-prioritized underneath it. After a while, everyone stops mentioning it.

The ticket makes the promise look more substantial than it is. There is somewhere to point when the question comes up. But recording a problem and deciding to solve it are separate acts.

If the next launch can push the fix aside, the original promise has no force. It depends on future work being less important than this work. The room has already declined to make that judgment while the problem is in front of it.

A convenient agreement

I understand why everyone agrees. The sentence ends the meeting and moves the pain to a future nobody owns. The problem is still there, but the room can stop dealing with it.

We can agree that something matters without letting it affect the launch. We can also avoid saying that it does not matter enough to fix. If nobody owns that future, the promise is just a way to finish talking. We should be able to end a meeting without pretending we have decided to do work we will keep putting off.

Say the decision

My position is simple: never ship a known hole. If it is known and it matters, it blocks the launch. If it does not matter, say that out loud and delete the ticket.

Deleting it means giving up the comfortable claim that a fix is coming. That is useful. It makes us state the decision we are actually making, while there is still a decision to make.

We are shipping with this and we are not going to fix it.

That is one honest sentence. "This blocks launch" is the other. Both tell the room what follows from the problem it already knows about.

The first accepts the problem and abandons the promise. The second accepts the cost of fixing it before shipping. Neither leaves an imaginary future fix to do the work of a present decision.

I want the sentence to match the choice. If we cannot say we are accepting the problem, we should not ship it. If we can say it, we should stop keeping a ticket around to suggest otherwise.

The rule is short. If it is known and it matters, it blocks launch.