4 ms·

I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and of

I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've got goals which are independent of the user's goals (typically to make money, which sometimes means doing something dastardly to the users on behalf of the shareholders). All the best software is more in the "tool" category and less in the "product" category. Usually it's made by the users, only bothers with solving problems they have, and has no ulterior motives.

mtweak 3mo ago
I'm also wondering if "perfect" and "good enough" are not really as important now vs. when a team of software engineers had to spend sprints implementing features. The rate of iteration is faster now, the rate of regenerating entire code bases is days. We can perhaps over engineer /more/ today than before.
- jaggederest 3mo ago
  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.
  - gjvc 3mo ago
    "reining"
sublinear 3mo ago
You've definitely used non-toxic and thoughtful products or you wouldn't be making such a distinction. You are throwing the baby out with the bathwater by retreating to "tools". If you want to stop the enshittification, this is not the way. You're just opening yourself up to new scams. i.e. AI tools, political agendas, etc. Better products are just better. Demand them.
- __MatrixMan__ 3mo ago
  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.
dasil003 3mo ago
I get what you mean about the conflict of interest for consumer software, but I don’t think a product mindset is inherently toxic. It’s more a function of where you are in the enshittification cycle.
- smaudet 3mo ago
  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.
  - __MatrixMan__ 3mo ago
    > Products tend to be someone else's tool I like this. The question is really whether you're facing the "business end of the stick" or not (although stick isn't quite right here, because not all software has both ends).
axus 3mo ago
Let's not make fixing bugs and backwards compatibility the enemy of shoveling out more features
- close04 3mo ago
  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?
  - moritzwarhier 3mo ago
    It's just the same about the definition of "perfect". Fixing critical bugs is not perfectionism. Fixing low-impact bugs by making high-risk, well-intentioned changes might be.
  - deleted 3mo ago
    [deleted]
- Daishiman 3mo ago
  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.
  - pdimitar 3mo ago
    As a guy who was a part of projects with an infinitely growing backlog (multiple times), I can tell you for certain that _not_ periodically addressing parts of your backlog absolutely will stop you from making more money; even lose you some due to customer churn.
    - Daishiman 3mo ago
      I am as close to a fan of a clear backlog as it can be, but I would also say that an insufficiently deep backlog is probably a sign that you're spending too much on refactors and cleanups.
stouset 3mo ago
The number of times I've heard that phrase used to justify shipping absolute crap utterly dwarfs the times it's been used to prevent over-engineering something that's already in a good state. In a thirty year career of software engineering, 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 it. I have, however, worked at multiple companies that have collapsed under the weight of their unmaintainable spaghetti tech stacks.
- malux85 3mo ago
  > 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
  - ryandrake 3mo ago
    I'm just like that, but minus the expectation of release/money/success. To me, the building and programming itself is the reward, and I have no motivation or desire to release anything I work on--or any belief that it would/should make money for me. To me, the hours spent fine sanding down and polishing my code, always approaching but never achieving perfection, is its own reward.
bch 3mo ago
> “let's not make perfect the enemy of good." Nuanced, but I’ve heard “don’t let perfection be the enemy of completion”, which is real in the cases of not shipping because one is constantly polishing/perfecting, or, as I heard sitting beside phk[0] at BSDCan commenting on rejecting some environmental sensors into FreeBSD, something to the effect of “We need ‘good’, not ‘good enough’.”, which draws a line at accepting janky “solutions” that are architecturally weak, or otherwise look obviously problematic. [0] https://people.freebsd.org/~phk/ https://people.freebsd.org/~phk/
- ChrisMarshallNY 3mo ago
  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.
  - bch 3mo ago
    I love the social/cultural aspects of our engineering discipline. > I always thought of that as “yak-shaving,” or “bikeshedding.” I think of yak-shaving as ending up (by lack of discipline, or perhaps out of necessity) working on some supporting aspect of a supporting aspect of a supporting aspect... in service of the original task. So, a potential time suck, for sure, but "perfection is the enemy of completion" doesn't have to be that deep - if we're throwing out more clever phrases and war stories - another phrase that comes to mind about just "polishing" and insisting it's not good enough to ship yet is it's (slightly NSFW) "just like masturbation - it feels good, but you're only f*cking yourself". You need to ship. Bike Shedding I think of as social - nearly Peter Principle in practice - everybody thinks they've got something to contribute to the construction of the bike shed because it's a thing that's easy to manage, and people want to be helpful and/or make a mark.
socketcluster 3mo ago
Yes, agreed, that quote is not as relevant to software development. Some would make the case that software isn't good unless it's perfect. Engineers will use the word 'correct' (e.g. correctness); and by that, they mean; is it perfect... And it's not wrong to demand it because the smallest gap can be a critical security vulnerability.
BloodyIron 3mo ago
So is a screwdriver a tool or a product? I think you're getting caught up on nomenclature and limited sample sizes.
- __MatrixMan__ 3mo ago
  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.
  - BloodyIron 3mo ago
    Well I sell various IT systems as products. For example, turnkey TrueNAS systems that were built on refurbished hardware that I/my business personally validated for reliability, and various other metrics. We don't make the hardware, nor the software, but we combine them, validate it does what is expected, and from my perspective that's fair to consider it a "product". How does that line up for you?
lazyasciiart 3mo ago
That’s a nice thought, but who are the users who plan to write their own air traffic control tool?
KaiserPro 3mo ago
Its about pragmatism. The problem is that a lot of software engineering tends to be not about building a product to service the buisness need. Lets be honest, a lot of the time engineering decisions are made because "it would be cool to use x" rather than "this is the fastest path to achieving business goal z" "over engineering" in a lot of cases is just either engineering gate keeping "oh you don't know how to do x properly, its soooooo much more 'performant' than y" or design by CV "lets use kafka, k8s, mobile app, AI, RAG" etc etc etc. in 99% of cases, the architecture really doesn't matter that much, you product is never going to need what ever fancy system you put in. Mainly because people over estimate scale. The thing that matters is that the customer is able to use it, and know how to use it. Everything else is almost irrelevant.
- elmer2 3mo ago
  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.
- pdimitar 3mo ago
  Popular view to dunk on meaningless perfectionists, sure, but your comment conveniently does not address "let's have this architecture because we know these new requirements are coming and we know we can't accommodate them with the current one". Arguing extremes is easy.

mtweak 3mo ago

I'm also wondering if "perfect" and "good enough" are not really as important now vs. when a team of software engineers had to spend sprints implementing features. The rate of iteration is faster now, the rate of regenerating entire code bases is days. We can perhaps over engineer /more/ today than before.

jaggederest 3mo ago
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.
- gjvc 3mo ago
  "reining"

sublinear 3mo ago

You've definitely used non-toxic and thoughtful products or you wouldn't be making such a distinction. You are throwing the baby out with the bathwater by retreating to "tools". If you want to stop the enshittification, this is not the way. You're just opening yourself up to new scams. i.e. AI tools, political agendas, etc. Better products are just better. Demand them.

__MatrixMan__ 3mo ago
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.

dasil003 3mo ago

I get what you mean about the conflict of interest for consumer software, but I don’t think a product mindset is inherently toxic. It’s more a function of where you are in the enshittification cycle.

smaudet 3mo ago
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.
- __MatrixMan__ 3mo ago
  > Products tend to be someone else's tool I like this. The question is really whether you're facing the "business end of the stick" or not (although stick isn't quite right here, because not all software has both ends).

axus 3mo ago

Let's not make fixing bugs and backwards compatibility the enemy of shoveling out more features

close04 3mo ago
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?
- moritzwarhier 3mo ago
  It's just the same about the definition of "perfect". Fixing critical bugs is not perfectionism. Fixing low-impact bugs by making high-risk, well-intentioned changes might be.
- deleted 3mo ago
  [deleted]
Daishiman 3mo ago
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.
- pdimitar 3mo ago
  As a guy who was a part of projects with an infinitely growing backlog (multiple times), I can tell you for certain that _not_ periodically addressing parts of your backlog absolutely will stop you from making more money; even lose you some due to customer churn.
  - Daishiman 3mo ago
    I am as close to a fan of a clear backlog as it can be, but I would also say that an insufficiently deep backlog is probably a sign that you're spending too much on refactors and cleanups.

stouset 3mo ago

The number of times I've heard that phrase used to justify shipping absolute crap utterly dwarfs the times it's been used to prevent over-engineering something that's already in a good state. In a thirty year career of software engineering, 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 it. I have, however, worked at multiple companies that have collapsed under the weight of their unmaintainable spaghetti tech stacks.

malux85 3mo ago
> 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
- ryandrake 3mo ago
  I'm just like that, but minus the expectation of release/money/success. To me, the building and programming itself is the reward, and I have no motivation or desire to release anything I work on--or any belief that it would/should make money for me. To me, the hours spent fine sanding down and polishing my code, always approaching but never achieving perfection, is its own reward.

bch 3mo ago

> “let's not make perfect the enemy of good." Nuanced, but I’ve heard “don’t let perfection be the enemy of completion”, which is real in the cases of not shipping because one is constantly polishing/perfecting, or, as I heard sitting beside phk[0] at BSDCan commenting on rejecting some environmental sensors into FreeBSD, something to the effect of “We need ‘good’, not ‘good enough’.”, which draws a line at accepting janky “solutions” that are architecturally weak, or otherwise look obviously problematic. [0] https://people.freebsd.org/~phk/ https://people.freebsd.org/~phk/

ChrisMarshallNY 3mo ago
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.
- bch 3mo ago
  I love the social/cultural aspects of our engineering discipline. > I always thought of that as “yak-shaving,” or “bikeshedding.” I think of yak-shaving as ending up (by lack of discipline, or perhaps out of necessity) working on some supporting aspect of a supporting aspect of a supporting aspect... in service of the original task. So, a potential time suck, for sure, but "perfection is the enemy of completion" doesn't have to be that deep - if we're throwing out more clever phrases and war stories - another phrase that comes to mind about just "polishing" and insisting it's not good enough to ship yet is it's (slightly NSFW) "just like masturbation - it feels good, but you're only f*cking yourself". You need to ship. Bike Shedding I think of as social - nearly Peter Principle in practice - everybody thinks they've got something to contribute to the construction of the bike shed because it's a thing that's easy to manage, and people want to be helpful and/or make a mark.

socketcluster 3mo ago

Yes, agreed, that quote is not as relevant to software development. Some would make the case that software isn't good unless it's perfect. Engineers will use the word 'correct' (e.g. correctness); and by that, they mean; is it perfect... And it's not wrong to demand it because the smallest gap can be a critical security vulnerability.

BloodyIron 3mo ago

So is a screwdriver a tool or a product? I think you're getting caught up on nomenclature and limited sample sizes.

__MatrixMan__ 3mo ago
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.
- BloodyIron 3mo ago
  Well I sell various IT systems as products. For example, turnkey TrueNAS systems that were built on refurbished hardware that I/my business personally validated for reliability, and various other metrics. We don't make the hardware, nor the software, but we combine them, validate it does what is expected, and from my perspective that's fair to consider it a "product". How does that line up for you?

lazyasciiart 3mo ago

That’s a nice thought, but who are the users who plan to write their own air traffic control tool?

KaiserPro 3mo ago

Its about pragmatism. The problem is that a lot of software engineering tends to be not about building a product to service the buisness need. Lets be honest, a lot of the time engineering decisions are made because "it would be cool to use x" rather than "this is the fastest path to achieving business goal z" "over engineering" in a lot of cases is just either engineering gate keeping "oh you don't know how to do x properly, its soooooo much more 'performant' than y" or design by CV "lets use kafka, k8s, mobile app, AI, RAG" etc etc etc. in 99% of cases, the architecture really doesn't matter that much, you product is never going to need what ever fancy system you put in. Mainly because people over estimate scale. The thing that matters is that the customer is able to use it, and know how to use it. Everything else is almost irrelevant.

elmer2 3mo ago
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.
pdimitar 3mo ago
Popular view to dunk on meaningless perfectionists, sure, but your comment conveniently does not address "let's have this architecture because we know these new requirements are coming and we know we can't accommodate them with the current one". Arguing extremes is easy.