Most engimeering decisioms aren't made my engineers. Many times, the goalpost keeps moving while the deadline stays the same.

The end result is cutting corners and perfection is never even a thought.

I always thought of that as “yak-shaving,” or “bikeshedding.”

Quality takes longer. Sometimes, significantly longer, for many reasons. That’s why something top-shelf, costs so much more than commodity, when it doesn’t seem to have much more, in the way of features.

Many orgs aren’t interested in spending that much extra time on it (which is their prerogative). The customer base tends to be smaller, and a lot more fickle. It’s really difficult to make a living, doing top-Quality work.

Source: I worked for many years, for a company known for top-shelf stuff. I’m quite familiar with Quality as an everyday feature.

You're saying it in jest but this is closer to the right answer. Features make you money. A large enough project has an infinite backlog. You will be unlikely to make much money from clearing out your backlog.

The expression is “the enemy of good” not “the enemy if something” so in the end it’s about defining “good”. It varies with context. What’s good, move fast and break things or go slow and considerate? Is risking bugs worth it to launch a feature? How important is that feature? How important is it to have it now vs. later? And how do you reconcile it when what’s good for you is bad for me?

I was one of those initiators of a rewrite. And I was facing a real problem: the codebase was in C, all C developers except me left, I was going to leave too, and both our HR department and an external consulting firm failed to find a competent C developer to replace me.

So I said: screw performance, we are rewriting this thing into Go, as that's what our existing developers were willing to work with - with the intention of leaving when this would be done.

And the day I finally submitted my resignation letter, a competent C developer was found, and later I heard that the Go rewrite was scrapped.

> I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software and never releases

Oh, I have. A LOT! In my friend group theres at least 5 of these right now. They work day jobs (that they dislike), they try to build a side hustle but never get it off the ground because they endlessly rewrite perfectly serviceable software and never release, the reason is:

- they believe that running a startup only requires writing a good product

- they avoid releasing because thats "judgement day" and might flop

- they think if they code it "just right" a money Waterfall will open up magically like a lottery ticket win and be instant success

- they believe that because theres the occasional exception to these rules above, it will happen to them too (everyone thinks they are the special exception,) because thats easier than accepting building a successful business takes discipline, hard work, and doing the tasks you dont want to do.

You havent come across them because by definition they never release and they dont share (they are embarrassed it might fail) so theres thousands and thousands of them, grinding away under false assumptions. They enjoy the act of building (which is totally cool!) but think thats all there is to it. Convinced that just one more rewrite is the thing holding them back from success - because they'd rather rewrite than talk to users. Millions of people doing this, millions of dreams that will die, because /just one more rewrite/

Just because you havent seen them, doesnt mean they aren't there

I'm that perfectionist and it is constantly preventing me from shipping. Basically everything I'm working on requires me to cut losses at some point because it would take twice or three times as long if done perfectly and there is no guarantee that it is actually perfect in the end.

I don't really feel it collapsing under the weight of unmaintainable spaghetti tech stacks, I'm mostly thinking that writing the missing features of the tech stack would require months of work and hard thinking that in the end might simply get rejected and now I would be stuck maintaining it myself so nothing has changed other than that there are even more things to maintain.

All of this for the sake of clean architecture that seemingly has no impact on users in the end... Like the users complain about completely different things.

The real challenge is reigning in the size and complexity of the codebase if you're using AI to generate it. I have a bunch of skills (YAGNI / KISS inspired) but it still requires a significant amount of human effort. Knocked down about 9000 lines of cruft this month and I know there's another 10k in there sitting around.

What it is to you depends on if you want to sell a screwdriver or if you want to drive a screw.

If you're looking for somebody to design a screwdriver for you, you're better off with the guy who wants to drive a screw.

Products tend to be someone else's tool.

Like you hint at, though, a tool is useful immediately and without end (at a particular task - windows operating systems remain useful despite whatever current version is being sold), the product is often an attempt to continuously derive value from the tool (attach a time limited license, offer "upgrades", new features, etc.).

A service is more like a product than a tool - selling data is not something that a tool can (by itself) provide (unless you accept virtual or test data).

Attaching a product mindset to a tool then becomes a matter of complication/value reduction, vs a product mindset to a consumable, like a game, or dataset, where the value is at least constant, if not growing over time.

I.e., I'm not sure I agree that the "enshittification cycle" is the variable here - even in the age of AI the value e.g. of a stock image service is constant or growing, even if the LLM generation process dilutes the market.

When I think of software that is minimally tainted by productism, these come to mind:

- linux

- nix

- nushell

- helix

Are these products... at all? Do the open me up to new scams? I don't think so.

I'm not in a position to demand anything from the people who make these things. If they were subject to demands, their craft would be tainted by compromises made in acquiescence to those demands, and I'd probably be less enthusiastic about their software (because presumably, my tastes don't align with whichever others are also in a position to be making demands).

Supply and demand are well and good if what you're after is barley. But when you compare what there's demand for with what's being supplied re: software, there appears to be no correlation.

We gotta stop selling picks and shovels and start learning to be miners who have good taste in picks and shovels and the ability to make and remake our tools as needed. The disconnect is creating a hell for our users.