5 ms·

An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobil

An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they're completely adequate for running all the software I've written.

pdimitar 7y ago
Good point, and I do that periodically. But I believe that's not the problem here, or at least not so much as the business being very impatient and just never respecting objections from the programmers that the quality of the software suffers due to far too tight deadlines.
mtm7 7y ago
I remember a story about an electronic musician who preferred to mix his songs with earbuds/headphones instead of with a high-end megabucks studio sound system. His reasoning was basically, “that’s how my fans will listen to my music, so I need to make sure it sounds good to them.” I can’t remember who it was, but the idea always stuck with me. Anyway, I agree that we should test our applications with the same hardware (and internet speed) of our average user. Very few people use a computer as good as a software engineer’s. :)
- gonational 7y ago
  That’s funny; I’m always debating my brother, talking about how earbuds sound much better than even high-end monitors, largely because of the surrounding environment (or lack thereof, when earbuds are in). When I make music I have to do the opposite; take my earbuds out and listen to the music over my car stereo or via my MacBook Pro speakers, to make sure it doesn’t sound good only through earbuds.
  - ratww 7y ago
    Hah, I have nice studio monitors since forever, but I also make music with Earbuds. I like them, but I've found that they make a bit too conscious about the sound, so I have to be extra careful. The isolation emphasizes noise and frequencies that the monitors don't, and that will be masked in the full mix. It used to lead me to a rabbit hole of noise-gating and EQs.
    - gonational 7y ago
      Interesting; I could totally see myself going down the same rabbit hole, or the opposite, thinking that a certain faint sound will be great, but when I play it in my car later it's completely unnoticeable.
      - ratww 7y ago
        > thinking that a certain faint sound will be great, but when I play it in my car later it's completely unnoticeable. That's true! This happens all the time with super expensive recordings too, and I love it. IMO discovering new sounds in the music you're used to only adds to the experience.
- qqii 7y ago
  Unfortunately this isn't the perfect solution as there is no universal device or average user. Especially with music, mixing songs for earbud/headphones will produce a worse quality song for another pair. In the same way we've seen software written by users primarily using x86 work less effectively when compiled to arm. Plenty of open source projects are developed on by people with less than adequate hardware yet they're still bloated and slow. I think it's very sensible (if a little unrealistic) to test applications on as many pieces of intended hardware as possible, and this somewhat reminds me about this story of snow clearance[0], where the solution was not only the intrudction of a new perspective but also empirical measurements. [0]: http://info.gritit.com/blog/what-is-gender-balanced-snow-clearance http://info.gritit.com/blog/what-is-gender-balanced-snow-cle...
  - hnuser123456 7y ago
    No one said you have to test on everything. Just adjust your target and testing hardware to something midrange, maybe even budget optioned. As above, test on some mid-range or even budget-level 2015 hardware, laptop or phone, and if it's smooth on that, it'll be smooth for people running 2020 hardware. You can never be sure about the reverse. That being said, there's a lot of crap software out there that's slow even on 2020 hardware.
- bradlys 7y ago
  I think testing with multiple hardware is a good idea. For audio, I'd say that editing audio on low grade audio equipment might backfire. I've always heard that professionals listen through multiple sources to make sure it sounds good on everything but idk how true that is these days. I've listened to quite a few people on YouTube and some musicians who clearly did their editing with a certain pair of headphones/earbuds. It comes through immediately on my speakers because high pitched whining noises made it through the edit (making it nearly unbearable to listen to) and/or they boosted the bass to infinity. (Usually indicates they never listened to their project on speakers because the bass heavy music between cuts becomes disgustingly loud whereas on headphones it's not that bad) It makes listening to their content impossible on decent speakers but fine on okay headphones.
systematical 7y ago
I have an underpowered chromebook for testing performance. Some sites actually crash on it. Much of the web is frustrating on it.
city41 7y ago
Also limit your network bandwidth to see how your app behaves when the user is on crappy 3g or what not.
ratww 7y ago
Ha! I use a 2011 MacBook Air with 2GB of RAM. It was the cheapest model when I bought it and the battery inflated twice, already! I still manage to crank some terrible solutions, though. :P
golergka 7y ago
I was so proud in 2014 that our development team managed to pull a 60 FPS on iPhone 4. Built our own UI framework (before Unity rebuilt theirs), pulled images from network, assembled and updated sprite atlases at runtime and even created our own text rendering - all of it, in order to get 60 frames per second on 4 year old phone. And most likely, it still does, in 2020. Since then, I've never worked in a team that would be so dedicated to perfomance. May be because that was a team that worked on a product with over 100 million installs that had all major features already developed - everybody else is too busy trying to figure out a market fit.
- MaxBarraclough 7y ago
  So the official toolkit wasn't capable of 60fps?
  - golergka 7y ago
    Official toolkit at the time was only immediate mode, calling all gui logic every frame, so, no. But even with the unity UI, building atlases on the fly isn't something that you can do out of the box.
Aeolun 7y ago
Try developing a react application built for IE11. That thing will fly if you ever run it in Chrome or FF (or even Edge)

pdimitar 7y ago

Good point, and I do that periodically. But I believe that's not the problem here, or at least not so much as the business being very impatient and just never respecting objections from the programmers that the quality of the software suffers due to far too tight deadlines.

mtm7 7y ago

I remember a story about an electronic musician who preferred to mix his songs with earbuds/headphones instead of with a high-end megabucks studio sound system. His reasoning was basically, “that’s how my fans will listen to my music, so I need to make sure it sounds good to them.” I can’t remember who it was, but the idea always stuck with me. Anyway, I agree that we should test our applications with the same hardware (and internet speed) of our average user. Very few people use a computer as good as a software engineer’s. :)

gonational 7y ago
That’s funny; I’m always debating my brother, talking about how earbuds sound much better than even high-end monitors, largely because of the surrounding environment (or lack thereof, when earbuds are in). When I make music I have to do the opposite; take my earbuds out and listen to the music over my car stereo or via my MacBook Pro speakers, to make sure it doesn’t sound good only through earbuds.
- ratww 7y ago
  Hah, I have nice studio monitors since forever, but I also make music with Earbuds. I like them, but I've found that they make a bit too conscious about the sound, so I have to be extra careful. The isolation emphasizes noise and frequencies that the monitors don't, and that will be masked in the full mix. It used to lead me to a rabbit hole of noise-gating and EQs.
  - gonational 7y ago
    Interesting; I could totally see myself going down the same rabbit hole, or the opposite, thinking that a certain faint sound will be great, but when I play it in my car later it's completely unnoticeable.
    - ratww 7y ago
      > thinking that a certain faint sound will be great, but when I play it in my car later it's completely unnoticeable. That's true! This happens all the time with super expensive recordings too, and I love it. IMO discovering new sounds in the music you're used to only adds to the experience.
qqii 7y ago
Unfortunately this isn't the perfect solution as there is no universal device or average user. Especially with music, mixing songs for earbud/headphones will produce a worse quality song for another pair. In the same way we've seen software written by users primarily using x86 work less effectively when compiled to arm. Plenty of open source projects are developed on by people with less than adequate hardware yet they're still bloated and slow. I think it's very sensible (if a little unrealistic) to test applications on as many pieces of intended hardware as possible, and this somewhat reminds me about this story of snow clearance[0], where the solution was not only the intrudction of a new perspective but also empirical measurements. [0]: http://info.gritit.com/blog/what-is-gender-balanced-snow-clearance http://info.gritit.com/blog/what-is-gender-balanced-snow-cle...
- hnuser123456 7y ago
  No one said you have to test on everything. Just adjust your target and testing hardware to something midrange, maybe even budget optioned. As above, test on some mid-range or even budget-level 2015 hardware, laptop or phone, and if it's smooth on that, it'll be smooth for people running 2020 hardware. You can never be sure about the reverse. That being said, there's a lot of crap software out there that's slow even on 2020 hardware.
bradlys 7y ago
I think testing with multiple hardware is a good idea. For audio, I'd say that editing audio on low grade audio equipment might backfire. I've always heard that professionals listen through multiple sources to make sure it sounds good on everything but idk how true that is these days. I've listened to quite a few people on YouTube and some musicians who clearly did their editing with a certain pair of headphones/earbuds. It comes through immediately on my speakers because high pitched whining noises made it through the edit (making it nearly unbearable to listen to) and/or they boosted the bass to infinity. (Usually indicates they never listened to their project on speakers because the bass heavy music between cuts becomes disgustingly loud whereas on headphones it's not that bad) It makes listening to their content impossible on decent speakers but fine on okay headphones.

systematical 7y ago

I have an underpowered chromebook for testing performance. Some sites actually crash on it. Much of the web is frustrating on it.

city41 7y ago

Also limit your network bandwidth to see how your app behaves when the user is on crappy 3g or what not.

ratww 7y ago

Ha! I use a 2011 MacBook Air with 2GB of RAM. It was the cheapest model when I bought it and the battery inflated twice, already! I still manage to crank some terrible solutions, though. :P

golergka 7y ago

I was so proud in 2014 that our development team managed to pull a 60 FPS on iPhone 4. Built our own UI framework (before Unity rebuilt theirs), pulled images from network, assembled and updated sprite atlases at runtime and even created our own text rendering - all of it, in order to get 60 frames per second on 4 year old phone. And most likely, it still does, in 2020. Since then, I've never worked in a team that would be so dedicated to perfomance. May be because that was a team that worked on a product with over 100 million installs that had all major features already developed - everybody else is too busy trying to figure out a market fit.

MaxBarraclough 7y ago
So the official toolkit wasn't capable of 60fps?
- golergka 7y ago
  Official toolkit at the time was only immediate mode, calling all gui logic every frame, so, no. But even with the unity UI, building atlases on the fly isn't something that you can do out of the box.

Aeolun 7y ago

Try developing a react application built for IE11. That thing will fly if you ever run it in Chrome or FF (or even Edge)