Speed improvements are legible (measurable), although most people are probably not measuring them. Sometimes that’s okay; if the app is visibly faster, I do not need to know the exact number of milliseconds. But sometimes it’s just a good feeling that I “did some optimization”, ignoring the fact that maybe I just improved from 500 to 470 milliseconds some routine that is only called once per day. (Or maybe I didn’t improve it at all, because the compiler was already doing the thing automatically.)
Code quality is… well, from the perspective of a non-programmer (such as a manager) probably an imaginary thing that costs real money. But here, too, are diminishing returns. Changing spaghetti code to a nice architecture can dramatically reduce future development time. But if a function is thoroughly tested and it is unlikely to be changed in the future (or is likely to be replaced by something else), bringing it to perfection is probably a waste of time. Also, after you fixed the obvious code smell, you move to more controversial decisions. (Is it better to use a highly abstract design pattern, or keep the things simple albeit a little repetitive?)
I’d say, if the customer complains, increase the speed; if the programmers complain, refactor the code. (Though there is an obvious bias here: you are the programmer, and in many companies you won’t even meet the customer.)
I’d wager that customers (or users) won’t complain about slow code, especially if there’s many customers, for the same reason that most people don’t send emails with corrections or typos on most online posts.
Speed improvements are legible (measurable), although most people are probably not measuring them. Sometimes that’s okay; if the app is visibly faster, I do not need to know the exact number of milliseconds. But sometimes it’s just a good feeling that I “did some optimization”, ignoring the fact that maybe I just improved from 500 to 470 milliseconds some routine that is only called once per day. (Or maybe I didn’t improve it at all, because the compiler was already doing the thing automatically.)
Code quality is… well, from the perspective of a non-programmer (such as a manager) probably an imaginary thing that costs real money. But here, too, are diminishing returns. Changing spaghetti code to a nice architecture can dramatically reduce future development time. But if a function is thoroughly tested and it is unlikely to be changed in the future (or is likely to be replaced by something else), bringing it to perfection is probably a waste of time. Also, after you fixed the obvious code smell, you move to more controversial decisions. (Is it better to use a highly abstract design pattern, or keep the things simple albeit a little repetitive?)
I’d say, if the customer complains, increase the speed; if the programmers complain, refactor the code. (Though there is an obvious bias here: you are the programmer, and in many companies you won’t even meet the customer.)
I’d wager that customers (or users) won’t complain about slow code, especially if there’s many customers, for the same reason that most people don’t send emails with corrections or typos on most online posts.