4 ms·

User focused metrics: 1. It's a user facing bug if I have to purchase a bigger laptop because someone decided to get the smallest element of a list by typing l

User focused metrics: 1. It's a user facing bug if I have to purchase a bigger laptop because someone decided to get the smallest element of a list by typing list.sort()[0]. 2. It's a user facing bug if the use of my app heats up their phone, drains the battery, and leaves someone stranded w/o a way to get safely get home on a friday night. 3. It's a business facing bug if my AWS bill is in the hundreds of thousands per month when I could be paying a mere 10s of thousands. (This is more common than you'd think) 4. It's a user facing bug if a sudden increase in traffic (due to my product being featured somewhere) takes down my services and results in lost sales and brand damage. I understand your point, it's not necessarily a problem if a backend feed is taking 45s instead of 30s, or if the the text input subroutine for an interactive app allocates. As far as I can tell as a software developer and daily computer user, people aren't erring on the side of making their software too fast.

mattmanser 10y ago
If you've a widely used program and you've never run a profiler on it, that's the problem, not using list.sort()[0].
dahart 10y ago
100% agree with all of these, and you did what the author didn't and added criteria that affect people. If these happen, then make the code faster! Abrash is a well known games/graphics programmer, and part of his point is that if your game is already running at 60fps, there's no point in replacing list.sort()[0] with something else. No milliseconds saved will help anyone in that case. (Though yes, as many pointed out, power consumption may be an important metric). Personally, I'd say if your backend feed is taking 45s and could easily take 30s, then you should fix it. :) > people aren't erring on the side of making their software too fast :) 100% agree... too fast isn't a problem we have. But, over-engineering is an exceedingly widespread problem, and that's where I'm coming from. If there's a user-focused metric that shows a problem, yes fix it. If there isn't a user-focused metric, then think twice. The article didn't advocate a user-focused metric as far as I could tell.
- 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.
- cestith 10y ago
  In The Practice of Programming Kernighan and Pike say that one should estimate how much time can be saved over the expected runs of the program and allocate no more than that much time to optimization. If you're doing something once or once per year that takes 45 seconds rather than 30 then don't bother. If you're doing it once every hour, that's six minutes a day, 365 days a year. If it's on a minutely cron on a hundred systems, that's 144,000 seconds a day. If a few hours of time can save you 144,000 seconds of runtime every day, that's a clear winner assuming other higher priority things are done. If it's run minutely by thousands of customers on hundreds of thousands of servers...

mattmanser 10y ago

If you've a widely used program and you've never run a profiler on it, that's the problem, not using list.sort()[0].

dahart 10y ago

100% agree with all of these, and you did what the author didn't and added criteria that affect people. If these happen, then make the code faster! Abrash is a well known games/graphics programmer, and part of his point is that if your game is already running at 60fps, there's no point in replacing list.sort()[0] with something else. No milliseconds saved will help anyone in that case. (Though yes, as many pointed out, power consumption may be an important metric). Personally, I'd say if your backend feed is taking 45s and could easily take 30s, then you should fix it. :) > people aren't erring on the side of making their software too fast :) 100% agree... too fast isn't a problem we have. But, over-engineering is an exceedingly widespread problem, and that's where I'm coming from. If there's a user-focused metric that shows a problem, yes fix it. If there isn't a user-focused metric, then think twice. The article didn't advocate a user-focused metric as far as I could tell.

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.
cestith 10y ago
In The Practice of Programming Kernighan and Pike say that one should estimate how much time can be saved over the expected runs of the program and allocate no more than that much time to optimization. If you're doing something once or once per year that takes 45 seconds rather than 30 then don't bother. If you're doing it once every hour, that's six minutes a day, 365 days a year. If it's on a minutely cron on a hundred systems, that's 144,000 seconds a day. If a few hours of time can save you 144,000 seconds of runtime every day, that's a clear winner assuming other higher priority things are done. If it's run minutely by thousands of customers on hundreds of thousands of servers...