3 ms·
> if your game is already running at 60fps, there's no point in replacing list.sort()[0] If the game runs on a device with a battery then reducing that load is
by sqeaky 10y ago
> if your game is already running at 60fps, there's no point in replacing list.sort()[0]
If the game runs on a device with a battery then reducing that load is a reason. You already implied that though.
I suspect hard to quantify improvements in quality is not what you are trying to rail against. If the software is going to be used widely or for long duration hard to quantify improvements can easily save millions in the long run.
There are over-engineering efforts where people try to shoehorn in bad design strategies, over-abstract an already well abstracted or refactor well working code to be more "testable" when it is already tested. All of those should be opposed, but how do you draw the line be over-engineering and hard to quantify quality increases?
- dahart 10y ago> how do you draw the line be over-engineering and hard to quantify quality increases? That is a really good question. That is the question, IMO. I don't know the answer, and if I did I'm pretty sure I could make a lot of money doing it. It's a balance, maybe the right thing to do is just make sure you have forces in both directions, and don't let one force dominate for too long. Make sure in your working groups there are always people asking if there's a user facing metric, a real tangible reason or justification for the code you're planning to write or optimize. And also make sure there are people who are good at planning for the future and are good at coming up with user-facing justifications for upcoming plans.