Good software knows when to stop

>Ignore feature requests — don't build what users ask for; understand the underlying problem instead

not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game).

for years and years, the reply from blizzard was "you think you want that, but you dont. trust us, you dont want that."

they eventually caved and launched classic WoW to overwhelming success. some time later, in an interview, ion hazzikostas (the game director) and holly longdale (vice president & executive producer), admitted that they got WoW classic very wrong and that the people "really did know what they want".

anyways, point being that sometimes the person putting in the feature request knows exactly what they want and they have a good idea. while your default mode might be (and perhaps should be) to ignore feature requests, it is worth recognizing that you may be doing so at your own loss. after all, you might not not be able to fully understand every underlying problem of every user of your product -- but you might understand how to code the feature that they asked for.

At first glance, the thread title made me think this was going to be about the halting problem.

We should normalize "finished" software products that stop feature creep and focus strictly on bug fixes and security updates.

It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand.

Evernote and Dropbox were perfect in 2012. Adding more features just to chase new user growth often comes at the expense of confusing the existing user base. Not good

In 2020 I became a full time Java developer, coming from a infrastructure role where I kind of dealt with Java code, but always as artifacts I managed in application servers and whatnot.

So when I first started dealing with the actual code, it scared me that the standard json library was basically in maintenance mode for some years back then. The standard unit test framework and lot of other key pieces too.

I interpreted that as “Java is dying”. But 6 years later I understand: they were are feature complete. And fast as hell, and god knows how many corner cases covered. They were in problem-solved, 1-in-a-billion-edge-cases-covered feature complete state.

Not abandoned or neglected, patches are incorpored in days or hours. Just… stable.

All is quiet now, they are used by millions, but remain stable. Not perfect, but their defects dependable by many. Their known bugs now features.

But it seems that no one truly want that. We want the shiny things. We wrote the same frameworks in Java, then python the go then node the JavaScript the typescript.

There must be something inherently human about changing and rewriting things.

There is indeed change in the Java ecosystem, but people just choose another name and move on. JUnit, the battle tested unit testing framework, had a lot to learn from new ways of doing, like pytest. Instead of perturbing the stableness, they just choose another name, JUnit5 and moved on.

I think Signal (the messenger) is an interesting example: by being free, open source, and privacy centered, there's automatically no room for ads and it's difficult to monetize. Also they have to be very careful adding new features for security reasons.

The result: very few features. Which is exactly what I want.

This is why I love Sublime Text. It's so fast, it works so well. It isn't trying to be AI, it isn't trying to evolve until it can read email or issue SSL certs via ACME. It's focused on one thing and it does it extremely, extremely well.

The hardest part of building software isn't adding features, it's having the discipline to leave something alone when it works. There's a real gravitational pull toward "just one more thing" because every feature request feels like a missed opportunity.

But I've noticed the products I actually keep coming back to are the ones that feel opinionated. They decided what they were and stuck with it. The ones that try to be everything usually end up being mediocre at all of it.

The WoW comparison in this thread is apt. The early expansions had clear identities. The later ones kept bolting on systems until playing felt like managing a spreadsheet.

I think notepad.exe is the strongest example of this right now.

The amount of hacking required to even be allowed to re-associate text files with that particular exe on Win11 was shocking to me. I get that windows is extremely hostile to its users as a general policy, but this one felt extra special.

Definitely that, a finite scope is good and finished software is beautiful.

But also, most of the modern software is in what I call "eternal beta". The assumption that your users always have an internet connection creates a perverse incentive structure where "you can always ship an update", and in most cases there's one singular stream of updates so new features (that no one asked for btw) and bug fixes can't be decoupled. In case of web services like YouTube you don't get to choose the version you use at all.

Also from 37signals, somewhere in their first book they talked about the importance of 'evergreen' things people always want, things like 'the speed of software'. As a junior dev I didn't really get the point or thought it was not that important. I browsed further in the book looking for other gems of wisdom, and this 'speed'-thing only stuck in my head for the wrong reason, thinking it was a little obvious for such clear writers with a solid vision.

Only 15 years later - now a couple of years back - I started to realize the importance of this. The apps on my smartphones seemed to get slower and slower by the year. The fast software experiences were a real joy amidst slow apps. I now have an appreciation for their opinion on 'evergreen' things like the speed of software.

Yeah, I've written about this before on this site. Incentives in software licensing have gotten really stupid since the Internet (and more importantly, since the typical user's bandwidth has increased enough to allow all software installation to happen totally online). Now, too many pieces of software are a revenue-extraction optimization problem instead of attempting to serve a space or solve a specific problem.

There are great exceptions to this rule, even in paid software, where the authors are significantly poorer in exchange for producing better software. I imagine the authors of BeyondCompare or Magnet (for example) could have done a lot better financially for a while using a recurring license model.

There are also really stupid applications of this rule, such as what has happened with AutoMapper and MediatR in the last year or so, where the only meaningful commits since going commercial are the bits that check your license and try to fool you into paying :/

It seems like this shouldn't be a problem. It often only takes one developer willing to make a sacrifice to make a particular class of software available that actually attempts to solve the problem and nothing more. But in reality what we see is over time those developers that did make a stand start to look out for themselves (which I have no problem with) and try to take what they can while they have market share.

How do we find a way to live in a world where developers can build useful things and be rewarded for it while also preventing every piece of software from turning into shit? I'm not sure what the answer is.

The more stars my personal GitHub repos have, the more likely the project was something I cranked out over a weekend to scratch an itch, and then more or less abandoned because it was good enough -- maybe even perfect for that specific itch?

The hardest engineering skill I've developed is knowing when to stop optimizing. There's always another microsecond to shave, another edge case to handle, another abstraction to introduce.

The best codebases I've worked with share a common trait: they have clear boundaries about what they don't do. The worst ones try to be everything and end up being nothing well.

This applies doubly to developer tools. The ones that survive decades (Make, grep, curl) do one thing and compose well. The ones that try to be platforms tend to collapse under their own weight.

I built a spotify music extractor called harmoni that helps you download your playlists and I feel I'm done. It does its job and it caters to both non-technicals and technical people alike.

This is an article Microsoft Windows, Office, Outlook and MS Teams developers and product managers should read, they continually break the working software only to come back regularly to what they have invented already, in the meantime annoying many who had to experience the experiments in between…

This resonates with AI coding tools. Claude Code doesn't know when to stop —it'll do 30 agentic loops for something that should have taken 3. The cost implications of a tool that doesn't know when it's done are brutal.

Stardew Valley is a great example of this, and that more is not always better.

Specifically he rolled out a "cave" system with procedural dungeon generation where players could mine through walls and other advanced systems, then undid all of it and ended with ~30 static layouts and very simplistic interactions. The entire game feels like a demonstration that simple, predictable and repeatable interactions with software have more longevity than cutting edge dynamic systems.

It's not about software, it's about money. They're chasing what they see making money and being mimetic. Simple as. It's a shame and sad to see so many get caught up in this, but it makes sense relative to where the world is at. People are desperate and this is what desperation manifest looks like.

We need something similar to the Svalbard Global Seed Vault, to protect un-AI'd Linux distributions so that, in the event of an AI apocalypse, we will have access to clean operating systems.

Don't forget the lifetime support subscription you bought for "ls" 2 years ago. It turns out the lifetime is for the lifetime of the software, not your lifetime.

Coreutils gets updates regularly! https://gitweb.git.savannah.gnu.org/gitweb/?p=coreutils.git

Even `ls` gets news flags from time to time.

I think "stopping" is great for software that people want to be stable (like `ls`) but lots of software (web frameworks, SaaS) people start using specifically because they want a stream of updates and they want their software to get better over time.

Maybe good software is like a living thing?

It grows and grows and eventually slows or grows too much and dies (cancer), but kinda sheds its top-heavy structure as its regrown anew from the best parts that survived the balanced cancer of growth?

Just forks and forks and restarts. It's not the individual piece of softwares job (or its community's) to manage growing in the larger sense, just to eventually leave and pass on its best parts to the next thing

> `als` doesn't just show files.

> It predicts which ones you meant.

> It ranks them.

> It understands you.

This is so good I want to know whether someone generated this or wrote it by hand.

"Good software knows when to stop, look at ls!"

ls: usage: ls [-@ABCFGHILOPRSTUWXabcdefghiklmnopqrstuvwxy1%,] [--color=when] [-D format] [file ...]

I don't think it knew when to stop.

Yeah, but if you vertically integrate you expand your target market, increase switching costs, and can charge rents, so everyone is trying to do it now.

"know the role and place your software fits in" yes! Probably one of the most important lessons of my career. As a junior dev starting out, I had no idea how my software fit into the company's product let alone into the entire ecosystem of what was already available and open source. Now as a senior, I see juniors making the same mistake that naturally arises out of this: needlessly doing things that have already been done or re-inventing the wheel. And now that coding ability is a cheap commodity, product development, and knowing where you fit into the ecosystem becomes the main skillset.

It's the wonderful part about OSS and 'mission-driven' projects. If the mission is not to make money, then a project is free to reject addons/etc that might be lucrative but not add value to the core of the product

I like the fictional way the article starts!

When chatGPT first gained traction I imagined a future where I'm writing code using an agent, but spending most of my time trying to convince it that the code I want to write is indeed moral and not doing anything that's forbidden by it's creators.

if I ran an OS upgrade and was greeted by something like this I'd immediately be swapping OS.

"To order, to govern,

is to begin naming;

when names proliferate

it’s time to stop.

If you know when to stop

you’re in no danger."

> Good software knows the purpose it serves, it does not try to do everything, it knows when to stop and what to improve.

agree with this point. new developers should care about this.

Just like all organizations are naturally self-expanding and self-perpetuating. Same with all organizations building software. The natural pressure is to expand. It is hard to resist it.

Oracle Database has now been renamed Oracle AI Database. But I think that in time, they will rename it back to Oracle Database. The hype will pass, but the AI will remain, and the name will no longer need to include the AI prefix. AI will just become the norm.

> ready to upgrade your favorite Linux distribution and packages to their latest versions

It is "their" distribution, to do with as they wish. If this would happen to your workstation, you are a fool, for not following release notes.

I already jumped distros for several reasons, marketing BS was one of them. I do not need latest scam or flag of the month!

I notice at this time there are no comments about systemd. I figured there would be at least one comment about it and "it does not try to do everything".

als: both fitting and terrifying name for that new utility...

Good software doesn't get you VC funding.

Link this to the Spotify product developers

I agree with this basically 100%.

> Say no by default — every feature has a hidden cost: complexity, maintenance, edge cases

AI-assisted development is blowing up this long-standing axiom in the software development world, and I am afraid it's a terrible thing.

Just because you can do something, doesn't mean you should.

No, all software grows until it gets email. Jamie told me that.

So uhm where can I get the 'als' command then? :P

Really at this point we should stop making software as we know it, but create minimal tools that an LLM can use.