5 ms·
If you can get past the "condescending excuse to save on hardware costs" bit there's actually a glimmer of truth to this. People are generally more motivated to
by mustpax 16y ago
If you can get past the "condescending excuse to save on hardware costs" bit there's actually a glimmer of truth to this. People are generally more motivated to solve problems they can directly experience and therefore understand. Question is: can you get developers to develop on a fast machine but consistently use an emulator/testing environment that's slower? If they are motivated and disciplined I would say yes. But it's worth a thought.
- pavel_lishin 16y agoYeah, it would make sense to test things on a slow machine, but having a slower machine is like increasing a lumberjack's output by giving him a dull axe.
- sudont 16y agoMore like forcing an axe-maker to test his own axes on trees, rather than having him watch the lumberjack test them out.
- slantyyz 16y agoWhile I agree with you, the thing with developers these days is that they will see an ad that says "We give our developers the best and fastest machines to do their work", and they won't care about the reasoning behind using slow machines. I would bet that there's even a segment of developers who actually rely on Moore's law to overcome performance issues in their apps at release time.
- Splines 16y agoIn a game post-mortem, one of the ways the team was motivated to maintain acceptable performance was to add a picture of their perf-dev in the corner of the game in varying states of angriness. The lower the framerate, the angrier he looked. It helped personalize the frustration gamers would feel when a developer introduced a feature that caused poor performance. With a desktop/web app, this is harder to do, but the idea could still have merit - surface perf data so developers can see the clock-cycle impact of their features.
- yummyfajitas 16y agoThere is a glimmer of truth to this idea, assuming developers are being lazy about performance, but I still think it will reduce productivity. My experience: I work at a high frequency fund. We do not skimp on performance - I rewrote Java's Math.exp for speed, and I rewrote our data store reader (already optimized to be read sequentially) to use multiple cores. Nevertheless, slow performance == downtime. I should be writing code right now. Instead, I'm waiting for a simulator to finish testing my strategy. I've probably wasted hundreds of hours this year waiting for tasks to finish, in 5-15 minute chunks. I think there is an easier solution. If your developers are being lazy about performance get new developers. If that really isn't an option, pay them more if the code runs faster.
- stcredzero 16y agoIf that really isn't an option, pay them more if the code runs faster. The problem with this, is that any benchmark can be gamed. However, if your software runs daily batch processes, you can keep track of processing time and take the average time per transaction. Measuring actual performance in the production environment would be much harder to game.
- yummyfajitas 16y agoSince the problem is lazy programmers, we are probably discussing regime of doing sums in php rather than in the db. In this regime, legitimate performance improvements are usually easier than gaming benchmarks.
- stcredzero 16y agoIt's just better policy to ensure that some engineer like Wally thinking, "I'm gonna code me a minivan!" actually benefits the company if the plan is executed.
- radu_floricica 16y agoWhy is programming management so stone-age? I realize it's been often compared to herding cats, but are things really so bad that a simple problem gets a "lazy programmers" and "get new ones" response? And from a management point of view, in any other domain it _would_ be a simple problem. Imagine complaining that your architects don't make your houses energy-efficient enough. So you get new architects?! No... you talk to them, you set standards, you check their designs or have managers check them... you solve the problem with the many management tools developed over the years. But when it comes to programming, we barely see this at all, at least not in small companies. Why?!