7 ms·
The more features you add
- deterministic 3y agoI 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.
- hoothin 3y agoIndeed. But if the features are common, more maintenance is the only problem.
- eschneider 3y agoIt'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".
- eikenberry 3y agoPerl v4 would be another good example.
- pydry 3y agoUbuntu 10.04
- yellowapple 3y agoWindows 2000
- bmacho 3y agoI also believe (and some others) that this optimum version is usually very very early in the life cycle. Around the first stable release.
- giovannibonetti 3y agoI 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.
- JeffSnazz 3y agoCounterpoint: all open-source software. It's obvious what causes this behavior: for-profit software production is a cancer.
- jareklupinski 3y ago"... the more features you have to support"
- nicbou 3y agoThis is my issue right now. The maintenance overhead is an increasing percentage of my work week.
- jareklupinski 3y agoI 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 https://hn.algolia.com/?q=learn+to+say+no
- nicbou 3y agoThere is zero external pressure. I just built too much stuff that needs maintenance.
- jareklupinski 3y agoah! then it is good to be needed :)
- m463 3y agoYou could add infinite features, then if they don't stick, deprecate them but leave them in.
- mvdtnz 3y agoYou must work for Google.
- throw310822 3y agoAside 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.
- x86x87 3y agoin case of bloat most features are not used. you spend almost all your time and attention maintaining shit nobody cares about
- throw310822 3y agoI 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.
- bsdpufferfish 3y agoThe cost of a change is proportional to how many things it touches.
- amatecha 3y agoIn 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.
- photon_collider 3y agoThe 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.
- sasham 3y agoEven worse, it becomes harder to discover and use the basic / must have features.
- 11235813213455 3y agothe more bugs
- yarg 3y agoWell 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).
- drpixie 3y agoyup - 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.
- SoftTalker 3y agoJoel 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.
- eloisant 3y agoJoel 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.
- hermanradtke 3y ago> 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.
- disgruntledphd2 3y agoYeah, 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.
- replygirl 3y agoi'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
- wokwokwok 3y ago> 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.
- ianand 3y agoRelatedly, 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-it-happens-and-how-to-break-out-of-it/ https://andrewchen.com/this-is-the-product-death-cycle-why-i...).
- eternityforest 3y agoI think "optimal number of features" is too simplified. 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.