5 ms·

Can I Make My Developers Write Efficient Code by Giving Them Slower Machine?

• xutopia 16y ago
  That's like asking wether or not you'll make race car driver's faster by giving them slower cars for practice.
• wccrawford 16y ago
  No, but you could make development cost a lot more.
• petervandijck 16y ago
  Yes, and you can get your toddler to sleep later in the morning by keeping them up later in the evening. Oh wait, no you can't.
• jimwise 16y ago
  Be took this approach, for what it's worth -- they sold two models of BeBox, and all developers were given the slower one. They pointed this out very proudly in their launch pitch for BeOS, a pitch which focused as much on performance / concurrency advantages of BeOS over the then-lagging MacOS as it did on the novel API features of the OS. Don't know whether that anecdote counts as for or against the idea, but it's certainly been tried...
  • stcredzero 16y ago
    I'd say for. A fully loaded Be desktop could easily weigh in at under 300MB. That would count as a "lightweight" Linux distro. BeOS was a lean machine.
    • gonk 16y ago
      I still have my BeBox, if only because back in the day I got a hell of a lot of good things done with it (reverse engineering of strange file systems, mostly) and without question I can still kick out some fully functional, performant, code with the thing. Old computers may be slow, but there is a hell of a lot of bloat in our computer worlds these days.
    • silentbicycle 16y ago
      I never developed for it, but I ran the free install years ago on (then) laughably slow hardware, and it was still quite snappy.
• slantyyz 16y ago
  In today's environment, you can definitely make them want to quit sooner by giving them a slower machine.
  • MrFoof 16y ago
    I came to say this. The reality is your programmers should instead have a low-level understanding of what their code does, and how it performs. They should then be using profilers and monitoring tools to ensure it's behaving inline with their expectations. One of my strengths is always being able to give a rough estimate as to how long a task should take before I've written it. The only surprise usually is if I find ways to make it even faster than I assumed was possible, by finding clever techniques to use.
    • slantyyz 16y ago
      I agree with you. I would add that in addition to having that low-level understanding, they should also care about what their code does and how it performs. That's where it tends to break down for me. For a lot of people in McProgramming jobs, they don't care, and rely on Moore's law to handle the rest, or mark it off as technical debt that can be paid off at some unknown time in the future (and that time never seems to arrive).
• zacharypinter 16y ago
  I'd say give them a virtual machine image to run with certain (slower) specs, and ask them to periodically try the app out on that. Their main dev machine needs to be fast though.
• 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 ago
    Yeah, 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 ago
      More like forcing an axe-maker to test his own axes on trees, rather than having him watch the lumberjack test them out.
  • slantyyz 16y ago
    While 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 ago
    In 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.
  • 16y ago
• drallison 16y ago
  Developers benefit by having a fast machine. But it is also important that they feel the pain of using a slower machine if that is the target market.
  • acqq 16y ago
    If I had a dollar for every equivalent of "what do you mean slow, it's not when I try with 3 of <something that the app should process in thousands> on my overclocked XXX with 16 GB of RAM and 4 hard disks in 10000 rpm and RAID" I've heard or read I'd be very rich now. The only competition they have is the other bad developer's all-time favorite "but it works and it's fast when you delete the database and start from that." There are more bad than good developers (and managers!) in the world. They won't care to make anything faster than what's being "acceptable" for them. Case study: Adobe Reader.
• compay 16y ago
  Having a slow machine available to test your code on is a nice option, but I'd be very annoyed if I was forced to use it as my development environment. Then again, it depends on what you're doing. I have a pretty slow netbook that I use when I travel. Working in Ruby or Java can be painful, but working in Lua feels exactly the same as on my Macbook Pro.
  • ryandvm 16y ago
    We just need to bring back the "Turbo" button.
    • bobf 16y ago
      New-ish MSI and Asus laptops actually have a Turbo button. It basically performs automatic CPU overclocking (at the expense of battery life).
• rimantas 16y ago
  Just give them profilers.
  • aidenn0 16y ago
    Not good enough. We have automated performance testing on older machines here. There was a case where something that ran blazingly fast on the developer's machine completely bombed the automated performance test on an older machine. In fact it ran several orders of magnitude slower. It turns out that the older machine had a smaller and less associative cache. On the developer's machine there were no memory accesses in the innermost loop, but on the older machine it was hitting memory several times in the innermost loop. This is a case where the rated MIPS difference was less than a factor of 4, but the performance difference was orders of magnitude.
• ianferrel 16y ago
  Yes, but they'll write it for someone else.
• andyv 16y ago
  The converse is true-- you can get your developers to write slow and bloated code by giving them top of the line machines. Fast machines are good for quick builds, but taking the trouble to test the code somewhere else is usually too much.
• csouth 16y ago
  The simple fact that someone is asking this question makes the developer in me weep...
• raheemm 16y ago
  This is why Russian programmers from the 80s were so good - that developed on crappy computers.
• georgecmu 16y ago
  edit-compile part of the development cycle should take place on the best machine possible (or machines -- see http://linux.die.net/man/7/icecream http://linux.die.net/man/7/icecream), but the run/test part of the cycle should take place on the target machine.
• AlexC04 16y ago
  In theory you could also make them write more efficient code by measuring the efficiency of their code. Paul Grahm - sentence 7 http://www.paulgraham.com/13sentences.html http://www.paulgraham.com/13sentences.html :)
• rubinelli 16y ago
  Wouldn't low-memory, single-processor VMs offer a decent first approximation?
• protomyth 16y ago
  Let's see, I spend extra time compiling, my debug version runs a lot slower while I try to find the bug, and I get laughed at by people working at other companies. Not to mention crap machines might not even meet the specs of the development tools. Thank $DIETY that this guy doesn't run a shop for embedded programmers.
• thesunny 16y ago
  We solved this problem for web development for orbs.com by doing the following: Everyone has fast dev machines. We access the site through a local domain name like orbs-sunny.com referring to my personal computer; however, this is routed through Nginx with throttling on to simulate a slower external connection. If we need a faster connection for certain types of testing like uploading 100MB files, we use orbs-sunny-fast.com. This goes directly to our machine and skips nginx. It is not perfect in that it doesn't simulate a slow computer; however, it's good enough to make everybody pay attention to speed. We did this because speed related issues were often ignored at the time of original development. We found that the slowdown on execution hasn't slowed development since our app is supposed to be responsive anyway. If it's not responsive, it's much better to fix it while your head is in that space. This results in faster overall development. Sunny
• edanm 16y ago
  This is actually an intriguing question. I remember reading a quote that claimed that the reason Windows UAC is so messed up is because all developers run as admins on their Windows machines, so they never bother to make their programs run without admin permissions. Opposed to, say, Linux, where the default is to run without root priviliges, and only run as root for the things you really need.
• dugmartin 16y ago
  Reminds me of the story of the discus the Americans brought to the first modern Olympics. From http://www.uh.edu/engines/epi1137.htm http://www.uh.edu/engines/epi1137.htm: "Robert Garrett, from Princeton, competed in several events. The discus was unknown in America so he had a blacksmith fashion one like those in Greek art. It weighed 20 pounds -- much too heavy to throw. Once in Greece, he found that a modern discus only weighed five pounds. He practiced with one for a few days. Then he dethroned the Greek champion. Garret came home with four gold medals."
• dgant 16y ago
  There's a similar thought process in the music production world: Get punchier mixes by listening to wimpier speakers while you mix.
• crs 16y ago
  I am sort of confused. If you ask them to improve performance do they just ignore you? I know with the current project I am on, we have a very specific cpu and memory usage requirement. This specific requirement is silly in what the customer demanded, but it is a requirement and it is our job to make it happen. There is no option to ignore it. Don't give your developers an option. Set specific goals based on your target environment. The product is not ready to ship until it meets those goals. At the same time you have to be reasonable. Your goals must be based on what the applications are actually doing. If they are very graphics heavy, you may need faster hardware than if its just a standard office style app. Giving them slower hardware will never make impossible things possible.
• sciolistse 16y ago
  I don't have anything measurable, but I do work on a slow, glitchy VM with a bloated application on an old machine in some of my projects.. It takes in the several minutes for me to test any changes to the codebase. It's possible that under the right conditions this might work (though I doubt it..), but in my situation the code has been steadily degrading due to refactoring being too painful of a wait, and having the time for a coffee break between any code change shakes any semblance of concentration on what you're working on straight out of you. You might be better off deploying to a slower test machine and have it run some time-tests there.
• scottyallen 16y ago
  My guess is the answer is probably yes, if you give your developers slower machines, they will start optimizing things for performance. However, I suspect they won't spend the time optimizing what you want them to. Good developers HATE being inefficient. Sitting around waiting for something to compile gets your out of the flow of writing and testing code. So instead of spending all their time optimizing the app, I suspect they'll spend a disproportionate amount of time optimizing the build process. Not really the outcome you want... Now, as you suggest, if there's a way to slow down only the running of the app, and not the rest of the development process, that would be useful and probably would cause the sort of changes you're looking for.
• linuxaddict 16y ago
  Yes, they would be motivated to write optimized code rather than a bunch of crap. Their productivity may suffer, unless their tools were also optimized to run on these slower devices. I normally write (or test) code in a virtual machine on an older system to make sure I force myself to think about impact to performance.
• gonk 16y ago
  A lot of people are saying "hell no, give me a fast machine because otherwise the development environment is going to suck ass.." Well, this is more a statement about the condition of the tools themselves. We need fast multi-core machines to do the building and developing, simply because the tools blow. Visual Studio is a dog! So I think the answer is not just to reduce the speed available to the programmer, but to refine the tools. Too many programmers rely, nay depend, on big fat bloated code tools that still don't really deliver much more than the end results (see recent threads about IDE suckage) .. so I say: "Yes, give your developer slower PC's to code on, but also give them more basic, more efficient tools. Fire those that rely on the heavy bloatware too much to get their jobs done, and promote those who can deliver the goods, no matter the deployment/development hardware restraints you impose.."
• regularfry 16y ago
  If the answer to this question were "no", I'd expect developer productivity to have increased over the years in line with computer performance, all other things being equal.
• thwarted 16y ago
  I once had a boss who refused to upgrade our machines from 486s to Pentiums because of this exact reason. What we later found out was that if we compiled the code on a 486, none of the newer SIMD instructions were used, so the performance difference was actually more pronounced than we first realized. We eventually had a special build environment, but the target market was newer processors anyway, so there was no reason, other than lack of funds, to not upgrade the engineers' machines.