[HN Gopher] The more features you add
___________________________________________________________________
The more features you add
Author : wubin
Score : 40 points
Date : 2024-01-13 08:06 UTC (14 hours ago)
(HTM) web link (www.lukew.com)
(TXT) w3m dump (www.lukew.com)
| hoothin wrote:
| Indeed. But if the features are common, more maintenance is the
| only problem.
| eschneider wrote:
| 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".
| eikenberry wrote:
| Perl v4 would be another good example.
| pydry wrote:
| Ubuntu 10.04
| jareklupinski wrote:
| "... the more features you have to support"
| m463 wrote:
| You could add infinite features, then if they don't stick,
| deprecate them but leave them in.
| mvdtnz wrote:
| You must work for Google.
| throw310822 wrote:
| 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.
| x86x87 wrote:
| in case of bloat most features are not used. you spend almost
| all your time and attention maintaining shit nobody cares about
| throw310822 wrote:
| 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.
| bsdpufferfish wrote:
| The cost of a change is proportional to how many things it
| touches.
| amatecha wrote:
| 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.
| photon_collider wrote:
| 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.
| sasham wrote:
| Even worse, it becomes harder to discover and use the basic /
| must have features.
| 11235813213455 wrote:
| the more bugs
| yarg wrote:
| 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).
| SoftTalker wrote:
| 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.
| eloisant wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-13 23:01 UTC)