Just One More Feature …

Not a single firewall was running in production in the dataforest cloud yet. The firewalls were still in development. They were meant to let users control their own inbound and outbound traffic. No user had ever written a rule. But the next idea was already born, shared IP lists maintained in one place so you don’t have to enter the same addresses into every firewall by hand. A great idea.

The lists were already half built, with their own page, an entry in the navigation, finished translations. Yet not a single firewall was running in production. We were building the roof before the walls stood. So I set the lists aside for now and put my full focus on the firewall.

The impulse is human. You want too much at once and lose sight of the core. Behind it sits a fallacy, the belief that more is better, when it rarely is.

The next feature beckons

The next feature pulls at you so reliably because adding is visible and finishing is not. It starts in the daily standup. “I’ve made a start on the shared lists” sounds like “very busy.” Say for the fifth time that you’re still on the firewall, and it sounds like you’re not getting anywhere.

And it isn’t only about how it looks from the outside. Even with no audience, the pull toward adding is there. A study in Nature showed it across eight experiments. Asked to improve something, people mostly add and overlook the solution that takes something away, even where removing would clearly be better. And the less time there is to think, the more likely you are to add rather than subtract. Which is exactly the state you’re in during the final sprint for a new feature.

The shared lists came from the team. Anyone who makes a suggestion like that wants to make the product better. They put themselves in the user’s shoes and see what the user might need one day. It’s rarely the quality of the idea that’s the problem.

But while the next idea is being discussed, you lose sight of what matters. The user is waiting for the one feature that’s almost done. And you tell yourself, “just this one addition or tweak, then it’s really finished,” and so the release slips further and further. Donald Reinertsen calls the price for this Cost of Delay, the cost that adds up with every additional day something isn’t out. Because that cost is invisible, we act as if delay were free. Nobody notices what arrives too late as a mistake, and supposedly nobody misses what never ships.

Technology is not an end in itself

Doing too much doesn’t always mean a new feature. Last autumn I built a component for a frontend that lazy-loads other components once they actually enter the viewport. It came fully equipped with a loading animation, error handling and a timeout for when things go really wrong. My ambition was to squeeze the last few milliseconds out of the user interface.

To this day no one has used it, which was admittedly also a communication problem. All components load the normal way. But not one user ever complained about the speed. Quite the opposite, plenty of users praise how fast everything feels.

And so I had built technology for its own sake, without solving a real problem. “Premature optimization is the root of all evil,” Donald Knuth noted half a century ago. The bad part wasn’t the time I put into the component. The bad part would have been wiring that machinery in everywhere, because nothing would have gotten noticeably faster, only harder to maintain and more prone to bugs.

The nerve to leave things out

And sometimes finished code has to go too. Well over a thousand lines, with their own complex page structure and a layout of their own, all to explain the cloud to new users. That was what the cloud’s onboarding looked like. It didn’t work as reliably as I had pictured, which is why I replaced it with a simple modal in the dashboard. What remained in the end was seventy lines of code that now work really well.

The hard part isn’t building the essential thing well. It’s having the nerve to leave most of the rest out.

That doesn’t mean more is always wrong. Sometimes the next feature is exactly the one that’s missing. The art is telling that moment apart from the mere reflex to add. And from experience, it isn’t easy.

“Weniger, aber besser”, “less, but better,” is the principle of the German designer Dieter Rams, and over time it has become my own. The one feature that runs at high quality is worth more than ten half-started ones that will soon see the light of day (any day now!). The firewalls are running in production by now. The shared lists will come when it’s their turn. And the onboarding, too, will make its comeback one day. I firmly believe that.

If you’re missing a feature, send me an email at hi@marvinstrauch.de, and at the next roadmap planning session I’ll finally have the best argument there is, a user who genuinely needs a feature.