[HN Gopher] Users only care about 20% of your application
___________________________________________________________________
Users only care about 20% of your application
Author : jnord
Score : 362 points
Date : 2025-09-27 13:15 UTC (2 days ago)
(HTM) web link (idiallo.com)
(TXT) w3m dump (idiallo.com)
| nenenejej wrote:
| I wonder of the 80% how much would they care for it if they had
| time to discover and learn it. And how much they really just will
| never care (unless their role / conpany changes).
| mrweasel wrote:
| Companies frequently moan about "re-training", but in my
| experience users of e.g. Word, or Excel don't need re-training,
| they need training. A large number of people how "Knows Word",
| can't use any of the feature beyond changing the font and font
| size, not even the "headings".
|
| For product like Microsoft Office (or whatever it's called
| these days) 20% is ludicrously high. I'd guess more in the 1% -
| 2% range. Especially Word is way to complex for the needs of
| most people, Wordpad covers the needs of most home users. I
| also thinks that's where the recentment for the remaining
| features come from. It's not that there's some number of
| feature hiding in a corner that's the problem, it's that almost
| the entire application is "useless".
| tonyedgecombe wrote:
| It often feels like the people who spend the most time in
| those applications are the ones least likely to explore the
| software's capabilities.
|
| I've lost count of the number of Word documents I've had to
| edit where the creator completely ignored styles and
| formatted every element individually.
| johannes1234321 wrote:
| It is a lot simpler to count the opposite.
|
| Working with styles is relatively complicated (not hard,
| but distinct form pure wysiwyg picking font&size and hoc)
| and for most small documents doesn't have much of a benefit
| in the result.
|
| For larger documents or professional work it's relevant,
| but by then people are used to adhoc ways
| bux93 wrote:
| Styles are also b0rken in interesting ways. Have you ever
| tried to change the default style to justified, and
| headings to left-aligned? How does that work out for you
| in tables? Table styles in general lack all kinds of
| support. Auto-numbering in headings can theoretically be
| customized, but good luck trying to change it without
| following a step-by-step guide that ends up with the
| default numbering. Using styles is supposed to negate the
| need for empty lines, but the space-before and space-
| after properties are buggy, meaning you end up just
| putting an enter anyway. Empty lines also end up in
| headings since word often, but not always, understands
| that the 'enter' pressed after a heading should start a
| new 'normal' paragraph, rather than a mult-line heading.
| The keep-together, keep-with-next properties on
| tables/rows work only kind-of, rather than consistently.
| Good luck autonumbering tables, illustrations and such.
| Not to mention that if you work on a word document that
| has had its styles changed a few times, there's a lot of
| invisible vestigial stuff in there that will interfere
| with your new styles.
|
| It makes you yearn for latex and xsl-fo(!).
| al_borland wrote:
| The only time I bothered with styles was when I was looking
| to create cohesive documentation for a large team, along
| with templates to help others create such documents.
|
| Ironically, at the time the corporate templates didn't even
| use styles. It was just a 5 page doc with all the different
| things a person might use, and we were expected to
| copy/paste what we wanted to get the proper formatting.
| This wasn't officially stated, but that was the only way I
| could see to use it.
| zwnow wrote:
| My state (Germany) recently switched away from Microsoft to
| open source solutions and public offices have week long
| delays due to employees not finding buttons they were used
| to. They expect a 1 to 1 copy of the Microsoft product.
| Training should be software independent. People need to be
| educated with computer basics, if they work in a field that
| requires the usage of computers. Having to go to some public
| office in my area already is notorious, now its even worse.
| mmmllm wrote:
| They had the week long delays before this switch :D - now
| they just found a good excuse
| nradov wrote:
| The type of education in fundamentals that would allow
| users to flexibly switch between office productivity
| applications requires a fairly high level of abstract
| thinking. Not everyone has that cognitive ability. Some
| struggle with anything more complex than executing a set
| procedure and would require years of remedial education to
| break out of that mindset.
| zwnow wrote:
| Maybe dont employ these people in positions that require
| a specific way of thinking then...
| nradov wrote:
| You're really missing the point. Most clerical jobs don't
| require that specific way of thinking. Major changes to
| office productivity applications are quite rare and it
| would be silly to hire for those jobs based on abstract
| cognitive abilities. Ability to reliably follow
| instructions is usually sufficient.
| zwnow wrote:
| Until... you change the software.
| thewebguyd wrote:
| > Training should be software independent.
|
| Agree, and I see this problem in both non-tech users and
| even sysadmins on my team when I'm looking for new hires.
|
| I'll get resumes of people that are seemingly great, but
| they really only learned a few specific tools and had no
| general understanding of theory or even what those tools
| were doing. I don't care if you "know" Ansible, I do care
| if you know why we use orchestration management in the
| first place, and what those ansible playbooks are doing.
| Tools come and go, but the principles remain.
|
| Likewise with general users. Don't train how to use Word,
| train how to communicate clearly, format ideas, and share
| them with others using a computer. The tool is irrelevant
| troupo wrote:
| With Word especially (and probably with any software
| approaching anything that can be viewed as professional) the
| long tail is unbelievably long, and "users only care about
| 20% of your application" may actually become "users may only
| care about 20% where no two users share the same 20%". Here's
| Microsoft's own research on it from an era when people were
| actually doing research: https://web.archive.org/web/20080329
| 042649/http://blogs.msdn...
|
| --- start quote ---
|
| Beyond the top 10 commands or so, however, the curve flattens
| out considerably. The percentage difference in usage between
| the #100 command ("Accept Change") and the #400 command
| ("Reset Picture") is about the same in difference between #1
| and #11 ("Change Font Size")
|
| --- end quote ---
|
| The whole series is great: https://web.archive.org/web/200803
| 16101025/http://blogs.msdn... and there's a presentation,
| too: https://www.youtube.com/watch?v=AHiNeUTgGkk
| cjs_ac wrote:
| Users are complete human beings, and their interaction with
| your product is a tiny slice of their life. They use your
| product to solve problems that they have. If the 80% of your
| product that they aren't using doesn't relate to their
| problems, they won't use it, even if they know that it exists.
| For example, I've never used Microsoft Word's mail merge
| function, even though I've known it exists for probably twenty
| years, simply because I've never needed to send out a form
| letter to a whole bunch of people.
|
| Sometimes, there is indeed a new feature that could solve a
| problem that they have, but they don't know it exists. I've
| seen a lot of pop-ups in software that try to tell me about new
| features, but I never read them, because I'm always trying to
| do something else when they appear. Emailed newsletters also
| don't work, because the marketing people who design them always
| make them look like advertisements.
|
| Finally, many computer users are deeply incurious about their
| computers, and are often too scared of breaking something to
| try an unfamiliar feature.
| XorNot wrote:
| But the thing is, being scared of something breaking is
| something we as software engineers have pushed onto users.
|
| You click a control and something happens - you don't like
| it, but you don't know what turns it off or undoes it.
| There's no global state rollback. It's like the sheer terror
| those "don't show me this again" buttons instill - the
| concept is frightening even if I'm kind of annoyed by the
| message, and they rarely if ever include an explanation of
| exactly where to do to turn the control back on.
| bux93 wrote:
| And this is only becoming worse in recent years. "Contact
| your administrator", "We are working on updates.." - I
| recently spent 10 minutes trying to find the actual
| location a powerpoint was saved to since every iteration of
| 'open location'/'open in sharepoint'/'copy link' just
| resulted in URLs with GUIDs or opening the document again
| rather than an actual path.
| thewebguyd wrote:
| That fear is very real, and I've noticed it on my team at
| work. Our (internal) help desk ticket work load has
| increased quite a bit over the past ~5 years or so, even
| though our user base hasn't changed much.
|
| People are even afraid to do basic troubleshooting out of
| fear of breaking something and not being able to easily
| rollback to the point that something as simple changing the
| sleep settings on a computer results in a help desk ticket.
| energy123 wrote:
| > their interaction with your product is a tiny slice of
| their life
|
| Low cognitive load should be a major goal, and that doesn't
| mean the app can't be feature rich. Make the app very fast,
| or at least hide latency from the user. No esoteric icons,
| instead default to plain text. If you have icons, no
| artificial delay between mouse-over and tooltip. No smooth
| scrolling. No excessive whitespace. No elements that move
| around while the page loads. No scrolljacking. And actually
| use your app so a random user like me can't find multiple
| bugs in it.
|
| Chatgpt website is a good example of how to tick some of
| these boxes to achieve low cognitive load, despite being
| feature rich. It's very fast, and mousing over an icon
| displays the tooltip immediately. Although they have a few UI
| bugs that they need to fix, I would give them an 8.5/10.
| Gemini website is an example of how to tax cognitive load
| despite being feature poor and "simple". It's very slow for
| large contexts, it scrolljacks, and it has numerous bugs. I
| would give them a 2/10, partly due to the fact that it hasn't
| noticeably improved for over a year since I started using it,
| despite being one of their flagship products.
| nradov wrote:
| Low cognitive load is not a good design goal for most
| software. I mean it's fine for something simple that sees
| only occasional, casual use. But for applications that
| enterprise employees use for hours every day the design
| must be optimized to maximize productivity over a wide
| range of use cases. The decision makers don't care about
| cognitive load.
| nubg wrote:
| Plot twist: but it's sometimes a different 20%.
| juliangmp wrote:
| Uh, did you open the link at all?
| amonith wrote:
| He used 20% of HN.
| layer8 wrote:
| Less than 20% of commenters do.
| defraudbah wrote:
| downvoted, bro
| themafia wrote:
| > Instead of fighting feature bloat, you can embrace the idea
| that your software will be used in ways you never imagined.
|
| Which is why interoperability is the most important feature you
| can embrace.
|
| I get the abstract sense reading this article that the main
| problem is software and sometimes version specific file formats.
| I don't mind cobbling three tools together, it's just that the
| tools seem to mind being used as part of a pipeline.
|
| The dream of Unix is a tricky thing.
| card_zero wrote:
| Pluralism, huh. I suppose this applies to games, too, the
| different ways people enjoy the same game.
| worthless-trash wrote:
| Users dont care about 1% of my application, lets be real.
| ChrisMarshallNY wrote:
| I've found that I'm not so good at anticipating how my work will
| be used, so I tend to "pave the bare spots"[0].
|
| [0] https://littlegreenviper.com/the-road-most-traveled-
| by/#pavi...
| cheschire wrote:
| Desire paths are how I recommend IT policy and governance is
| written too.
|
| But it is worth noting that this can have trouble scaling in a
| complex enough environment and can be more expensive in the
| long run.
| ChrisMarshallNY wrote:
| Very much so. It can probably be scaled to a degree, via
| structure and process.
|
| I'm not a huge fan of the CMMI, but Level 5 prescribes pretty
| much exactly that, though applied to the production process,
| as opposed to the end product.
| hshshshshsh wrote:
| Yeah. But they can you have enough money to fix that. Problem
| is most users don't even make it to that point and over
| engineer.
| bmacho wrote:
| This is just telemetry but IRL and no way to opt out. You can
| _maybe_ hop in someone else 's footsteps if you are not the
| first.
| ChrisMarshallNY wrote:
| That's very true. I worked for a company that was known for
| doing what others have done, but better. That's sort of
| Apple's philosophy, as well.
|
| Anyone can walk through a minefield, as long as they're
| patient, and don't mind walking past a lot of body parts.
|
| Omaha Beach was a nightmare on D-Day, but a lot less
| challenging, in the next few days.
| ojbyrne wrote:
| This should really credit Joel Spolsky somewhere:
| https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
| CodesInChaos wrote:
| Pretty similar article to some old Spolsky blogposts:
|
| https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
|
| https://www.joelonsoftware.com/2006/12/09/simplicity/
| ChrisMarshallNY wrote:
| It's very similar to the second one (Simplicity).
|
| To be fair, the author may not have been aware of these
| previous posts. I find that "kids these days" don't really read
| the classics.
|
| For those not aware, Joel Spolsky, Steve McConnell, Don Norman,
| and a whole bunch of others, _really_ thought hard about our
| vocation, and wrote down their thoughts.
|
| Might be worth a gander.
| raincole wrote:
| It's crazy how well Joel Spolsky's works aged.
|
| Some of them ended up proving wrong (like he once predicted
| that making graphic cards would be a very thin margin
| business[0]), but most are still true today. Probably truer
| than when they were written.
|
| [0]: https://www.joelonsoftware.com/2002/06/12/strategy-
| letter-v In his defense, by the time 'video chips' were totally
| different things from today's mighty 5080.
| Hendrikto wrote:
| > today's mighty 5080
|
| Consumer GPUs really are not where the money is. It's only a
| tiny fraction of Nvidia's revenue, and much lower margin.
| Datacenter GPUs are where the volume and margins are.
| deeringc wrote:
| I would have expected that consumer GPUs still have higher
| volume, but that Datacenter GPUs have much, much higher
| margin and therefore significantly higher revenue and
| profit. Is that not the case?
| raincole wrote:
| Datacenter GPUs definitely amount to a bigger volumn in
| 2025[0]. But even when it wasn't the case, Nvidia had
| been running at a very high margin for years.
|
| [0]: https://nvidianews.nvidia.com/news/nvidia-announces-
| financia...
|
| Out of $46B about $41B is from datacenter.
| Sharlin wrote:
| If Nvidia made SoC GPUs for mobile devides, then they'd
| might have higher volume, depending on market share. But
| gaming and workstation PCs that benefit from a high-
| performance discrete GPU are a pretty niche market these
| days, whether laptop or desktop.
| raincole wrote:
| Nvidia had a very high gross margin % (for a hardware
| company) of ~50% way before AI hype. Even before A100.
| einsteinx2 wrote:
| You're not wrong, but Nvidia's consumer cards also still
| have pretty massive profit margins all things considered.
| It's just they have obscene profit margins in the data
| center cards that make the consumer cards look small by
| comparison.
| seec wrote:
| Yeah but that's mostly because they dominate the
| benchmarks. And part of it is better hardware engineering
| but also part of it is coupling with optimized software
| bits that they pushed to devs very well.
|
| It was very well done and strategic on their part but
| realistically without that they are not that much better
| than AMD and the margins would be much smaller if it had
| 1-to-1 compatibility as an x86 has.
|
| Also, since improvements have been plateauing and entry
| level is becoming enough for more and more people the
| margins are going to diminish even more, high-end GPU is
| going to become even more niche overtime IMO.
|
| So, I'd say he is not wrong in spirit, the timeline is
| just bigger than expected.
| muzani wrote:
| Joel is my favorite essay writer. His writing has established
| so many norms that cargo culted to hell. It's nice to paste
| the original articles to a whole new generation.
|
| People know they should do coding tests in interviews, but
| not how they're designed to find smart and get things done.
|
| People know they should code clean, but not how it only needs
| to be clean enough to spot dangers.
|
| Some companies are paying super high prices for interns, and
| then don't try to integrate them into their recruiting
| funnel.
| chuckadams wrote:
| There's a few that have not, like his stance on rewrites.
| Apparently, if Joel's guru status had been properly
| respected, Netscape would be a powerhouse today, running on
| its Navigator codebase, because "The idea that new code is
| better than old is patently absurd. Old code has been used.
| It has been tested. Lots of bugs have been found, and they've
| been fixed. There's nothing wrong with it."
|
| https://www.joelonsoftware.com/2000/04/06/things-you-
| should-...
|
| There is of course some truth wrapped up in those thick
| layers of punditry, but even today that article gets trotted
| out as some kind of Revealed Truth of Software Engineering to
| be swallowed and digested without qualification.
|
| (Edit: I agree that from-scratch total rewrites are rarely a
| good idea, and should require blindingly obvious
| justification at the very least. I still cannot take all the
| points about Old Code at face value, since rewrites often
| come about after Lots of Bugs have been found and _continue_
| to be found)
| jcgl wrote:
| I think you're claiming an overly strong interpretation of
| Joel's stance on rewrites, something like "new code is
| never better than old code." While that's kind of what your
| quoted excerpt says, that's not what it means in-context.
|
| In-context, his point is pretty obviously (I think) more
| like " _given a piece of code_ , it's never better to
| rewrite." His point is _not_ that newer software can 't
| come along and be better than old software. Rather, all
| other things being equal, rewriting is an inferior
| development choice.
| bluGill wrote:
| Rewrite needs to be seen in context of just fix the old
| code in place. You are always stoppable and making money,
| but spend some effort into cleaning up the things you wish
| you had done differently, enabling tomorrows features,
| while also have spare "manpower" to use to build new
| features.
|
| Rewrites often do work out in the long term. However you
| end up spending 10 years on the rewrite and those are 10
| years where the old thing isn't getting as many features
| (everyone knows it is dead long term so they only invest in
| the most important features thus allowing your competition
| time to catch up). Worse those, in 20 years (10 years after
| the rewrite replaces the old thing) the rewrite is showing
| age because of things you wish you had done differently.
|
| Which is why I advocate for fixing the old code in place
| over time. No matter what your best ideas while turn out to
| be wrong in some way. Architecture decisions that seemed
| good turn out of have downsides. Languages that go
| obsolete. APIs everyone uses that you realize should have
| been done different (If they are only used in one places
| that is an easy change). Core data structures that no
| longer meet your needs, but you can't change without
| touching a million places that update it. You will need a
| long term effort to fix those mistakes whatever they are.
| Sure it will take longer to get the old thing to where it
| needs to be than the rewrite, but you are not saving
| anything as the new thing will have different mistakes that
| you will regret in 10 years.
|
| Also the above is in context of a large program. My program
| to draw names for the family Christmas drawing is easy
| enough for anyone to write from scratch in an hour so who
| cares. When your are on a project that costs over 1 billion
| dollars to write you have different constraints (some of
| you are on small projects that it is better to write from
| scratch each time)
| raincole wrote:
| > Netscape would be a powerhouse today
|
| In our real timeline, Netscape did rewrite. During the
| rewrite their market share halved. And they died a few
| years later. So yeah, the lesson here is if you're okay to
| let your company just die and rebuild a new one, it's
| perfectly fine to rewrite the whole codebase.
| hunterpayne wrote:
| In all fairness, a lot of that was about IE being bundled
| into the OS and other rather underhanded strategies
| employed by MS.
| nextaccountic wrote:
| Rewrites can and sometimes do result in _better code_. They
| just don 't usually help a business bottom line. And
| rewriting stuff didn't help Netscape anyway (but it did
| help Firefox, after Netscape went out of business)
| dapperdrake wrote:
| And in all likelihood they would have stayed a thin-margin
| business.
|
| CNNs and LLMs became feasible and viable much later. People
| in the 1500s would also have bet on the automobile and the
| Wright brothers. Right after drinking coffee from their
| microwave.
| rightbyte wrote:
| He also pioneered 'velocity tracking' for SWE tasks. Seems
| like a major disservice in hind sight. But then again I don't
| think I can't blame him for Agile and Jira.
| michaelrpeskin wrote:
| But I think he's the only one to have done it right. I've
| never seen velocity tracking correct for measured
| inaccuracy in each developer's estimates. I've tried so
| many times to implement his EBS approach, but no one wants
| to do it.
| rightbyte wrote:
| Sure. If I remember the details correctly it was some
| sort of individual approximation of 'veolicity story
| whatever points' too, to make it less arbitrary and
| obviously stupid to KPI-PIP-stack rank people with.
| komadori wrote:
| I worked for a company which adopted FogBugz. The
| multiplier it calculated to be applied to developer time
| estimates quickly diverge towards positive infinity. It's
| probably fair to share some of the blame for that between
| us and it. Nonetheless, we managed to hit our quarterly
| release deadline well in advance of the predicted five to
| six years :-P.
| bee_rider wrote:
| Another note in his defense, that was before integrated
| graphics really (well, integrated graphics were integrated
| into the motherboard at the time, haha). If we include modern
| iGPUs they are pretty low margin devices I guess (or at least
| it is hard to separate out their value from the rest of the
| CPU package). Of course iGPUs aren't add-on cards like he
| describes, but I don't think it really weakens his overall
| point--the most popular GPUs in the world are so cheap
| nowadays they can't even justify the premium of having their
| own PCB or taking up a physical PCI slot.
| indoordin0saur wrote:
| Really? I think he seems entirely wrong when it comes to
| bloatware. For instance, whenever I open Adobe lightroom on
| my high-powered desktop PC it turns into a space heater and
| is crammed with junk features that I feel the need to turn
| off.
| newsclues wrote:
| What percentage of an app do power users care about?
| throawayonthe wrote:
| 15
| defraudbah wrote:
| i'll downvote this comment too
| newsclues wrote:
| Why?
| Minor49er wrote:
| He doesn't even have enough karma to downvote
| defraudbah wrote:
| yeah, then who downvoted you both?
| api wrote:
| For different users it can be a different 20%
| benrutter wrote:
| Not sure if you read the article, but that's exactly its main
| point!
| colonwqbang wrote:
| 80% of HN users read only 20% of the article before writing
| their comment.
| latexr wrote:
| That's the thesis of the article. Hard to miss even when
| skimming, as it's in very large letters near the top.
| atoav wrote:
| I guess most people don't care about our applications _at all_.
| They care about how it solves a problem they want or need to have
| solved.
|
| That is the starting point. You can get people to care if your
| application becomes a great tool for the things they want to do.
| And good tools don't get in your way.
| benrutter wrote:
| > Slack works similarly with its integrations. Discord does this
| with bots and servers. The platform provides the foundation, but
| users craft their own experience on top of it.
|
| Not really the articles core point, but to me at least, those two
| products are full of loads of stuff I don't want!
|
| I thought VS code was a good example, I'm curious about if anyone
| has other examples that they think do modularity well?
| lawn wrote:
| I'd say Emacs and Neovim fit the mold even better than VS code.
| By themselves they're quite bare but with plugins, addons, and
| your own configuration they can become anything you want (and
| more!).
| SoftTalker wrote:
| I suppose the core of emacs is pretty minimal but in practice
| the number of packages that it includes by default is pretty
| large.
| hungryhobbit wrote:
| I thought VS Code was a terrible example: don't 100% of VS Code
| users use the code editing pane?
|
| Some might use the debugger and some might use extensions and
| some might use AI and so on ... but there's nothing 80/20 (or
| 20/80) about the core of the product, and that seems to
| directly contradict the article's point.
| vjvjvjvjghv wrote:
| " your software will be used in ways you never imagined."
|
| This is actually a lot of fun to discover.
| ltbarcly3 wrote:
| If only they could agree on what 20% so we wouldn't have to build
| the rest.
|
| No I didn't read the article but the punchline is trivially
| obvious.
| prasadjoglekar wrote:
| There's a marketing corollary that is called the Modified Pareto.
| Briefly that it's not 80/20 but 60/20. That is 20% of the
| heaviest or power users will consume 60% of the product. But that
| means the 80% will actually consume 40%. That's no longer small
| enough to ignore, so you have to cater to the light or infrequent
| user.
|
| https://marketingscience.info/value-paretos-bottom-80/
| atoav wrote:
| It is always interesting to view such principles as part of
| iterative feedback loop rather than the truthism it is:
|
| 1. Observation: 80% of users only interact with 40% of the
| software
|
| 2. Conclusion: lets cut part of that 60%, since those are
| rarely unused features
|
| 3. Observation: 80% of users only interact with the 40% of the
| remaining software
|
| 4. Conclusion: lets cut..
|
| You get the idea. In reality the most important thing is that
| users _perceive_ your software to be able to solve their
| problems. If you want them to spend money you need to give them
| the feeling your software could also solve their problems if
| they came around in a slightly different shape. And those
| different problems may be covered by the unused features.
|
| If you for example look at 3D software, that bone rigging
| system may be used by only 2% of users for 1% of the time, but
| a much higher fraction of users may not even consider your
| software if it doesn't have that feature in comparison to other
| software, even if they don't need it yet.
| ryangibb wrote:
| This is a good argument for the Unix philosophy's "do one thing"
| to avoid the bloat the author describes. E.g. vi, sendmail, and
| some bash for Word's mail merge. Or Emacs and some lisp. But then
| the onus is on the user to compose these tools to something that
| solves their particular problem.
| oneeyedpigeon wrote:
| I almost commented the same, but I think the tricky bit is that
| it still holds: users only care about 20% of vi, etc.
| psychoslave wrote:
| 99% hardship of any advanced tool that is expected to be used
| by any random person is in integration, discoverability, fault
| tolerance, pragmatic relevant guidance.
|
| I love Vim (RIP Bram, thanks for all the fish), but it's a tool
| for the less than 1% who loves that kind of thing.
|
| Most people won't learn the tool because they see it only as an
| anecdotal detail bringing hindrance in their quest to
| "something".
| pjmlp wrote:
| They also care 0% of how it was written, unless it stands on
| their way, hence why nowadays we have applications of various
| quality levels, when looking under the hood.
| CodeCompost wrote:
| I didn't read the article but in my experience, 80% of the
| application are parts that you rarely touch, config stuff and
| "LEFT JOIN" stuff.
|
| There is always one or two parts where all data comes together
| and that is the heart of your application. Yeah those are the
| parts your users care about and pay you to make.
| filleduchaos wrote:
| It's against the rules to say this, but it would definitely
| help to actually read the article.
| CodeCompost wrote:
| Ok
| davedx wrote:
| > Kagi didn't need to beat Google for everyone; they just needed
| to serve that specific slice of users perfectly. They focused on
| being the ideal 20% for people whose 20% Google was ignoring.
|
| Yes, this is actually a critical insight into how to find
| product-market fit
| carlosjobim wrote:
| When it comes to Kagi, I would guess that it is a better
| alternative for more than 90% of Google search users. The only
| thing making it niche is that it's a paid product competing
| with free.
| didip wrote:
| When it comes to Kagi, it just needs to be the old Google.
| Something that new Google abandoned.
| mixmastamyk wrote:
| Yes, search as it was before enshittification.
| rpastuszak wrote:
| I like to call this approach MISS (MISS - Make It Stupid, Simple)
| or better: Make It Stupid
| Simple, To Experience Revenue
| = M.I.S.S.T.E.R.
|
| i.e. keep removing features until the idea fits in your head, the
| value can be explained concisely to a small group of people to
| whom it'll just 'click'.
|
| https://untested.sonnet.io/notes/miss-make-it-stupid-simple/
| oidar wrote:
| I love your blog. As an aside, on OBEY - I also love smoking
| and have quit - except for one time - for years now. And a
| thing that's helped immensely, is just sitting and becoming
| comfortable with the idea that I will always want cigarettes.
| It's just biology. When I tried to do things like to distract
| myself, like your suggestions in OBEY, the desire became
| stronger. So, my suggestion is to lean into the discomfort of
| not having something you want. Or wanting something, and
| deciding not to take it.
| chrisrickard wrote:
| This is why AI development will be huge in the "Buy vs Build"
| space... Businesses (with a capable tech team)can build the 20%
| of the SaaS they need, and stop paying for the 80% every single
| month.
| nradov wrote:
| And then they'll later find out there is a critical group of
| internal users who was using way more than 20% of the SaaS and
| roll-out of the replacement application is blocked. Whoops.
| ajsnigrutin wrote:
| I kinda miss the unix philosophy... one tool for one job. A PDF
| reader should read PDFs, there's no need for it to have its own
| (possibly paid) cloud service and an AI chat bot.
|
| I do get why some integrations are beneficial (eg. office
| software with text editing, spreadsheets and a database, so you
| can generate eg. letters with data from a database, etc... but
| every service needing its own cloud and adding a useless AI
| chatbot is just a useless overkill for me.
| mushufasa wrote:
| the counterpoint is that unix itself is a holistic system --
| the value of unix is the integration of a bunch of different
| tools by providing a consistent way to manipulate streams of
| text and files with standardization
| data-ottawa wrote:
| I think you have the wrong model for apps. Doing one thing is
| almost always having the full document CRUD loop.
|
| Once you have a pdf viewer users want rotating pages, then
| bookmarks, then highlights, then form filling, etc.
|
| That "just a pdf reader" is strictly worse than every pdf
| editor (which have to meet the minimum requirement of a pdf
| reader).
|
| Apple's Automator and Preview combo for me are indispensible
| and perfectly follow the Unix ideal. Automator composes well,
| and Preview does all the pdf editing well, and together they're
| excellent software.
|
| The version of Preview Apple just released on iPad is however
| basically just a reader, and do it hasn't made itself relevant
| to any of my workflows or needs.
|
| Full featured plus composable. That's the sweet spot for the
| best apps.
|
| Side note: I'm surprised there's no ffmeg or imagemagik for
| pdfs (maybe there is?). Someone should build that.
| OkayPhysicist wrote:
| An under-explored integration type, IMO, is the concept of
| interchangeable parts. I like having an integrated PDF reader
| inside my browser. Problem is, my external pdf-reader is
| substantially better than the pdf reader in my browser.
| Wouldn't it be nice if I could embed the external reader,
| replacing my browser's reader?
|
| Or one that I've actually hacked into a few contexts already:
| What if every multi-line text field could be replaced by a
| neovim buffer?
| tnolet wrote:
| Very true.
|
| But then you start selling to Enterprise and everything changes.
| Because one missing "hygiene feature"* can tank the the whole
| deal. And every Enterprise has a different one.
|
| *like a toilet. It needs to be there. You use it 3 minutes per
| day. If it is not there, the house is uninhabitable.
| mackman wrote:
| As best I can tell we've never sold the same product twice.
| Product roadmap is "whatever the last person I spoke to asked
| for." And tech debt maintaining a grab bag of 5,000 almost-but-
| not-quite-entirely-production-grade "must have" features that
| the customers rarely if ever use despite claiming that not
| having it was a deal breaker, is, well, debty.
| xnorswap wrote:
| The best decision I ever made was moving from a company that
| acted on the whims of whomever the sales team spoke to last,
| to a company that had a strong product vision and was happy
| to say no to their customers on occasion.
|
| It's a lot less exhausting when you're not changing
| priorities every quarter.
|
| You also avoid the soul crushing experience of working really
| hard, crunching to get a feature out, only to realise your
| time was given away free to land a deal. Sometimes a deal
| that fell through anyway.
| tnolet wrote:
| Even if you weed out the willy nilly stuff, you will bump
| into Enterprise users that are actually correct.
|
| They will mention something you know you should have added
| but always wrote off as "bloat" or "not really really
| really needed". Those things start happening more and more
| the moment you are doing $100K plus deals.
| xnorswap wrote:
| Are you talking about structural fundamentals or product
| features?
|
| Because I agree about the fundamentals, the things
| enterprises tend to care about:
|
| - SSO / SAML / auth integrations
|
| - ISO Certifications
|
| - Regular Pen tests
|
| - Localisation support
|
| - APIs ( that they'll never use )
|
| - Bulk operations
|
| - Self-hosting ( or at least isolated / non-shared
| application cloud hosting )
|
| Get these and similar right and it's the difference
| between landing enterprise or not.
|
| But if you're talking about features specific to a
| product, or custom products for a platform, that's a very
| different thing, and that's where the great distraction
| can come in. That's where you'll end up developing
| features that go unused, and it's these which aren't so
| consistent across customers.
|
| Imagine you make washing machines and get a request for:
|
| " This Washing machine must have a pre-set button for a
| 57deg 38.5 minute wash. Without that, I couldn't consider
| this machine ".
|
| You try to argue that you let users define their own pre-
| sets, and that they can set up their own pre-set for that
| cycle. But you're denied by the person in sales who
| insists that they need exactly that as a first-class
| button on the front of the machine.
|
| That's the level of petty that some large customers will
| try. In some way, it can be seen as a good sign that
| they've engaged with your product, but sometimes you
| wonder if it's just a trial balloon for seeing if you'll
| put up with the unreasonable.
| timr wrote:
| You missed some universal ones that are both necessary,
| and a total pain:
|
| - Teams & Fine-grained Permissions
|
| - Audit logging
|
| - SOC 2/3 compliance
|
| - Data wiping / retention / data policy management
|
| - Reporting
|
| - Cookie law crap (GDPR & CCPA)
|
| - Myriad forms of custom product tiers & billing
| arrangements
|
| I'd put these above several of the items on your list,
| and in my mind, they fit into the category of "things a
| developer calls 'bloat', that are actually necessary for
| enterprise sales".
| xnorswap wrote:
| It wasn't an exhaustive list, it was to articulate the
| difference between structural features, which all of
| those are, and product features, which are specific to
| your product.
| timr wrote:
| Yeah, I don't really mean it as a criticism -- my list is
| stuff that I think is incredibly painful to build, ends
| up taking >80% of dev time, is messy/spidery, and which
| I've spent a lot of my life explaining the necessity of
| to (typically junior) engineers.
|
| In short, this is the kind of stuff that I think fits the
| parent comment's categorization: it drives enterprise
| sales, engineers _hate_ building it, and it never really
| ends because the maintenance and detailed feature
| requirements change with almost every contract.
| hedora wrote:
| On top of that, you have to get messaging right. Here's
| an example from consumer:
|
| I'm looking for a TV. I buy after careful research, so
| there's a 90+% chance I'll end up with the TV I have in
| mind before walking into the store.
|
| One device we frequently use (Linux) doesn't send the
| "switch to me" hdmi signal when we start using it, so the
| "switch input" button on the remote is crucial.
|
| The front runner has a One Button (TM) remote. "What
| fresh hell hast thou wrought?", I ask.
|
| On page 1, the manual says to change inputs you need to
| press the gear button, navigate through the settings menu
| to "inputs", and then find the right input from there.
|
| Ok, so do I get the crappier panel to avoid the settings
| menu every time I turn on the TV, or not?
|
| Thankfully, page 10 has a picture of the remote, and it
| has a quick change input button, so that's OK.
|
| On top of that, I want the TV to be a dumb TV.
|
| There's no mention of this in the quickstart guide, but
| it has "Basic Mode" that which is that, except that
| calling something "Basic" is right up there with most
| four letter insults with kids these days.
|
| As a bonus, after reading the manual, I also honestly
| can't tell if it's possible to have four hdmi inputs and
| also variable volume audio out at the same time.
|
| If you're going to produce differentiating features (or
| your competitors are differentiating you via
| enshuttification) you need to make that clear pre-
| purchase.
|
| In enterprise it's at least 10x harder to get this stuff
| right because you probably don't use the product on a
| regular basis, and also, there are many more features.
| tnolet wrote:
| yep, exactly. We implement some parts of that over the
| years and it's a hog.
| pixl97 wrote:
| >bump into Enterprise users
|
| What a lot of these HN programmers seem to miss, is it's
| not about what you or your application provides. It's
| about what your competition is willing to provide. If you
| don't have much competition then that's great, but the
| moment your 100k-10m paying user starts testing the other
| software your C-levels and sales people are going to have
| the programmers locked out of the building the moment
| they say they won't write a feature.
| polishdude20 wrote:
| I worked at a place that did it a third way: The CEO had a
| product vision that changed every month.
| tnolet wrote:
| Founder mode unlocked
| rubicon33 wrote:
| Ultimately the vision for the company and the product
| have to come from SOMEWHERE.
|
| Small companies often have the CEO in a product position
| in my experience.
|
| Still isn't ideal though and more to your point, how they
| actually do the product role is really what matters. I.e.
| chasing shiny objects.
| FireBeyond wrote:
| Depending on the company's product (and this is a wide
| range), somewhere between employee 10 and employee 100,
| the founder needs to decide "Am I CEO of the company? Or
| CEO of the product?" (As in, that "and" needs to become
| an "or").
| nradov wrote:
| It really depends on the industry. In a narrow vertical
| market with only a limited number of large customers, the
| vendors pretty much have to roll over and do whatever the
| customers demand regardless of product vision. Give the
| customers what they want or else they'll find a more
| pliable competitor. The power dynamics are different in
| more horizontal markets.
| magicalhippo wrote:
| If the customer has people on the other end that knows
| about their processes and cares, you can push back.
|
| We landed our largest customer by gar a few years back,
| and we pushed back hard. However we had good arguments
| why, and explained why changing their workflow would be
| much better or offered some other approach to solve the
| problem that didn't involve a new bespoke and brittle
| feature.
|
| On the other side were a team that knew the processes
| well and understood our arguments.
|
| After they went live, the management thanked us for
| helping them improve their organization.
|
| On the other hand there have been cases where decisions
| is made by leaders so high up they have no idea what's
| going on by those that need the tool, and aren't
| interested in spending time or effort on it. Not much you
| can do then.
|
| edit: Though sometimes they learn. We've had a few
| customers who we said no to since their wishes were not
| really feasible, and who selected others and failed, and
| failed again, before finally ending up with us, on our
| terms.
| ryandrake wrote:
| This is one of the things I try to suss out when I
| interview somewhere. Do you have a product team (or at
| least someone in leadership) with a stable requirements
| vision, or do you just haphazardly develop based on whoever
| your sales team last talked to. Having a stable roadmap is
| an absolute requirement for me. I may not agree with the
| roadmap or priorities, but I'd rather have them than not
| have them.
|
| I've worked in both types of companies, and the ones where
| sales dictated what we worked on this week were universally
| awful.
| SoftTalker wrote:
| Another thing to be wary of is a product where there are
| a small number of customers, maybe even just one, who
| contribute the vast majority of the revenue. Because
| then, even with a good product vision, it's going to be
| very hard to say "no" to what they ask for.
| data-ottawa wrote:
| I don't mind this as long as the sales team and management
| allow the correct amount of time to build it in a
| maintainable way.
|
| The reality is I only get paid because of those deals, and
| the post deal tech-debt sprint never happens.
|
| So the work has to get done and if sales doesn't give time
| for it to be done properly then in 3-6 months velocity will
| drop and the sales pipeline will dry up.
|
| Any company that can't understand that is not a long term
| company I want to work at.
| snarf21 wrote:
| This is what I've come to refer to as a _Spice Girls_ sales
| team.
|
| The solution is for the cost of these new additions to come
| off the top of the deal (pre-commission) they are signing to
| re-align the incentives.
| rubicon33 wrote:
| Oh my god you just perfectly described the frustration of
| working in enterprise SaaS. It's been fun in some ways but
| the constant churn of almost-but-not-entirely-production-
| grade software is soul crushing. We celebrate and reward
| speed to market and lack of process in a way that feels
| unhealthy and unrewarding.
|
| I've worked at consumer facing companies but also other
| enterprise SaaS and have to say I've never seen it done like
| this before. Just ruthless pursuit of features over polish,
| craft, etc.
| pixl97 wrote:
| Customers buy features, customers rarely buy polish.
| g8oz wrote:
| Polish increases customer lifetime value.
| didip wrote:
| At least a toilet is fairly standard these days. Not so much
| with digital only products.
| stronglikedan wrote:
| > like a toilet... You use it 3 minutes per day
|
| I think you may need to go see a doctor about that, seriously.
| bobsmooth wrote:
| >You use it 3 minutes per day.
|
| Damn you must get a lot of fiber.
| montag wrote:
| I like to call these "windshield wipers." Rarely used yet
| essential.
| taude wrote:
| I had started writing this in a new thread, then saw yours....
|
| "Unless it's Enterprise users. Then 1000 Enterprises all care
| very seriously about 2 custom features no one else cares about.
| You had to do horrible things to your code base to support,
| that will only kick some poor dev in the face two years after
| you left, and a year after the customer churned."
| r_singh wrote:
| With AI type tools though it's more likely than ever that the 20%
| each user group cares about is a different aspect / feature of
| your application
| nottorp wrote:
| Yes but not all users care about the same 20%.
| oldandboring wrote:
| Tell me you didn't read the article without telling me you
| didn't read the article.
| tgv wrote:
| I'm building things for internal users, and they are quite
| demanding. Many features don't get used often (as is obvious),
| but may be critical for serving different clients. The software
| is also open to external users, and they really stick to the
| basics.
| reinvent42 wrote:
| > I often destroyed our home computer when I was a kid. Armed
| with only 2GB of storage, I'd constantly hunt for files to delete
| to save space.
|
| Many people have a similar experience, but it's amusing that
| statements like this can roughly indicate your age and the
| systems you were dealing with... Mine is 40 MB.
| oblio wrote:
| This is true for folks from the wild and woolly days of...
| before 2005 (I think?).
|
| But if you think about what's happening today, things have
| plateaued. Most people since at least 2005 probably have
| laptops, and generally those hover around 250GB, 500GB, 1TB of
| storage (with the bigger difference being top of the line/more
| expensive configurations, than with generational differences).
| More likely people now identify with 64GB, 128GB, 256GB for
| smartphones and tablets.
|
| We will soon reach a point of mass market computation where the
| "mature" times are longer than the early years (1980 - 2005 =
| 25 years, 2005 - present day = 20 years and counting).
|
| Large leaps, at least in storage, don't really happen (50MB to
| 1GB is <<extremely>> consequential, 500GB to 1TB is meh.
| scarface_74 wrote:
| My high end Dell that I used for my job at a startup that
| they let me keep after the startup collapsed in 2010 was a
| Dell Core 2 Duo 2.66Ghz with 8GB of RAM, a 1920x1280 display
| (one the last with that beautiful ratio), a 500GB hard drive,
| Gig E internet, 892.11n and FireWire.
|
| I put Windows 10 on it when it was released and used it for a
| Plex Server until around 2021. It wasn't until last year that
| base MacBook Airs came with more than 8GB RAM and they still
| come with less storage than that. Not to mention that low end
| PC laptops still come at a lower resolution than my old Dell
| did.
| Cockbrand wrote:
| Oh yes, the memories! [Pun not intended] Mine is 880k. Boy, did
| I squeeze the last bytes out of that Workbench boot floppy!
| magicalhippo wrote:
| I recall when we upgraded our 40MB HDD to a mindboggling 210MB
| drive. I vividly recall booting up, running dir and wondering
| what on earth I was going to do with all that space.
|
| Not a week later I was back to figuring out what to delete to
| free up some space for a new game...
| yibg wrote:
| For me there was a bit of a step function, where I went from
| caring about the size of something (number of floppies -> CDs
| -> HD space limited) to at some point just stopped really
| worrying about it. Yes a 2GB vs 10GB download time differs but
| leave it and it's done when it's done. HDDs these days are big
| enough at least for my (and I would imagine most people's) use.
| I can see storage being a limiting factor if you have a lot of
| games or media though.
| rpigab wrote:
| That's fine, I care about 0% of my users.
| faeyanpiraat wrote:
| why though
| oldandboring wrote:
| I am reminded of an episode of Seinfeld where Jerry gives his dad
| an expensive, multifunction PDA called "The Wizard" but his Dad
| doesn't immediately see the use. Jerry explains it can do all
| kinds of things, for example, it has a calculator he can use to
| calculate tips at restaurants, leading Dad to conclude it's a
| $200 tip calculator. Jerry keeps protesting "it does other
| things!" and the old folks act like they can't even hear him.
| jillesvangurp wrote:
| But they don't necessarily care about the same 20%.
|
| Another thing worth considering is that your users won't actually
| know what features they are going to get until after they've used
| the application. Users will install your app not based on what's
| in the app but based on what they think is going to be in the app
| after they install it. That's an important distinction. All that
| hard work you are doing on features won't actually pay off until
| after you convince people to use the app.
|
| This is especially important when you are trying to make an MVP.
| Lack of features is almost never the problem that prevents users
| from installing and staying in your app. Usually the actual
| issues are with your messaging, marketing, etc. Or maybe your app
| doesn't do anything that actually interests users. Whatever it
| is, your feature set probably has nothing to do with it. Adding
| more features won't solve these issues either. This sounds simple
| but I've seen companies get this wrong.
|
| The simplest MVP is simply trying to get users to sign up before
| you even have anything implemented. It's a common pattern to
| validate ideas.
|
| The best confirmation that your messaging is right is users
| getting disappointed after they sign up. That's still bad but now
| at least you know that at least the messaging is right and that
| you can convince people that what your selling is worth having.
|
| This of course leads to another issue: launching your app before
| it is a proper MVP for whatever your messaging promises. If you
| promise lots of things that aren't actually there, you are
| probably setting people up to be disappointed at least somewhat.
|
| A related point here is that many features are nice to haves that
| are hard to monetize because they aren't that essential.
| Especially with SAAS applications there are usually a lot of nice
| to haves that people don't actually want to pay for. Treating
| your customer wishes as requirements is going to need a lot of
| scrutiny. Do they actually value what they get? Would they pay
| for it? Does it solve some important pain point? Etc. It's more
| important to understand why they ask for stuff than to exactly
| deliver what they ask for.
| Sharlin wrote:
| > But they don't necessarily care about the same 20%.
|
| That's kind of the article's main point.
| dansmith1919 wrote:
| > But they don't necessarily care about the same 20%.
|
| Did you write that entire comment based on the headline only?
| hansvm wrote:
| At one SaaS I worked at, I spent a day or two on a foolhardy
| initiative to analyze our users based on the subset of features
| they actively used (hoping to reign in the complexity of the
| product to a few core archetypes we could design for, ideally
| eliminating some of the more annoying features on the way). The
| results weren't any better than a weighted random choice. Beyond
| the login page (and even that had a few customization options),
| every single person really did have a different 20% they cared
| about.
| ozim wrote:
| That's why pushing back on features is important. It is super
| hard to remove them once they are in.
|
| Most of the time it goes way that sales people promise
| something you build it ,,because that's going to be great huge
| customer" - but after a year or 2 years that huge company moves
| away because people who originally wanted features moved to
| other jobs or departments and you are left supporting something
| some other customer started using by coincidence and is using
| it in totally wrong way but it somehow works good enough but
| still initial effort is not paid back and best would be to kill
| the feature.
| johnmaguire wrote:
| The parent comment seems to imply that roughly 1/5 of their
| user base each used a different 1/5 of the product. This
| implies that every feature was genuinely valuable in driving
| revenue - or at least customer acquisition!
| cantor_S_drug wrote:
| Wasn't this the same argument which Evernote made for its
| bloatedness.
|
| Evernote's 5% problem offers a cautionary lesson to tech
| companies
|
| https://news.ycombinator.com/item?id=10842679
| ozim wrote:
| That doesn't mean feature paid itself off if you invest
| with idea that it will be useful for more than 1/5 of users
| and when feature brings single customer and is marginally
| useful for other customers.
|
| Then also you have ongoing costs of maintaining the feature
| that no one usually accounts for. Even if customer
| participated financially into creating the feature when
| they leave you are left with maintenance.
| ivape wrote:
| Would you consider each 20% to almost be its own utility app
| (could possibly be a standalone app), or do you think each 20%
| were simply different workflows for the same app (each user
| prefers a particular workflow).
| hansvm wrote:
| The latter thing. One user might use features 1,2,3,4,5,
| another 1,3,5,7,9, another 2,4,6,8, and a fourth 1,2,3,8,9.
| Those usages weren't meaningfully disentangleable.
| michaelt wrote:
| _> every single person really did have a different 20% they
| cared about._
|
| I have always wondered what would happen if someone had to
| invent spreadsheets from scratch, today.
|
| Would conditional formatting and pivot tables get removed,
| because only 1% of users use them?
|
| Would they feel supporting column, bar, line, area, pie and X/Y
| charts was just too complicated? That being able to customise
| the chart styles and colour schemes was just going to confuse
| users?
|
| Would they think obscure jargon like 'vlookup' was too
| confusing, and difficult to localise internationally? Would
| they think formulas were too complicated to ever be a mass-
| market feature, as well as too difficult to input on mobile?
|
| Would they discover 80% of office suite users don't use the
| spreadsheet beyond shopping lists, and replace it with a
| shopping list tool?
|
| My theory is the modern software industry couldn't produce such
| a product. I don't think I've seen the industry produce a mass
| market product that requires a comparable level of user
| expertise in 20 years.
| rbonvall wrote:
| > _I have always wondered what would happen if someone had to
| invent spreadsheets from scratch, today._
|
| This is exactly what Joel Spolsky did:
|
| > _What was I talking about? Oh yeah... most people just used
| Excel to make lists. Suddenly we understood why Lotus Improv,
| which was this fancy futuristic spreadsheet that was going to
| make Excel obsolete, had failed completely: because it was
| great at calculations, but terrible at creating tables, and
| everyone was using Excel for tables, not calculations._
|
| ... so he went on and created Trello.
|
| https://www.joelonsoftware.com/2012/01/06/how-trello-is-
| diff...
| lo_fye wrote:
| Yes, but many of them care about different twenty-percentses, so
| you probably still need the whole thing to keep the number of
| users you currently have.
|
| BUT if you can find a feature that few people use, but which
| requires a lot of maintenance and/or ongoing development time,
| get rid of that bit and enjoy a higher ROI.
| BinaryIgor wrote:
| That's why is so crucial for any great product (or striving to
| be) to have reliable usage metrics - you then have reliable data
| to decide what's worth focusing on and improving and what's not
| so much
| throwmeaway222 wrote:
| 20%? I imagine most of us use 0.1% of Jira. And it's the same
| 0.1% for all users in the org. The app is massive, millions of
| lines of code and we're effectively using like 60 SQL statements
| that run within it.
|
| create issue, edit issue, move issue, update issue status, close
| sprint, repeat
| tuna74 wrote:
| Why don't you use something cheaper then?
| thomastjeffery wrote:
| More interestingly, users care about 20% of each of the other
| applications they are trying to use. Not only is it frustrating
| for them to be bombarded with the 80% of your app they don't care
| about, it's frustrating when they can't easily replace that 80%
| with the other apps they prefer.
|
| The entire premise of an "application" is, in my opinion, a huge
| mistake. Each application, by virtue of being just that, is
| designed to be a silo of functionality and usability. An
| application monopolizes the functionality for the use case it was
| designed to apply to. Not only does an application hold its
| functionality hostage, it insulates itself from the functionality
| of other applications. This creates a brittle system with
| incredible overhead.
|
| There's a reason many of us prefer to use a terminal emulator and
| shell utilities: they are designed with the opposite goal, to
| collaborate with each other as much as possible. That's often
| worth dealing with the ~40 years of cruft that the shell comes
| with, but accessibility could definitely be improved.
| renegat0x0 wrote:
| Whoa. That is 20% more than I thought
| isk517 wrote:
| While hitting 100% utilization will probably never happen in any
| significantly large application, in my experience almost every
| application has a good 10-30% of it that remains unused because
| they are extremely unintuitive to anyone who isn't on the
| development team, has a absolutely awful and inefficient
| workflow, or is so basic that it would only be of value to
| companies that would in no way be able to afford that application
| in the first place.
| sharkjacobs wrote:
| I made a little hobbyist app for myself, and I think it's pretty
| nice and occasionally think about polishing it up and releasing
| it.
|
| And the first reason I don't is because I'm not interested in
| promoting it, and it's pretty pointless to release to no one.
|
| But the much bigger reason is because I'm not interested in
| implementing the remaining 80% that I don't use myself.
| kccqzy wrote:
| I also made several hobbyist apps for myself. Sometimes I
| thought what if I just posted it as a Show HN, but I am just
| rarely in the mood for implementing features others ask for,
| outside of work which pays me enough that I'd oblige.
| conductr wrote:
| It's been 25 years now but this exact thing is why I switched
| majors away from CS in college, I decided back then that I
| didn't want an employer/client telling me what to build. I
| liked software as a hobby but think it would have been a
| miserable profession (for me, not projecting to anyone else).
| lomase wrote:
| I made one plugin for myself and released open source in
| github. The amount of, sometimes hostile, request I had to
| implement stuff I did not care made me stop the development.
| SoftTalker wrote:
| Just tell them you'll be happy to consider including their
| patch to provide the missing features, or f-off. I've used a
| lot of open-source code which up-front says that issues
| requesting new features will be closed.
| SoftTalker wrote:
| If you're not releasing it as a product for sale, there's
| absolutely no obligation to promote it, or add any features
| that you don't use. People can use it as-is if it fulfills a
| need, or fork it and add what they think is missing.
| hatthew wrote:
| I made a random 30-line bash script that filled a small but
| critical niche (reimplementing an existing semi-niche tool to
| work with ipv6). I am bad at bash, but I put it on GitHub
| anyways, with a descriptive name.
|
| Occasionally I check in on it, and see it's still getting
| pageviews, clones, and sometimes forks. A few people raised
| issues about something beyond the 20% I built, and I say "go do
| it yourself", and then they do but at least they didn't need to
| start from scratch.
| einpoklum wrote:
| "Your application"? That post talks about Microsoft Office.
| That's the giant corporation + the government's application. Give
| LibreOffice as an example if you want to talk about large apps
| that can be "yours", at least partially.
|
| And indeed, we should make sure the apps we write are FOSS, so
| that those users who care about those various 20%'s feel that its
| also "their application", and may actually help out - with money
| or code or time.
| g42gregory wrote:
| Correct, but each may be using different 20%.
|
| In the enterprise software (think ERP), each user may be using
| only 0.01% of the overall functionality. And the entire company
| maybe using only 1% of the functionality.
| hermitcrab wrote:
| >You can't predict exactly which 20% each user will need, but you
| can build systems that let them find and enhance their own slice.
|
| If your users are programmers, engineers or scientists, fine.
|
| If your users are not the above, fuhgeddaboudit. You will end up
| in support hell.
| a4isms wrote:
| Back in the days when desktop applications were the thing, I
| recall a (probably apocryphal) claim that nobody used more than
| 5% of Microsoft Office, but no two users used the same 5%.
|
| So it always appeared to be bloated with features nobody ever
| used, but actually somebody, somewhere, was using every one of
| the features. I doubt the number was actually 5% or that usage of
| features was close to even, but the principal idea seems
| reasonable. Different users use different subsets of a product.
| imoverclocked wrote:
| Debian popcon is an interesting way to judge usage IMO. Of
| course, not all environments are amenable to sharing usage data
| but it would be an interesting clause to include in a software
| license.
|
| "Without usage data, we can not guarantee that all features
| will remain in the software."
| nextworddev wrote:
| Yes but you still need those useless features to sell
| listenallyall wrote:
| new | threads | past | comments | ask | show | jobs | submit
|
| I only use one of these links regularly, another one
| occasionally, and the others, if I happen to press it, it was
| probably a misclick. So about 20% seems like a good
| approximation.
___________________________________________________________________
(page generated 2025-09-29 23:00 UTC)