My pet theory of how great software gets started
hiandrewquinn.github.io
hiandrewquinn.github.io
I only say that to say: I think the actual conclusion I'd draw from the idea this post puts forward is, well, two things: First, that the best software is software built by its biggest and most zealous users; software built for other people exclusively is never, never good. Second, that the best software has features no one is asking for, the "I've got a feeling we'll want to be able to sort on that table" kind of features, some people would call this quality Good Taste.
The process which produces most software the world uses seems almost intentionally designed to throw both those conclusions to the curb. That, to me, explains almost all of why software quality has nosde-dived over the past 10 years. Its the old story about how the designers and product managers on the Windows team at Microsoft all use Macs.
Scrum?
I read this more as purely data-driven product decisions, or three years of UX research before we get building, those sorts of approaches.
I'm more-so referencing e.g. Amazonian Data-Driven Decision Making. That the nature of this kind of process puts taste behind data, even erroneous interpretations of data or incomplete data, data is data and data is king; organizations quickly lose any sense of taste they may have had as decision making is predominated by data analysis. This process looks down on someone finding data to support a conclusion they want to reach, but in reality this is the only way to build great software: Starting with good taste, and supporting that taste with data, metrics, and experimentation. Cherry-picking is fantastic; instead we larp scientists.
To a similar degree, I'm also referencing over-specialization in enterprise companies. The classic Office Space bit: "We don't let the engineers talk to customers". Computers give us an effectively-infinite second-brain and effectively-infinite automation capability, if used correctly. This idea that we need a multi-disciplinary team of a dozen people to build anything, each person holding one small piece of the puzzle like a precious gem, is antiquated; it predictably leads to the vast, vast majority of all billable person-hours being spent on self-inflicted problems and context transfer. At minimum, many extremely successful companies organize themselves around multi-disciplinary individuals & vertical teams, instead of specialized individuals and horizontal teams; this is great. But, as we live through the birth of AI rather quickly gaining many of the capabilities of these specialized individuals, I think we'll inevitably see the most profitable and productive companies and teams get smaller and smaller.
Many things in life seem to work optimally when we take them with an "ebb-and-flow" style pattern. For example, I'm a fan of seasons of feast and seasons of famine when it comes to trying out new software: In seasons of feast, I throw caution to the wind and try anything new and shiny which looks appealing to me, and then in seasons of famine, I prune, prune, prune away anything which doesn't directly serve my purpose.
There's a similar ebb and flow here. The largest community is very "means to an end" oriented. The power users often view the tool as a thing of beauty in itself, at least for a little while. That's the "end in itself" ebb. The hackers transcend this and view the tool as an imperfect, vexing beauty, and wish to create something even more beautiful -- but that's where things wrap back around, because the beauty does ultimately come from how well it is suited as a means to the end!
Let me start to plug that hole now. The concrete example I was thinking of while writing this was Bram Moolenaar's `vim` (RIP). I'm pretty sure most people would argue `vim` is great software in at least some abstract sense, even if they are ride-or-die for Emacs or Kakoune or some such.
Plenty of `vi` clones already existed by the time Bram started work on `vim` in '91. That gives us the community, scene, subscene layering I suggest. The pool of text editor users is massive worldwide; text editor power users are smaller in number but still quite large; and text editor creators are smaller still but tend to be very enthusiastic about their craft. How do we know Bram was a member of all 3 groups? Well, he has a page literally titled "Seven habits of effective text editing" [1], which isn't even really specific to Vim -- it just outlines the beliefs that have crystallized for him over a long, long lifetime of editing text really, really well.
It also means that `vim` did not spring fully formed from the forehead of Bram. There was a whole litany of iterations going on at the time which he could tap into, previous riffs on the genre that were successful, but could have been even moreso.
Other software I would put in this camp might be: Linux, Obsidian, Podman, Kubernetes (kinda - you really have to run into all of those SRE problems individually before you can arrive at a design like k8s, and even then there are things most people agree could be improved upon). They all have this iterative pattern to them, kind of like dogfooding to the max.
One problem is there is no one definition of “great”. I really like using bash on the command line and for simple scripts. I really like Powerpoint for making decks with elaborate visuals. I hesitate to say they have anything in common.
Bash and Powerpoint both seem approachable at first. It's easy to get started and have something to show for your time. Both also completely suck at anything complicated.
Sure, nobody agrees on what the strict definition of great is. I don't think it's reasonable to argue that a blog post titled "My pet theory..." doesn't achieve the minimum word count.
Go back and read the HN thread [1] that was the impetus. Now TFA exists within a lot more words to train an LLM on.
Why not attempt to triangulate what this particular piece of software might look like, if it was the best it could be?
While insufficient, the major point here I think is essentially correct. Or at least the converse/inverse, one of those words is: Which is: No great software is made without someone having a lot of love somewhere in the beginning.
Taylor Otwell, Laravel framework creator, is still the only person merging all PRs (4771 as of now).
He became rich and still does it every single day.
Like the article stated, for him, it's probably no longer just a means to an end, but an end in itself.