What performance indicators can I use to convince management that I need my development PC upgraded?

At work, my PC is slow. I feel that I can be way more productive if I just wasn't waiting for Visual Studio and everything else to respond. My PC isn't bad (dual-core, 3GB of RAM), but there is a lot of corporate software and whatnot to slow everything down and sometimes lock it up.

Now, some developers have begun getting Windows 7 machines with 8 GB of RAM. Of course, I start salivating at this. However, I was told that I "had to justify" why I should get a new machine.

I can think of a lot of different things, but I am curious as to what every one else on SO would have to say.

NOTE: Ideally, these reasons should be specifically related to .NET development in 开发者_开发技巧Visual Studio on a Windows machine. This isn't a "how can I make my machine faster" question.

I would ask myself "What am I waiting on?" And then let the answer to that question drive whether or not I felt like I could justify it.

For example, right now, I'm dealing with 90 minute compiles of the project I'm working on. Would a faster machine help that? A little. But, more impactful would be sane configuration management. So, I'm pushing that way (to no avail) rather than to the hardware route.

Bring in a chess clock.

If you are waiting start the clock when you aren't stop the clock.

At the end of day, total up the time multiply it by your pay rate, multiply it by 2000, and that is a reasonable upper limit as to the amount of money the company is squandering on you per year due to a slow machine

Most useful metric: How much time do you spend reading The Onion (or, these days, StackOverflow)?

This is item #9 on The Joel Test:

9. Do you use the best tools money can buy?

Writing code in a compiled language is one of the last things that still can't be done instantly on a garden variety home computer. If your compilation process takes more than a few seconds, getting the latest and greatest computer is going to save you time. If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity.

I agree with the "what is holding me up?" approach.

I start with improviing workflow by looking at repetitive things I do that can be automated or a little helper tool can fix. Helper tools don't take long to write and add a lot of productivity. Purchasing tools is also a good return on your time - a lot of things you could write, you shouldn't bother, concentrate on your core activity and let the tool makers concentrate on theirs, whether is is help software, screen grabing, SEO tools, debugging tools, whatever.

If you can't improve things by changing your workflow (and I'd be surprised if you can't), then look at your hardware.

• Increase memory if you can. If you're at 3GB with a 32 bit OS, no point going any further.
• Add independent disks. One disk for the OS another for your build drive. That way there is less contention for disk access from the OS and the compiler. Makes a difference.
• Better CPU. Only valid if you are doing the work to justify it.

Example: What do I use?

• Dual Xeon Quad Core (8 cores, total)
• 8 GB RAM
• Dual Monitors
• VMWare virtual machines

What are the benefits?

• Dual Monitor is great, much better than a single 1920x1200 screen.
• Having lots of memory when using Virtual Machines is great because you can realistically give the VM a realistic amount of memory (2GB) without killing the host machine.
• Having 8 cores means I can do a build and mess about in a VM doing a build or a debug at the same time, no problems.

I've had this machine for some time. Its old hat compared to an iCore7 machine, but its more than fast enough for any developer. Very rarely have I seen all the cores close to maxing out (pretty much going to be held back by I/O with that much CPU power - which is why I commented on multiple disks).

For me (working in a totally different environment, where JBoss, Eclipse and Firefox are the main resource sinks), it was simple enough:

"I have 2GBs of RAM available. I'm spending most of my time with 1GB of swap in use: imagine what task switching and application building looks like there. Another 2GB of RAM costs 50 euro. Ignoring the fact that it's frustrating working like this, you do the productivity math."

I could have shown CPU load figures and application build times as well, but it didn't come to that. It took them a month or two, but boy is development a joy since then! Oh, and for performance, it's likely you'd do best with Windows XP, but you probably already know that. ;]

Use some performance monitor to determine the cause.

For me its the antivirus has some kind of critical resource leak the slows down IO after a few days requiring a reboot and no hardware upgrades will help much.

The justification will need hard data to back it. If their business software is causing the problem that "this is industry standard" obviously doesn't fly anymore. Maybe they'll realize their business software sucks and fix that instead.