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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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").
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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)
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.
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)
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.
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)
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.
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.
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.
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.
> 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.
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.
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.
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).
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.
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.
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.
> 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
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.
> 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.
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...
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
> 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?
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.
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!).
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'.
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.
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.
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.
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
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.
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).
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".
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.
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
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.
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.
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
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.
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.
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/20080329042649/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")
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.
> 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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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
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.
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.
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.
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!
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
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
yep, exactly. We implement some parts of that over the years and it's a hog.
>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.
I worked at a place that did it a third way: The CEO had a product vision that changed every month.
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.
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").
Founder mode unlocked
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.
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.
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.
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.
Customers buy features, customers rarely buy polish.
Polish increases customer lifetime value.
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.
I like to call these "windshield wipers." Rarely used yet essential.
>You use it 3 minutes per day.
Damn you must get a lot of fiber.
At least a toilet is fairly standard these days. Not so much with digital only products.
> like a toilet... You use it 3 minutes per day
I think you may need to go see a doctor about that, seriously.
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/
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.
> 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.
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.
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.
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?
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.
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.
Nvidia had a very high gross margin % (for a hardware company) of ~50% way before AI hype. Even before A100.
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.
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.
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.
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.
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.
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.
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.
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.
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)
> 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.
In all fairness, a lot of that was about IE being bundled into the OS and other rather underhanded strategies employed by MS.
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)
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.
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)
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.
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/
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.
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...
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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).
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.
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.
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.
> But they don't necessarily care about the same 20%.
That’s kind of the article’s main point.
> But they don't necessarily care about the same 20%.
Did you write that entire comment based on the headline only?
> 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
When it comes to Kagi, it just needs to be the old Google. Something that new Google abandoned.
Yes, search as it was before enshittification.
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.
> 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.
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...
Oh yes, the memories! [Pun not intended] Mine is 880k. Boy, did I squeeze the last bytes out of that Workbench boot floppy!
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.
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.
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.
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.
>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.
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.
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".
I almost commented the same, but I think the tricky bit is that it still holds: users only care about 20% of vi, etc.
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
Why don't you use something cheaper then?
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.
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.
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.
> 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?
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.
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!).
I suppose the core of emacs is pretty minimal but in practice the number of packages that it includes by default is pretty large.
I like to call this approach MISS (MISS – Make It Stupid, Simple) or better:
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/
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.
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.
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.
Pluralism, huh. I suppose this applies to games, too, the different ways people enjoy the same game.
“ your software will be used in ways you never imagined.”
This is actually a lot of fun to discover.
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
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.
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).
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".
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.
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.
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
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(!).
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.
They had the week long delays before this switch :D - now they just found a good excuse
> 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
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.
Maybe dont employ these people in positions that require a specific way of thinking then...
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.
Until... you change the software.
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/20080329042649/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/20080316101025/http://blogs.msdn... and there's a presentation, too: https://www.youtube.com/watch?v=AHiNeUTgGkk
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.
> 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.
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.
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.
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.
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.
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
Whoa. That is 20% more than I thought
"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.
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.
It's against the rules to say this, but it would definitely help to actually read the article.
Ok
This should really credit Joel Spolsky somewhere: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
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.
That's fine, I care about 0% of my users.
why though
Yes but not all users care about the same 20%.
Tell me you didn't read the article without telling me you didn't read the article.
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.
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.
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
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.
Users dont care about 1% of my application, lets be real.
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.
For different users it can be a different 20%
That’s the thesis of the article. Hard to miss even when skimming, as it’s in very large letters near the top.
Not sure if you read the article, but that's exactly its main point!
80% of HN users read only 20% of the article before writing their comment.
What percentage of an app do power users care about?
15
i'll downvote this comment too
Why?
He doesn't even have enough karma to downvote
yeah, then who downvoted you both?
Plot twist: but it's sometimes a different 20%.
Uh, did you open the link at all?
He used 20% of HN.
Less than 20% of commenters do.
downvoted, bro