The Feature Is Ready. Are We?

As an author, I know that feeling beyond software. I’ve finished a book, read it from beginning to end three times, made my revisions, and still wondered whether it was ready to publish. Even after all that work, letting other people read it made me anxious. It’s interesting how closely that moment resembles releasing a feature, at some point, the work leaves your hands and becomes part of someone else’s experience.

As a contractor, I’ve worked on projects where the hardest part of a release had nothing to do with writing the last line of code. It was deciding whether what we had built was ready to put in people’s hands. I’ve seen product teams push developers to release when the feature was not fully functional. I’ve also seen hesitation on the business side when a working feature was ready to go. The pressure to ship and the fear of shipping can both pull a team away from the question that matters "what will users receive?"

A feature can work, solve a real problem, and still have an implementation the team wants to improve. Sometimes the interface has taken on responsibilities that would be cleaner elsewhere. Sometimes the system makes more requests than it needs to. These concerns deserve attention. The question is whether they justify keeping a useful feature from its users today.

I can picture the conversation because I’ve seen different versions of it across projects. The team has spent weeks on something people have been waiting for. The feature is working, the results are right, and everyone can see what it would let users do. Then someone points to the code behind it. They are right that there is a cleaner way to build it, and nobody wants to ignore that.

What follows is a release decision disguised as an architecture discussion. Do we put the working feature in users’ hands, or hold it until the implementation looks the way we wish it had from the start?

Imagine that technical debt is an accepted part of how the team works. There is room to schedule improvements, and the cleanup could be done in the next sprint. In that setting, I would ask what we gain by making users wait. If the current version gives them the functionality they need, can we release it now and commit to improving the code immediately afterward? Or do we wait another sprint for a better design? It is easy to say the delay is only a week. It is harder to account for what that week means to people still working around a missing feature.

I’ve heard the argument from both directions. Sometimes a product team pushes to release while the feature is genuinely unfinished, and developers have to explain why users would be let down by what is there. Other times I’ve been around teams that keep asking for one more round of tests, security checks, or corrections even after the agreed checks have been completed.

I think some of that hesitation comes from the uncertainty of a first launch. Once the feature is out, real people will use it, and the team loses the comfort of being able to keep polishing it in private. That feeling is understandable, but it deserves to be named. Otherwise, anxiety about releasing can sound like an endless list of requirements.

I understand the argument for waiting. Developers have seen temporary solutions become permanent, and “we’ll fix it later” often loses its place behind the next urgent request. A rough implementation can also make future work harder. Those costs are real, and I would not ask a team to pretend otherwise.

But postponement carries its own risk. Once we fix the part that bothered us, we may notice another issue worth improving before launch. We review the new approach, find one more edge to smooth out, and move the date again. Each decision sounds reasonable on its own. Together, they can keep a working solution away from users for far longer than anyone intended.

For me, the distinction is between a feature whose implementation we dislike and a feature that fails the people using it. If it gives wrong results, exposes information, or cannot withstand ordinary use, the work is unfinished. If it works reliably enough to deliver the promised value, an inelegant implementation is a reason to plan a change, not automatically a reason to postpone release. Users cannot see the technical debt we hope to avoid. They can see that they still cannot do the thing we told them was coming.

First make it work, then make it better.

So, do we release it or not?

When facing this choice, I make two decisions together:

First, is the feature ready for the people who need it? If they can use it to get the right result—without unacceptable security or reliability issues—the answer may be yes, even if the code behind it is messy. If the implementation causes problems users will actually face, we resolve those before asking them to rely on it. That is the release decision: judge the feature by what it delivers and the risks it brings, rather than by whether we would build it the same way again.

Second, if we release it, what exactly are we committing to improve? “We’ll fix it later” is too easy to forget. Someone needs to own the work, the team needs to agree on what will change, and the next sprint needs to leave room for it. If we choose to wait instead, we owe the same level of clarity: which specific problem blocks the release, and what will be different for users when we finish the extra work? The decision to delay should have a defined result, just as the decision to ship should have a defined follow-up.

Before agreeing to another week, ask "What will users be able to do next week that they cannot do with the version we have today?"

If they will finally get a correct or dependable feature, waiting has a purpose. If they will get the same working feature with cleaner code behind it, lean toward releasing now and doing that cleanup as promised. The cost of waiting belongs in the decision too: while we improve the implementation, people are still doing their work without the tool they need.

Ask yourself "Would you want to wait for your burger while you’re hungry just because the grill’s electric igniter is broken, even though they can still light it with a match?"