> The thing is, we can usefully flip this concept on its head! What if more developers developed a sense for the “maximum” number of things a product should do — and stopped there?

I'm sorry, but the author misunderstands entirely the reason for feature creep. It generally has nothing whatsoever to do with "fun" or developers "wanting to develop" or marketers "wanting to stuff to market".

Rather it has to do with segments of customers genuinely needing a given feature, and they won't buy the product unless it has the feature.

There's the old quote about how 80% of the people only use 20% of the features -- but then the punchline is that they're all using a different 20%.

That screenshot of all the Word toolbars? Guess what. There are different user segments that actually use each one of those toolbars. Yup.

So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish. If you're a business and you want to make money and you'll profitably sell to more customers if you can build in a new feature, then you do it.

Why would any company restrict itself to an arbitrary "maximum" and leave money on the table...?

The reviewer liked the product enough, but slated the fact it didn't have a word counter. Now, I for one, have never cared about the number-of-words in a document. But, it turns out, journalists tasked with writing a 2000 word review _really_ care.

With great popularity comes great variability, and more "corner cases" matter.

Incidentally the solution is not fewer features, but better UI. Notice thats a very old screenshot of Word. Whereas Word to day looks very different, has the same (or greater) feature set, and a much more streamlined interface. The much-hated-on ribbon bar is actually a better interface than endlessly-deep menus and a million toolbars.

I'll have my Word with endlessly-deep menus, combined with discoverable keyboard shortcut and Ctrl-shift-p please!

I don't think most people hate it any more.

Once you know where everything is and what the icons mean, it's probably better than nested menus for use with the mouse. Since that describes most of the person-hours in the software, this is an improvement on average. New users and those who lean heavily on the keyboard still aren't going to like it, though.

Still hate it. Most apps did not follow Microsoft’s lead and add a ribbon to their app.

If anything, placing the Styles menu front and center in the Home tab with live preview has made document formatting very discoverable. I used to receive so many Word docs with manually adjusted fonts and line spacing. Not so much after the ribbon was introduced.

How do you know that? This seems like a made up thing I’ve seen it stated by multiple people and it’s probably not true. If you take someone new to computing and show them the old idioms of UI and they’d likely prefer it since it makes way more sense.

I completely agree in principle. The problem is IMHO that the best UX is almost no UI.

Microsoft UI is IMHO essentially industrial automation. Select you data, then push a button (or menu item, or ribbon) to cause something to happen to your data. Apple attempts to encourage more direct interaction with data. The best example is pinch zoom. Remember when maps used navigation buttons to pan and zoom? Direct touch manipulation is better. This is very hard to do with a large feature set though.

One solution is hot-keys, but they do require learning and are limited in number. Context dependent hot keys can also be confusing.

In solvespace we have almost no UI and hot keys are critical to productivity. We avoid context dependence partly by having consistency. The constraint solver is always present, from 2d sketching to building an assembly, so those function keys are universal.

UX is hard, but also distinct from UI.

Piling more chairs on top of each other to get features out the door can be demoralizing. You know it's going to collapse under its weight eventually, and you're just speeding the company along to The Big Expensive Rewrite.

But fixing bugs? An actual chance to make things better? That is satisfying.

No, for a few reasons: 1) it's often tedious work 2) often the bug has been around a long time and nobody's really noticed or cared, so how important could it be? 3) organizations rarely reward this work.

While individual fixes are often unnoticed, the overall effect is profound. Users are happier, support staff are more confident, and programmers are able to build the next layer on a firm foundation.

I agree bug fixing my code is more enjoyable to bug fixing other people's code, and I agree that most programmers resist the former and hate the latter.

But for me, bug-fixing foreign code, is one of the truest tests of skill.

Personally I prefer the thinking, reasoning, tracking down, supposed 'tedium' that comes with bug fixing.

Sure, bugs are boring, but most of the time the new features aren't terribly exciting either.

Even when it’s time for your next job, you can’t very well put on your resume “I fixed bugs for a year” and expect to standout.

Then there is answering behavioral questions at the interview where you have to talk about accomplishments.

On the other hand, I can’t pretend to know what most developers on the enterprise dev side go through at interviews. Even though that’s where I worked most of my career until 2020, I targeted small companies who were looking for “adult supervision”.

And managers care about their career and the size of their team is a proxy for their degree of success. If a company has 100 developers to create new software and 10 to bug fix, they want to be in the development team. If it's 100 to bug fix and 10 to build, it's the other way around.

I think I like bug fixing/performance fixing/'design' (as in db, infrastructure, code structure, refactoring - not UI) most. I don't mind new feature work, mainly because it typically involves some if the latter I suppose. I really don't like total greenfield work though, where you have to faff about with all the initial config of stuff (which assuming you don't start a new project every day you haven't done for ages) - especially anything to do with JS where you also have to work out how to do it without their 'helpful' cli tool, or how to combine a slightly different 19 tools & frameworks than the example you found.

I don't think fixing bugs is the only satisfying thing. Sometimes, the need for new features arises only after users use your product for some time.

For example, PriceTable lets users generate professional-looking estimates quickly. After about a year of using our product, some customers said, "we use it everyday and have sent thousands of estimates to our clients. Is there a way to run reports to gain sales analytics insights?" So we added that feature too. And I found it satisfying. :)

These engineers never really learn from their own mistakes or the mistakes of others. They just jump from one startup to another. "What we need here is another microservice!"

I disagree, I think the Unix philosiphy solves the problem. You build simple tools that do one thing, and do that one thing well, but you make it easy for the tools to work together and then you can have pieces that do one simple thing while still serving needs.

When new needs come up that aren't addressed by current tools you simply put together another simple tool that does that.

Let's say you take a mega-program, break it into 100 programs.

Each now becomes more stable, due to simplicity. Yes, it really does.

But my point is, when you use those individual things, you use a random allotment of 3 or 4 of them. Not all 100.

Thus, the stringing-together bit is far, far less complex.

This is the statement I disagree with the most.

The problem is that combining different programs, that aren't strictly written to interoperate in a specific way, gives you an order of magnitude increase in the complexity. Sure, running find and grep together is common enough, but how about running {obscure_command_rarely_used} through {other_command} through {other_other_command}. There are always corner cases that can crop up, and even before we get to corner cases, just understanding how to fit the pieces together correctly is not so simple.

One cohesive program designed to all work together sometimes just makes more sense, especially when we're talking about complicated, high level actions, as opposed to the more common low-level actions of unix commands. (Or well, maybe high level and low level is the wrong way to put it - maybe the lower abstraction stuff in Word vs. the higher abstraction stuff that Unix tools deal with.)

Yes, your example of find|grep is perfect for this. Sometimes (not often) I have a situation where a simple pipe combination doesn’t work and I have to fall back to awk, which would be the single cohesive (and more complicated ) program.

And so you find that a small change somewhere like deprecating an option, fixing a typo, or adding extra data to the output makes the integration explode horribly in a confusing fashion.

There's also that plain text is a horrible serialization mechanism. Every program has to deal with parsing text that's mostly made for human consumption and deal with things like imprecise boundaries and arbitrary limitations per tool and per system.

Eg, /etc/passwd is a nice simple format, until you consider that somebody might want to use a ":" in a field, or to add more fields, or to store multiple lines of data. And all those quirks are specific for that particular file and may be handled subtly differently by other parts of the system.

And internationalization is an extra bit of fun, which ensures random bizarre bugs that use ',' instead of '.' as the decimal separator, or just emit text in some language that isn't English.

Integration and ease of use are features in themselves.

The best of both worlds would be building things that is modular from the developers perspective but integrated from the perspective of the user. Few will pull that off though, and when they do the modular systems become complex and expensive bespoke setups (Typical of e.g SAP, Oracle).

You're right, systemd does fail in this.

And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.

> the punchline is that they're all using a different 20%.

You could try creating different products.

1. https://www.investopedia.com/terms/e/empirebuilding.asp

Each additional 20% of the features you support cuts the UI and technical effort that can be put into the other 20%s of features.

The end result is the standard big corporate apps that feel heavy weight despite doing what feels like a pretty simple thing.

It makes sense for companies to do it. Because the cost is born by the consumers.

There are examples to the contrary. CAD products I think are way more complex than this JIRA abomination but are not slow at all. And for what it worth I went from knowing nothing to producing complete design of a relatively complex piece of equipment (main assembly, all individual parts etc in a form accepted by factory) in less than a month using Solidworks. This says something about quality of this piece of software. Out of fun when I had nothing to do I tried to repeat the design in FreeCAD - never fucking again.

So I think the problem is not the amount of features (the more the better). It is just very hard to design proper ergonomic GUI and workflow.

If only that were true. There are several long-requested features that they refuse to implement on "agile purity" grounds (such as the ability to split a story while also distributing points, so you can mark it as partially complete in a sprint, or at least leave behind completed subtasks in the old sprint).

Fun fact: a single Jira Issue page could download up to 100 MB of data. Not joking. Hope they fixed it in time.

https://news.ycombinator.com/item?id=30799083

If you sit down to try to write a program that no one will ever see but yourself, you will have to fight against feature creep. It comes from the creators themselves. It's basic human nature to find it easier to desire things than to restrain oneself.

Because when there's too much options and features users are going to be overwhelmed.

Also, feature creep has nothing to do with developers wanting or not wanting, those are product decisions.

I saw that in the past with an ecommerce, we had a good portal, then stakeholders in corporate that need to justify their salary started shoving more and more stuff, now what was a simple search-find-pay has become interrupted and overwhelmed with features and information.

there is another reason feature creep happens for certain categories of products, which is regulation. If a law is passed mandating industry X needs to support Y that feature will be added for any product wanting to sell to the market that has mandated the feature.

any analysis that misses these kinds of real world scenarios is not that interesting.

Adding new features is fun and exciting but feature creep is bad?

What is feature creep if not new features? (Well new features + the idea that we're adding more features than we're thinking about their implementation and/or before the app does what it set out to do in the first place)

This is all pretty early days, but my hope is that we can iterate the core "have feature toggles" concept to the point where we have the ability to turn functionality and function accessibility on across many verticals. I hope that one day internally we can configure things a per-customer and per-user-persona basis. I also hope that one day we can expose some of those switches to admins and/or everyday users, possibly with paywalls or other strictures.

We'll see where it all lands :D

The upside is a clean interface which helps during training, support, and day to day use.

The primary downside is discoverability. Occasionally customer needs change and some assume "the software doesn't have that feature" rather than call us, or check online.

That's a problem best solved with good communication, but that can never be perfect.

[1] this is in the B2B space, and has a proper sales, install, support cycle.

Anyway no one uses an alternative to MS Word / Office 365 because the alternative has fewer features.

Imagine one of your customer requests a feature, e.g. “add a button on form X that transmogrifies a foo into a bar and then copies it to form baz”.

The request is communicating multiple things and blurring them together. First, your customer is telling you that they have a business problem that needs to be solved, eg converting foos into bars and making them available to other business processes. Second, they are telling you that in their current process in their business, which likely is centered on particular people with particular personalities, the best solution for them (“best” here means “least amount of stuff I have to change and grief I have to deal with”) is a button that does the conversion and then takes the next step in their workflow.

If you build the feature exactly as requested, it will likely only delight exactly one customer.

On the other hand, if you decompose the request into its different constituent parts, and then build the unique features in such a way it can be composed into arbitrary workflows, you are likely to delight many customers.

In my example, maybe you build some kind of library function that converts foos into bars, and then have a general way to compose it. If I were writing Microsoft Excel, I might implement a ConvertFooToBar() function and make it available in both formulas and in script.

In other words, dissect customer requests carefully, implement the uniqueness and throw away customer specific workflows in favor of composability. In fact it’s a lot like the Unix philosophy.

There are other kinds of feature requests that may not initially seem to fit this model, like security features. One I have gotten a lot (and made myself) is “federated login”. You still need to dissect these to separate business problem from workflow, eg the business problem might be “I don't want you having a list pf all my users and their passwords”; again you need to aim for composability while solving the business problem.

Separately, at a previous job, we stopped using the term “minimum viable product” because such MVP products are almost invariably shitty. Instead, we adopted the term “minimum lovable product”, implying that the product must not only be useful and fit for purpose but must also not be onerous to use; you don't want customers to discard it as soon as anything else comes along that isn't as painful.

Often times customers come with feature requests but dev/biz fail to translate that into problem resolutions.

"I want it to export all my data for this time period", should be followed by an in depth discussion on why that's needed, whose going to do perform the task, how often, under which circumstances.

A bad translation more often than not translates to bad UIs, half-features, and hours upon hours wasted on dev time and customer support time.

The more powerful machines have become, and the larger the screens we work with (I am writing this on an LG 49" ultrawide), the easier it becomes to jam a bunch of stuff in there.

A good exercise for Keeping It Simple, Stupid (KISS), is to write firmware for fixed displays, or mobile device software (although mobile devices are starting to look more and more like full-sized computers, these days).

I learned religion from Scott Jenson's excellent The Simplicity Shift[0]. It was written before the iPhone.

Most of the tips in there, could be applied to desktop/laptop computer software. I used to use his "triage" methodology, in the days that we wrote host software, at my old job.

[0] https://jenson.org/The-Simplicity-Shift.pdf

This book is over 100 pages long -- any chance you could summarize some of the most important ideas, like the "triage" methodology, so we can figure out if we want to read it?

But the main gist of the book is about prioritizing features. Remember that it was written, when the peak of phone technology was the Motorola RAZR, with its tiny screen, and people were writing “m.” mobile sites in WML.

It recommends a pretty intense selection process, with a lot of bathwater being thrown out, and care, taken, not to include the babies in that.

The methodology that I developed, based on this philosophy, was what I call "Front of the Box/Back of the Box."

Say we have a boxed product on a store shelf. The front of the box is facing out.

You only want to list no more than three main features, in big font, on the front of the box, to catch the buyer's attention.

The buyer then takes down the box, and turns it around, so you can list, maybe four features, on the back, in smaller font.

The rest of the features are listed on the sides of the box, in even smaller font.

When we look at our feature set this way, it requires a brutal triage. We need to do away with the thought that "Every Feature is Precious," and select the three (maximum) "Front of the Box" features, etc.

This also affects the project design and implementation, as well. We need to make sure that the "Front of the Box" features are done first, even if they are not the most problematic or challenging features. They are the ones that will be important to the end-user.

That way, when the inevitable "crunch time" comes, and we are tossing out features, the ones we toss out, are the "Side of the Box" features.

In terms of teams, I don't think "developers" are here to blame. Where are the product managers? And I don't mean the project managers pretending to be product managers. Great products require the vision of a designer, organizational skill of a product manager and developers to be able to implement and/or tell everybody is asking for something feasible with current technology.

Its not easy, which is why so many products suck.

Which generates bad PR and companies like to avoid that. I've seen quiet a few highly voted hacker news threads which get angry at:

- A feature being removed from something.

- An app adding metrics and analytics to track feature usage.

Then what? Follow this line of reasoning to its terminal (or shall we say, maximal) conclusion: developers would be laid off or fired (or at best shifted to another product, which might not be what makes money for the business, so back to an increased risk of being laid off or fired). Tell your boss that the product is done, no more updates needed, and see how well it goes for you.

We already know why feature creep happens, people need to work to survive. One of the few ways to prevent this occurs in open source, where people's livelihood is (generally speaking) not tied to their output. If we want feature creep to stop, we would have to live in a society where people wouldn't need to work to survive. I'm sure that will come with AI automation soon enough, if ChatGPT and Stable Diffusion and other adjacent programs are anything to go by.

Assume for the moment you had a sales driven model, like say Word did in the era of those screenshot.

Your whole business depends on more sales. Developers, support, admin - stop selling for a month and the business goes under.

More customers means more support, which means more overhead, which means sales has to increase in pace. This clearly isn't sustainable (so, no one gets support.)

Part of those sales goes to existing customers. (upgrades). Which means new features.

It's a treadmill to dream up new things just so there are things to sell as part of the upgrade.

Recognizing this route could only end in a crash we switched to a SaaS model. Now support is a priority (and we'll funded), programming, and random new features less so. Customers get better support, programmers get rewarded for fixing bugs, new features can be considered, well planned, and done properly on a decent time scale.

And if the business never sells another copy, it's OK. Support remains funded.

It's a much better model for customers, for support and programmers, and ultimately yes, better for business owners as well.

I was reminded of this quote (from Shannon Vallor who I don't know via a Cory Doctorow post https://pluralistic.net/2022/10/20/benevolent-dictators/#fel...). It's not even just about having too many features anymore, it's about having actively user hostile features that want to manipulate you into doing things or steal your data.

The article mentions Word / MS Office which is the prototype for this. They long ago crossed the Rubicon into the "too many features" domain, but recently they have moved into "connected experiences" - we want to upload everything you write and will dark pattern you into some technicality of consent, plus nonsense like accessibility checker that complains about things I do in internal company presentations while (outside of connected experiences, through some other scam to steal my data) uploads all my charts to MS servers and captions them for me so that blind users will now they are "a picture of a chart"

Anyway, that turned into a rant. Tldr, 2005 was about too many features, 2022 is about ultra manipulative features that try to steal your data and impose tech designers' world view on users

It is a brave product manager that declares his product more or less feature-complete. Because it is a far more frightening proposition for a company to begin a new product, perhaps only their 2nd ever, rather than glom-on extras to their first-born.

It’s one thing to manage a backlog of features into a product (or to discard them), but quite another to have the clarity of vision for your product that allows you to repeatedly say “no” even in the face of clear customer demand for functionality. Functionality that really belongs in your 2nd app, not your 1st. Even if you as a product manager have that clarity, you’ve then got to get the rest of the company behind you. IMO the only thing harder is getting a company to kill a product that needs killing.

There are plenty of products have iterated over decades and maintained the same simplicity, think Ableton Live. I would even give Word some credit in that it has recovered from the earlier mess the author points out by delivering a toolbar architecture through its ribbon menus and advanced settings to hit those less common use cases while maintaining a level of approachability. Sometimes all it takes is a step back and a bit of thought on design.

You're right about the thinking. But that thinking is flawed. Must product X be used by everyone? No, there are (literally) millions of customers out there - pick a segment and serve it well.

You start offering A, then you offer everything from A to F, putting complex strains on design and overwhelming your users over and over. Then you start losing the customers that liked A but find the software too bloated.

If the simplicity is artful, then the copy just “doesn’t feel right.”

Anyone remember the Movado watch? When it came out, there was nothing like it. A lot of competitors tried copying it, and they just looked cheap.

It eventually fell out of fashion, but it commanded top dollar, the whole time, despite the copycats.

I never liked it, and would not have brought one, but I have to respect the design.

The same could be said for Apple’s stuff. Not all of it is something worth copying, but they are a multi-trillion dollar company, regardless of the hate heaped on them.

Nowadays, it’s actually fairly easy to copy complex stuff; especially if a lot of that UI is the result of leveraging standard chrome in a framework.

You can't keep adding to a broken paradigm and get ideal results. True, that might disrupt current users but done right they'll eventually appreciate it if you've made the tool less friction-y. An alternative is to give user the option to see what they want and ignore what they don't. Maybe allow them to change background colors so their most used features are easier to see?

Put another way, it's not how much you say, it's how you say it.

> This is what you get when you search for “Maximum” on Pixabay, not really sure what’s going on here.

This image succinctly summarizes the problem that the article is talking about. (It's an actual case of "an image is worth a thousand words".) The correct color scale would have green in the middle and red both on the "minimum" and the "maximum" side. Instead, "maximum" somehow has a generalized positive connotation, even though it is just as far away from "optimal" as "minimum".

Only because you've been referring to v1 as the MVP, everyone thinks launching the "real first version" will be a straight forward process. Only it won't be, because it's v2.0 and the second system effect blindsides everyone and the result is even worse.

Don't be fooled by the siren call of the MVP.

Not because it's "too powerful", no; you'd stop using it because of the fallout. A newer, sleeker alternative comes out with 20% of the features, resulting in a cleaner, faster UX that eats market share (Trello/Jira). Bugs accumulate until people give up. New users open the program, take one look at 3 stacked toolbars of unintelligible options, and go devise workflows that let them avoid opening it again. Structural problems ironically make it hard to add new features so it starts getting rejected. The features are fine, but they're not free.

Yes, and everyone tries it and sees it's missing their one rare feature that they use all the time and that's the end of that dalliance. In the words of jwz, "Mozilla is big because your needs are big."

A PO once said that. And it stuck as something I should strive for.

I also practice Minimum Lovable Code.

Another interesting model that avoids user-interface bloat is installable extensions. For example, Visual Studio and Visual Studio Code. Instead of making EVERY feature accessible via menu, right-click-menu, and ribbon or button bars all the time, make only those features that have been installed available.