New features are exciting. Users want them. Stakeholders want them. Designers and developers are excited to work on them. What’s not to like?
When it comes to adding a new feature, I know I've been susceptible to focusing on the benefit without considering the cost. The default is to ask, "Can we build it?" What doesn't always get asked is, "Should we build it?" Sure, adding features is a big part of building an app and growing a business, but it’s not all upside.
New features expand the surface area of your product. They add complexity. There is more that can break, which means more that needs to be maintained. There is more that a user needs to learn, which means on-boarding and retention can suffer. Sometimes new features are “bolted on” in a way that increases their maintenance beyond that of a feature that cleanly fits the existing architecture. "Complexity has a way of compounding difficulties."
If you add features more quickly than you expand your capability for managing the cost (cost in the general sense, not just dollars) of those features, you’ll soon find yourself in the red. The tech debt will pile up. You’ll never seem to manage to bat down bugs as fast as they are coming in. Your app will drown. There is a dual nature to adding new features, a benefit and a liability. Add and remove accordingly.
Notes:
There are ways to manage the amount of software your team or business can be liable for. Many software tools and practices -- like testing, type systems, and OSS frameworks -- help reduce the liability of adding more code. Though I don't have much experience with this, large software companies suggest that staffing and organizational choices are a way to manage (and perhaps mismanage) this liability as well.
Top comments (0)