Makes sense for desktop software, less so for webapps and web services. I agree with the point that developers should profile their apps and for some apps having a bad computer is an implicit way of doing that. It doesn't mean it is a good strategy for everyone.
It makes even more sense for webapps, with the bloated frameworks, non native performance single threaded performance, network access overhead and bloated json parsing everywhere.
Force that dev to try out his app with cpu and network throttling to simulate a normal mobile phone user on a shitty mobile network and he'll soon reconsider fetching 10mb of javascript bundles and rerendering the entire page every time the mouse moves.
This, plus the best machines tend to come with high quality monitors, and testing your web apps a using lower resolution can expose all kinds of UI and accessibility gotchas.
Then again, if you’re developing something like a AAA video game, it’s going to be in a 5 year development cycle. So early in early development, you’re going to need a more advanced system to match what the mid-range system will look like in 5 years.
Plus, a lot of optimization happens closer to release in the game industry. There’s no sense optimizing code that may be removed or changed, you need something that’s closer to the final product.
13 comments
[ 3.7 ms ] story [ 51.5 ms ] threadIsn't the latter what a large chunk of desktop software is these days?
Force that dev to try out his app with cpu and network throttling to simulate a normal mobile phone user on a shitty mobile network and he'll soon reconsider fetching 10mb of javascript bundles and rerendering the entire page every time the mouse moves.
Plus, a lot of optimization happens closer to release in the game industry. There’s no sense optimizing code that may be removed or changed, you need something that’s closer to the final product.