Why Can't Software Just Stay Good?

In July 2026, Brave’s team documented a failure on YouTube’s mobile website: in fullscreen landscape mode on Android, the settings button was visible but did nothing when tapped. Other player controls still worked.¹

Playing a video and changing its settings are basic actions a user would expect to work reliably. Adding features that users don’t need while breaking the functionality they rely on or pay for is not progress.

Preserving what already works deserves much more attention in product design and engineering decisions. That applies both to the functionality itself and how convenient it is to use it.

Protect core functionality #

Another example is Garmin’s course editor. Drawing, adjusting and saving routes are the core functions for anyone looking to plan a route.

In summer 2026, users reported that route creation froze. Garmin investigated and later said the issue should be resolved in Connect Web 5.25.2. A later thread covers failures when moving waypoints, backend changes to address them and subsequent reports of unwanted loops and detours.

For a route planner, regression tests should cover basic editing actions such as moving a waypoint and check the resulting route for unwanted detours. Manual release checks or feedback from beta users should catch regressions when editing existing courses or creating new ones. I described a similar approach in From Code Review to Evidence Review: show that the change works in the situations that matter to its users.

Include existing users in product decisions #

When it comes to new features, the people asking for the addition are just one group to consider. Check whether meeting their needs adds steps or changes familiar behavior for a much larger group, including people who will never use the new feature. Attracting new users is not a sufficient justification for adding a feature that potentially alienates existing ones. Evaluate feature requests against the needs of all types of users and especially against the core philosophy of the product.

The wallpaper-click behavior introduced in macOS 14 Sonoma offers another example. Clicking the wallpaper moves application windows aside to reveal the desktop. Apple documents this as a way to access desktop widgets. For users who don’t use widgets, it still changes a familiar action.

If you change the default behavior of something people use every day, the improvement should be significant enough to justify breaking user habits. That judgment needs to include people who will continue using the product as before. A feature can work exactly as specified and still make their experience worse.

YouTube offers several smaller examples of how features and interface changes affect everyday use:

• Shorts adds recommendations for a format some users would prefer to hide permanently. YouTube offers a “Show fewer Shorts” preference, which does not hide them entirely.
• Hype adds a video promotion button, badges and leaderboards.
• On the desktop watch page, saving a video to Watch Later sits behind More > Save, adding steps to a frequently used action.

For users who don’t need the added features, the benefit is nonexistent while the extra steps affect the product they came for. Product decisions need to account for that difference, especially when those tasks are the reason someone chose or pays for the product.

Try the same task before and after the change. Count the extra steps, check what existing users struggle to find and include people who don’t want the new feature. Adoption of the addition alone cannot show whether the product has improved for its existing users.

Keep a clear product purpose #

An AI chat interface or a social feature needs to help with something users came to the product to do. The fact that it can be added, or that competitors have added it, is not sufficient justification.

Not every app needs a chatbot and not every product benefits from AI features that are active by default.

For each proposal, name the task it improves and explain why it belongs in this product. If it serves a different audience, consider whether it should be an optional part of the product or a separate offering. The existing experience should remain straightforward for people who do not adopt it.

The work continues after a feature ships #

Feature estimates and product roadmaps need to include ongoing testing and maintenance as well as implementation. A new player control also has to work after rotating the phone and entering fullscreen. A routing change has to work with courses people have already saved.

Someone has to deal with the extra complexity, either the team maintaining the software or the person trying to use it. Leaving that work out of the estimate can mean more support requests and more time spent on workarounds.

Maintenance needs time on the roadmap. A new feature is easy to demonstrate, while keeping route editing reliable for another year is less visible. Planning both explicitly helps ensure that the capacity to maintain the product grows with its scope.

Plan a practical way to reverse a change that causes problems. Small releases are easier to investigate, and making a new feature optional can let users keep working while a problem is addressed. Reverting application code won’t always undo a data change or a change in an external service, so the recovery plan has to fit what is being released.

More changes to maintain #

I use coding agents extensively for implementation and investigation. They make it easier to change software, but every feature added still needs to be maintained. Faster implementation doesn’t remove that work.

GitLab’s AI Accountability Report, published June 23, 2026, draws on a Harris Poll survey of 1,528 developers and technology buyers. In that survey, 85% agreed that AI had shifted the bottleneck from writing code to reviewing and validating it.

Agents can also help reproduce bugs, write regression tests and investigate behavior across a running system. In Building the Systems That Produce Software, I describe the context and access needed to make that work useful.

Use some of that additional development capacity to investigate recurring failures and simplify the code behind them. Include this work in release plans and evaluate its effect on reliability and maintenance effort.

Conclusion #

If you keep adding features without testing their impact on existing users, you risk losing the most loyal users you originally built for. By that time, the accumulated complexity may have made the product difficult to maintain and expensive to simplify. Coding agents make it easier to add features. That makes deciding what belongs in the product more important than ever.