How to measure productivity loss from slow PCs running Visual Studio?

Question

Many PCs we have on the development team are out-dated and are very slow to run Visual Studio 2008. They should very much be replaced with newer machines. But there's a general reluctance on management/company to buy new machines.

How do we come up with numbers and benchmarks to show that these slow PCs are causing a loss in productivity?

Obviously we can't call them to sit down with us as we build solutions and/or open various files.

Is there an objective way to come up with some kind of reliable numbers that non-technical people can understand?

It'd be nice to have a way to measure this across an entire organization on many different PCs running Visual Studio. I'm looking for an answer that does better than using a physical stopwatch. :)

Answer 1

Modify your solutions so that the pre-build and post-build events write the current time to a centralised database. Include the machine name and the name of the project.

You can then display this information as graph showing time for build vs machine.

This should show a correlation between the build time and the age of the machine, hopefully showing the the older machines are slower. You could even convert the time into a $ (or £ or € ) value to show how much these older machines are costing. Summing this over time will give a value for the payback on any investment in new machines.

By modifying the solutions you can get this logging deployed onto all development machines by simply getting everyone to do a "get latest" from source control.

Answer 2

Many PHB's understand productivity in terms of lines of code (which IMO is very Wrong).

Can you record the amount of code produced per day on the slow machines vs not so slow machines?

Answer 3

Slow machines are the bane of development, IMHO, especially since any delay gets developers out of concentration and can lead to a much costlier switch to things like web browsers. There can be other weird effects like a how a slight increase in the latency for the Javadoc popup or C# equivalent) to appear when you hover a method and the chances someone would consult the documentation.

If legal in your company (at least for self use), record about half an hour of work with a screen capture tool like Camtasia. Then use a fast editor to spot the times the machine was hung (easy if you have a cursor change, progress bar, etc.) and count the time and number of instances. I've done that for hours of tapes - it doesn't take that long. Use these numbers to argue the case, though you need to also argue that it leads to the indirect costs like a context switch.

Also, in my experience, hard drives are often the major cause of slowdown, not CPU or RAM, and unfortunately most organizations skimp on fast hard drives or SSDs and have very strict rules about replacing them.

Answer 4

I would attempt to explain to them that programmers cost much more than machines. If you spend 30 minutes a day waiting, do the math and figure out what percentage of your salary is wasted due to laggy machines. Present these numbers to them, and compare it to the price of a new computer, and explain how they could save money in the long run by upgrading.

If they choose to continue to spend big bucks affording your wisdom only to have you sit there and watch a spinning cursor, just laugh because the joke is on them.

Answer 5

Don't forget to factor in the cost of time spent figuring out how much slow PCs cost you (this post in other words)!

Answer 6

This does not really answer your question, but might help to achieve the required results. Tell your bosses that The Programmer's Bill of Rights is something to be taken seriously.