We instinctively add on new features and fixes. Why don’t we subtract instead? | Hacker News Reader

We instinctively add on new features and fixes. Why don’t we subtract instead?

washingtonpost.com

23 pointspcl21 comments

We insinctively add on new articles and submissions too.

Discussion (143 comments) from 9 days ago based on Nature article: https://news.ycombinator.com/item?id=26727878

And yet, often I want to submit a link and find I can't because it was discussed 11 months ago? Even if some recent event has rendered it worthy of revisiting?

I consider HN's combination of highly transient discussion (by design) and prohibition on revisiting a topic for a year to be its biggest flaw. Either it should commit fully to transience, and let people discuss whatever they want whenever they want (and permit people to delete comments in perpetuity), or fully commit to being an archive, one thread per link forever.

What HN does now is very good. Posts and comments belong to the community, so they can't be edited or deleted after some time. Not allowing frequent multiple submission is a good heuristic, but if something important happened and there is no good new URL you can submit, you can either create a blog post / tweet announcing the new thing and submit that or message 'dang and ask to submit an old URL even though not enough time has passed.

I can confirm that dang is quite receptive to suggestions, and submissions that tend to broaden the HN perspective (he's specifically mentioned historical pieces) are strongly encouraged.

I was aiming for a tongue-in-cheek way of noting this had been recently discussed, without quite naming this a dupe, though by HN guidelines it probably is.

HN isn't beyond a level of repeated discussion, and even has accrued a set of perennial favourites. Diamonds in particular are forever: https://news.ycombinator.com/item?id=26701421 Also eyeglasses: https://news.ycombinator.com/item?id=19317023

Ongoing stories / long-term developing issues and phenomena can see new developments/understanding hashed out. Largely-similar stories without new developments, not so much. See dang's comment here: https://news.ycombinator.com/item?id=22014114

With new research, there's a fairly predictable progression from pre-publication releases, journal article, discussion of article, hot- and cold-takes, researcher interviews, criticisms, books, reviews of book, etc., etc. Each adding to the earlier in a manner much as this particular article discussus. Though that's in large part simply a dynamic of today's media environment.

"The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun."

It was often said that users only used 20% of Word's functionality, the problem was it wasn't the same 20%. Someone somewhere is utilising a feature you don't even know exists and they aren't doing things wrong they are just doing something different.

I would love to. But users freak when you take things away. And when users freak, sales and marketing freak even more. The fact that a "cleaned up kitchen" may be better for the user community and product as a whole, is lost on the sales and marketing types who tend to be very focused on achieving short term goals rather than mid and long term ones.

Wouldn’t you freak too if your bike was suddenly stripped of pedals “because we found out new users are better without these”? Software products are shared between different users who build their own processes on top of that. No surprise they complain when someone breaks these because “cleaner look” or “better for the community” (what does it even mean?). If you believe in a fresh start, start a new project instead of tricking everyone into something they probably can’t use effectively anymore.

A better analogy would be getting upset that your dozer, back hoe, fertilizer spreader, auger tractor, had the steering wheel replaced with two ropes you pull on

Gonna push back on this analogy. Ripping out features that cause more trouble than they're worth is like moving a dozer, back hoe, fertilizer spreader, etc off your property.

Average users appreciate all the extra real estate of their back yard! So much time to do the thing they enjoy, gardening.

Power users hate you, they used those power tools every day! They felt in control! Their backyard garden was meticulously crafted!

Ideally when you take their dozer, back hoe, etc, you put them into an easy to access shed out of sight from most users. Of course it's an engineering/design challenge to 1) create a shed (segment these features without adding complexity), 2) make it easy to use for power users ("wahh, I gotta click through 4 more options!"). They might be able to pull out their auger tractor, but it just isn't as easy as starting the auger tractor right where they left off.

Even with an analogy, it's hard to say: "1% of our users use this feature, tear it out." Even when it imposes > 1% of work on all future features/releases/testing.

One thing to note is, the less users use a feature, the less you understand how exactly they do it. Of course from a saas point of view, it’s easier to serve most and forget about least (we are here). But technically, only n% of users have advanced tasks that require a dozer on their lawn, because their “lawn” was not meant to have a grass or a kids playground on it from the start. If you sell a product that initially has a dozer in it, it will be bought by 88 home owners and 12 construction sites, because it fits both. If you then remove a dozer, or even put it into “easily accessible place”, construction sites will stall, because their speed depends on having that thing always present on site.

As one example, search engines respect quotes less and less with years. So even if you quote few words, you may not find it anymore.

Another example is my bank app that combined searches from different pages into one omnisearch field. Before that, I could simply go to a specific card and search for “digi” to see recent digital ocean payments with dates, and screenshot it to my accounting guys (also scaleway, kamatera, you name it). Now I have to scroll through “suggestions this week” (ads) with random “digi” in them, and then tap on every DO payment, because some of them are my own expense (on a different card), and I can’t see dates in a list anymore, because “date” is a property of a payment, and omnisearch searches for all kinds of items, and their common class doesn’t have a date, so to speak. They broke it for me, because now instead of one “shutter-send” I have to wait for 5-15 REST queries to complete and shutter-send each of these, confusing my accounting, because they also prefer lists with dates. Not to mention that omnisearch may not show some items for an unknown reason, and that I have no idea who wanted to search for ads and other crap in a bank app, instead of having well-partitioned searches together with a proper omnifield.

Removing stuff is harder because it requires a deeper understanding of the entire system. You can usually add things with only a localized understanding of a part of a system.

My favorite is when we do strip out stuff because “nobody uses it or wants it”. Sometimes we find out right away that that someone is using it. Other times we get asked years down the road, “why doesn’t it have feature X”. Well... we used to have feature X....

Isn't that the point of every redesign? To strip out all the cruft and come up with a more pure look at the problem. And then afterwards you have all your customers complaining, we used to be able to do this, give us this feature back.

That's the theoretical point of every redesign. The practical effect of every redesign seems to be that I must relearn how to use an application. This means when an application is redesigned there's a period when stickiness decreases.

You may also eliminate those features used by only 10% of the population. The issue is that 100% of your customers use one of those features.

Subtracting the pay wall would be nice.

I've yet to see a remove feature OKR.

As a matter of fact I've seen the super-opposite more than once.

That's where the organization figures out they are having the team work on something no customer wants, but they decide the team should go ahead "finish" it, as if there is value in the company maintaining filler.

The worst part of the anti-pattern is when a software leader is trying to do a good job, but finds this puzzling behavior where people in the org just want to hurry up and finish the filler project instead of resolving problems like poor performance, bad customer experience, etc.

Because magic happens two different worlds collide, and we don't know where the magic will happen. So we put everything related and then see what happens.

Of course there are applications that simplicity works well but I believe to create the simplicity we have to understand what is possible we have to deal with complexity first.

Simplicity first doesn't work, because we don't know what will be the most interesting thing for the users.

Relevant xkcd: https://xkcd.com/1172/

I would change 'instinctively' to 'lazily' since it's incrementally easier than understanding the neater way to do it--until it isn't.

Chesterton's Fence.

Reply on news.ycombinator.com