Coding Horror: Pressing the Software Turbo Button | Hacker News Reader

Coding Horror: Pressing the Software Turbo Button

codinghorror.com

9 pointstwampss13 comments

What an utterly pointless article.

No joke - totally missed the point and went off on an unrelated tangent - real broken record stuff.

"Developers need fast machines to be productive"

Possibly. But one of the advantages of giving developers comparatively slow machines is that it gives them a personal incentive to produce fast software.

Of course that's painful when bloaty IDEs come into play, but for web software I'd have to suggest using an under-specced deployment test platform to get some of this benefit.

Giving developers sub-par machines for "incentive" purposes is... well, crazy. Intentionally slowing down your write-compile-test cycle makes no sense.

For web software, you indeed want your test environment to be no faster than production, so it can be slower (within reason), especially if you have a hard time simulating in test loads you expect to see in production.

Your developers should have the exact same spec machines as your users.

I remember back in the day working for a company whose websites looked gorgeous on the designer's high-end Mac displays on the LAN... The average customer at the time had a 56.6k modem.

Not for development they shouldn't. For testing sure, but are you really going to justify that the development process should take at least twice as long because of poor QA?

I really question whether a fancy machine helps with productivity. Some things are obvious, like plenty of screen real estate so you can switch contexts just by flicking your eyes. But most of the tools are just gratuitous power hogs. Rational Rose, Eclipse, etc. Let's be brutally honest, modern IDEs don't do much that Energize wasn't doing perfectly well well over a decade ago, or that Emacs was doing a decade before that. I could do my job on an old SparcStation 5, and I bet everyone else could too.

That's a bet you'd lose.

More specifically I can't without taking a huge hit in productivity (and there are somethings I wouldn't be able to do at all on a Sparc station).

In order to do my job, here's a short list of what I run on my MBP:

Eclipse (explaining why Eclipse is better for my needs than emacs (which I used to use) would take a while, but lets assume I'm actually more productive with Eclipse)

Parallels Linux VM running Oracle 10 XE

Parallels Windows XP VM for testing with IE and IE 7, and running a couple of windows only tools I need on occasion

Mail.app

Adium

Safari

Firefox

iCal

iTunes

TextMate

OmniFocus

VPN Client

SQLDeveloper

JBoss + ATG Commerce JVM (768 MB of RAM)

JBoss + ATG CSC JVM (768 MB of RAM)

Ant builds triggered from Eclipse that compile hundreds of Java files and deploy 5k+ files to the various JBoss servers

The JVMs have to be restarted frequently to pickup code and config changes

While I'm sure there are lots of people who could do their jobs just fine on a SparcStation 5, or any old computer, there are some people who need large amounts of RAM and very fast CPUs in order to not spend their day waiting for builds, JVM restarts, and VMs to come out of swap, etc...

You can emulate a slow connection using something like YSlow. http://developer.yahoo.com/yslow/

Intentionally slowing down development time just doesn't seem like the correct approach to me.

If all they do is browse/design the pages, maybe.

If your developers need to run Eclipse, JBoss, Oracle, SQLDeveloper, Safari, IE6, IE7, Firefox, run Maven/Ant builds, email client, IM client, etc... Then the faster their machine runs those builds, switches to the next browser, lets your app retrieve data from Oracle, etc... the better.

Ideally your developers would have the exact same specs as your users' machines + your build server + your web-app servers/cluster, if you want them to see things the same way they'll be seen in production. Since that's not really viable, lets settle for a really fast, high RAM, desktop/laptop with a big screen:)

No. A slow machine is just aggravating. If I have to wait very long for a compile, the IDE, anything, there's a good chance I am going to get distracted and do something else. I'll typically have tons of things open at once, already slowing things down a bit; having old hardware is just too much on top.

It is important to check for performance on slow machines, but that can be done on a virtual machine.

Seconded, its extremely aggravating, I remember clearly when I had the horror of working with an old version of .NET C# with a big project on a SHARED slow server, which took roughly 1-2mins to compile, can you imagine trying to learn and debug C# code under this environment? Right, not a good idea.

Sure, it's annoying. But I didn't say it was nice, I said it was a good incentive for the developer to create software that was snappy.

Those suggesting the use of a separate slow test environment are, I submit, being unrealistic about real-world practices in testing.

Reply on news.ycombinator.com