The more features you add(lukew.com)
lukew.com
The more features you add
https://www.lukew.com/ff/entry.asp?2046
34 comments
> And an increasing number of features inevitably begin to bog down what a company can do going forward
This is a common misconception.
It may happen to be true, but it does not have to be true.
What prevents rapid delivery is constraints, and naive, stupid or incompetent implementation (or requirements) for features that add more constraints.
Adding features in a way that aligns with existing constraints, or breaks existing constraints doesn’t have to be slow; just careful.
What kills software is “nothing can ever change once it’s in production”; ie. once a feature is live, it becomes a hard constraint that can never be altered or removed or changed because of user expectations.
It’s not the number of features; it’s the immobility and panic caused by the prospect of anything ever changing, which prevents you changing anything, except very very slowly.
This is a common misconception.
It may happen to be true, but it does not have to be true.
What prevents rapid delivery is constraints, and naive, stupid or incompetent implementation (or requirements) for features that add more constraints.
Adding features in a way that aligns with existing constraints, or breaks existing constraints doesn’t have to be slow; just careful.
What kills software is “nothing can ever change once it’s in production”; ie. once a feature is live, it becomes a hard constraint that can never be altered or removed or changed because of user expectations.
It’s not the number of features; it’s the immobility and panic caused by the prospect of anything ever changing, which prevents you changing anything, except very very slowly.
The other issue with having so many features is that some of these features may become harder to discover, especially if users have to sift through congested user interfaces.
Even worse, it becomes harder to discover and use the basic / must have features.
Joel Spolsky wrote years ago that nothing generated new sales of his software more than releasing a new version with more features.
That's hard for a business to turn down.
That's hard for a business to turn down.
Joel Spolsky was in the business of selling versions of his software. A lot of businesses nowadays are selling subscriptions to saas software, and the sales dynamic is very different.
> the sales dynamic is very different
For enterprise SaaS, QBRs and contract renewals are the point where sales shares all the new features as part of the story as to why the company should continue being a customer.
For enterprise SaaS, QBRs and contract renewals are the point where sales shares all the new features as part of the story as to why the company should continue being a customer.
Yeah, and lots of big companies have checklists for RFPs et al, so if you don't have a feature it doesn't matter how good the rest of your software is, unfortunately.
It's true that any app that lives long enough reaches an "optimum" version and then goes downhill from there. For Microsoft Word, for instance, the optimum, or "Elvis" version was "v5.1 for Mac".
I wonder if it is related to when the most competent team — often the one that created the product — leaves and is replaced by other people that can't maintain the same level of quality.
Counterpoint: all open-source software. It's obvious what causes this behavior: for-profit software production is a cancer.
I also believe (and some others) that this optimum version is usually very very early in the life cycle. Around the first stable release.
"... the more features you have to support"
This is my issue right now. The maintenance overhead is an increasing percentage of my work week.
I read something called "learn to say no" on HN a while ago, trying to find the same one again might be tough but that was the gist of it: https://hn.algolia.com/?q=learn+to+say+no
There is zero external pressure. I just built too much stuff that needs maintenance.
ah! then it is good to be needed :)
Indeed. But if the features are common, more maintenance is the only problem.
Aside the fact that more features means more time spent supporting them- is it actually true that too many features degrade the product because it becomes too complicated? I disagree.
A good interface organisation can hide the most complex features from most users. The lack of a feature might force users to use a different product; but if the software is confusing, or bloated, this is a problem with its how it's organised and the quality of its code, not with the number of features per se.
A good interface organisation can hide the most complex features from most users. The lack of a feature might force users to use a different product; but if the software is confusing, or bloated, this is a problem with its how it's organised and the quality of its code, not with the number of features per se.
In my experience/opinion, most software companies don't spend the time/effort to properly integrate new features in a cohesive way that makes them "intuitively" discoverable while avoiding complicating what was already there. The product becomes degraded because no one spends the amount of effort needed to cleanly integrate a new feature which changes the model of how a person interacts with the software. Instead it's usually just tacked on, shoved in somewhere that it kinda fits. New button, menu item, toolbar tool, whatever. More stuff.
The cost of a change is proportional to how many things it touches.
in case of bloat most features are not used. you spend almost all your time and attention maintaining shit nobody cares about
I usually think of bloated software as sw with features that are ill-conceived, either because they've been thrown in by some clueless pm, or because they're not really meant to help the user but only to generate a profit for the company, or to justify the existence of a team. If that's the case, it's not much the number of features per se, it's how they've been designed and implemented.
I disagree that more features require more maintenance. Not my experience at all. I maintaining very large scale C++ software and work 99% of my time on new features. Solid auto tests ensure that old features doesn't break.
Relatedly, and more important for startup founders, is that more features may not actually drive increased adoption (e.g. David Bland's product death cycle https://andrewchen.com/this-is-the-product-death-cycle-why-i...).
i've come to believe Fopt and F2 are only different numbers when you're underinvested in design, or that you have positioned your incentive structure in opposition to HCI first principles
the more bugs
Well that all depends on how well the features are integrated.
Often times a new feature is similar from the API perspective to pre-existing ones.
If that's the case either integration is simple, or you need to refactor the underlying API (which means that when you eventually get around to implementing the feature it (and similar future features) will integrate cleanly).
Often times a new feature is similar from the API perspective to pre-existing ones.
If that's the case either integration is simple, or you need to refactor the underlying API (which means that when you eventually get around to implementing the feature it (and similar future features) will integrate cleanly).
yup - and because the number feature interactions is exponential with the number of features, things get much, much worse as the number of interacting features increases.
Many features don't require any user interaction or even knowledge, like passive error checks, and are easy to implement.
Some features can replace other features or even other entire systems, which would otherwise be much more work without the integration.
If I'm selling something on eBay, they do everything from communications to returns to payments to shipping calculations to keeping track of what I've bought and sold.
I sure wouldn't want to use some kind of modular thing where those were all separate parts.
Minimum effort spent on stuff nobody wants to do, minimum chance of mistakes, and minimum chance for getting into a state where you have to go back and redo earlier work is a more direct measure than just trying to avoid complexity.
That last one seems to be one of the usual very common points that make systems harder to use for people who aren't used to how software in general works, because it requires making the user define things as small pieces that the computer stacks up for you, rather than the real world process of stacking up stuff you wouldn't even think of as separate steps.