Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
junon295256dI hate that saying. It's a copout and really means "the company doesn't want to pay you to do quality work, we need something shipped now"
Over optimizing is just one possible definition.
The saying might also mean:
- Don't waste time making it neat
- Don't waste time commenting the code
- Don't waste time thinking about edge or corner cases, stick to the defined ones
- Don't make it user friendly
And I'll add this:
Good is the enemy of secure.
@N00bPancakes I agree that premature optimization can be a problem but where do you draw the line?
If I write code that works for the 1 use case described but fails whenever an edge or corner case appears, is it good? Would adding code to handle more use cases be optimization?
If I write a CLI utility that doesn't provide help and isn't documented, is it good? Would adding CLI help be considered optimization?
What is the definition of "perfect", anyway?
And "good" can be adhered to as long as the requirements are understood and agreed upon. If they are free-form and ever-changing, and when are they not, who's to say when "good" is "good enough"?
I get it: This saying fits perfectly into XP. It's one of the aspects of XP I detest.
@junon I agree. There is a difference between over optimization and making something of quality.
I see optimization as:
- Cleaner code
- Faster code
- DRYer code
I don't consider optimization:
- Adding user friendly interfaces and help
- Catching predictable errors and faults