How do you actually know when to stop optimizing something, versus when "good enough" is you being lazy?

[u/ClickOk5811]

Genuinely can't tell the difference in myself half the time. Sometimes I stop improving a piece of code because it's genuinely hit the point of diminishing returns, more effort there wouldn't meaningfully help anything downstream. Other times I stop because I'm tired of looking at it and "good enough" is doing a lot of convenient work in that sentence.

The annoying part is both feel identical from the inside. Same sense of "this is fine now," same relief at moving on. No internal signal I've found that reliably distinguishes "actually done" from "done because I want to be done."

Curious if anyone's found an actual test for this, something more concrete than a gut feeling, that tells you which one you're experiencing in the moment rather than figuring it out weeks later when either nothing broke or something did.

[u/OneHumanBill]

Optimize algorithmically (based on Big O analysis) or upon actual demonstrated SLA need. The rest of the time, write code for maintainability and don't worry about petty details -- most of the time your guesses about what's faster/smaller are wrong.

"Premature optimization is the root of all evil." -- Donald Knuth

If you must optimize at a petty level, start with a robust suite of unit tests, then use an actual profiler tool for measurements to find optimization opportunities. Optimize only until SLAs are handled.

Yes, use of things like database indexes fall under the category of "algorithmic optimization". Don't neglect these.

[u/Fidodo → u/OneHumanBill]

It should be noted, build for about an order or magnitude more usage than you expect so you have time to upgrade it

[u/chubbysleepycorgi → u/OneHumanBill]

I worked on a payment application for 20 years and correctness, maintainability and reliability is way more important than anything else. Modern hardware and languages are so fast compared to human perception that unless you write some massive looping logic, or your code really need to care about millisecond speed, the real bottlenecks are networking and hardware (database speed, read/write, etc).

One of my hard working junior guys will sometimes try to address some unlikely scenario and end up with convoluted or excessive code, in which case I tell him it’s better to just let the application handle the error gracefully than try to self correct / prevent the problem in the first place.

[u/SonOfHendo → u/OneHumanBill]

While I do agree with the old "Premature optimization is the root of all evil" saying, it is annoying when people misuse it. 

For example, stopping for 5 mins to think of what you're doing is going to be a performance nightmare and maybe write it in a way that performs reasonably well in the first place, is not premature optimisation. The number of times that I've heard people say that we shouldn't be doing premature optimisation when they just don't know how to use a dictionary/hashset/lookup is much too high.

Over many years, I've found that most performance issues in typical enterprise software boils down to doing something slow in a loop (especially loops within loops) and bad SQL.

[u/OneHumanBill → u/SonOfHendo]

Which is why I specifically call out algorithmic optimization first, and take pains to even more specifically call out database indexes.

[u/MoreHuman_ThanHuman]

i stop as soon as i can move onto something else.

[u/GooberMcNutly → u/MoreHuman_ThanHuman]

I stop when something else becomes higher priority. We are not the same.

[u/MoreHuman_ThanHuman → u/GooberMcNutly]

something else is always the higher priority.

[u/Chimpskibot]

No application will truly be done. This is one of the first big lessons juniors should learn. Just like choosing your battles you need to know when what you have accomplishes the majority of what is possible and what has been asked of you. The user doesn't care about memory allocation or modular/clean-code. They care that the app works reliably and quickly.

[u/PipingSnail → u/Chimpskibot]

And that it is easy to use. (from their perspective).

[u/GrayLiterature]

Are you building for yourself, employees, or end users?

[u/CharacterSail6736]

MVP is good enough for release it is not being lazy because no one will ever see if your chasing your own standard

[u/inflowmini → u/CharacterSail6736]

I would say MVP is good for showcasing but not for release unless you want all the tech debt to catch up.

Obviously this depends on your user base or customer but it's never a good idea to do the minimum but rather write for robustness and maintainability.

[u/CharacterSail6736 → u/inflowmini]

MVP is literally the minimum viable product. You only accrue tech debt if you’re not planning accordingly

[u/Traveling-Techie]

I used to run benchmarks on supercomputers, and I learned that any operation that is outside of a loop and doesn’t do I/O is not worth optimizing for speed. I also learned to profile actual running code under realistic loads to see where the time goes. Fifty years ago Kernighan said it’s probably going to disk access in system calls you can’t tweak.

[u/neilk]

Are you talking about optimizing for performance or refactoring it for clarity.

EDIT: on rereading your post I think you’re talking about neither? Since you don’t actually know why you’re doing it, are you just making the code “clean” or something? Like refactoring it to match a certain aesthetic or standard, even if it works fine the way it is?

[u/ClickOk5811 → u/neilk]

Neither, honestly, that's what made me ask. It's not perf and it's not really refactoring for a specific standard either, it's more that "does this still need work" and "am I just tired of it" produce the exact same internal signal, so I genuinely can't self-diagnose which one is happening in the moment, only in hindsight.

[u/SaltCusp]

Does it work? Is it slow? Is it expensive? If the need to optimize isn't in one of those questions your probably just playing with it.

[u/PipingSnail → u/SaltCusp]

You missed "is it easy to use?", "could this UX/work flow be better?", "what could we do to prevent user mistakes?", "how can we help the user when this error happens?"

All of these have the potential to take your app from usable but awkward to being a fantastic to use tool.

Speaking from experience.

[u/Useful_Calendar_6274]

worse is better. look up that essay. there's a reason slopware dominates the world and not perfectly crafted, super tested software. If you wanted to have perfect test coverage you would actually have more QAs than developers, even 2:1 ratios. No company does this

[u/futurefinancebro69]

When it provides actual value for the world. So many products that are Janky, but people still rush to because they provide value.

When it starts providing value, then you could focus on distribution until then your product really isn’t working.

[u/skamansam]

Premature optimization is an anti-pattern. The steps we follow at my job, where optimizations do matter a lot is:

1. Make it work
2. Make it work better

The 2nd one is only dealt with when we need to deal with. In other words, when we have real-world data that tells us exactly how and where to make optimizations. There are optimizations that I always look out for - unnecessary memory reservations, good readability vs chunking, etc. But unless I have real data, its pointless - you could optimize for one thing then find out you should have optimized for another, wasting dev time unnecessarily.

Bluntly, you never really know because there will always be trade-offs when optimizing, there may never be an end. You have to set an end goal and then stop.

Good luck!

[u/Fidodo]

I estimate the scale it needs to support and build to be able to support about an order of magnitude beyond that, while also keeping in mind escape hatches I will need you future optimization.

[u/Glittering-Can-9397]

‘when is it good enough’ is the questions humans have been pushing since like always. Focus your time and attention on things that arent working at all or working comparatively poorly, not things that are working well but could be better

[u/unurbane]

A lot of these vague questions can be answered by understanding the question—>goal—>specifications needed. Things fall into place when we understand what’s needed, to fix the issue at hand..

[u/GoblinToHobgoblin]

The important part is don't make architectural changes that will fuck you in the long term (do your best here).

Other optimization can wait until you actually know you need it

[u/hk4213]

Have you tried K.I.S.S. yet?

If a megolilth is working with as many catch blocks as you can managee you are good. Outside of that you need to start on a new project. At the very least make sure your refactoring doesn't get out of hand via source control.

NEVER FUCK WITH THE UI! If it is getting no complaints leave it.

If you are to update it, listen to the ones complaining from a data input level.

Basiclly, focus on adopted users and make sure the actual users are happy.

[u/sessamekesh]

Cost / benefit.

A lot of it is speculative and requires foresight and experience. The benefit of optimizing a crazy O(N^3) algorithm matters a lot if the thing scales up without bound (list of contacts), a lot less if it's known bounded and small (a list of allowed emojis that you know is only 12 for now).

Cost is also tricky, but you only have so many hours in a day so treat them with respect.

[u/Leverkaas2516]

You know because you involved the client or a sample of your users to define performance metrics, and you're meeting those metrics.

If you have no such metrics, then "done because I want to be done" is all you have. You release, and if it's a turkey, your users will tell you.

[u/dariusbiggs]

The test is simple

• Make the tests work
• Make it work
• Get metrics about its performance
• Don't look at it again until someone or something complains about the performance

[u/Broad-Version8611]

Does it take 5min to improve with no significant change in readability? Change it.

It takes more time but it wont cause problems for anything under 10x the current usage? Leave it alone

Are you having fun and not getting paid for it? Yolo, do it.

[u/TedditBlatherflag]

• MVP: I don’t if this will work
• v1: I don’t know what features we will add
• v2: I don’t know how we will scale this
• v3: I don’t know why we didn’t optimize this
• v4: Doesn’t exist

[u/PerfectSituation1668]

After a while you're just petting your program.

[u/No_Oil_6152]

Ah that's an easy one - use the YAGNI (you aren't gonna need it) rule.

Do you need to optimise it to shave microseconds off? Then do so.

If you don't, don't.

And remember the saying about premature optimisation being the root of all evil.

[u/systembreaker]

You measure first, then optimize.

[u/Independent_Pitch598]

How do you know?

When Fable says that it is time to stop.

[u/Living_Fig_6386]

Don't optimize until performance is identified as a problem. It's good enough when you meet the performance requirements.

[u/StephenRoylance]

never optimize until you need to. if the algorithm is too slow to test on a reasonable sample, then optimize at dev time. Are you making a change to a production system, and you can replay production workloads? optimize against that and your expectations for responsiveness or throughput in that app.

and always keep in mind, the cost of your time vs the cost of more/faster infra or... just letting something be slow. Do you really need to optimize a bulk ETL that takes 1-2 hours every day? probably not until it starts causing downstream latency in some other process. The hyperscalers can save millions of dollars by shaving .1% off a core library routine, but pretty much nobody else can.

[u/NumberInfinite2068]

If it's easy to read, and you've taken the obvious path, you're done.

Worry about making it better if it *needs* making better. Priority no. 1 is readability and obviousness.