When the time came recently to upgrade the computer hardware for my developer workstation, it got me wondering what the average specifications are of dev workstations "in the field".  Through the use of twitter and linkedin, I reached out to several colleagues to conduct a very informal survey, to see what kind of horsepower they were running these days.  For all the respondents, they are full time employees and are not owners or consultants, so they typically don't make or influence the hardware purchase decision, they merely use daily what they are given.

In general, the results indicated that most were using a machine with specs similar to this:

Core i7 CPU @ ~2.67GHz, 2 Cores, 4 Logical cores, 8GB RAM, 7200 RPM Hard Drive

Upon doing some more research on the topic, I found this blog post on MSDN that discusses the hardware requirements for VS2010.  I also found myself referencing this blog from Jeff Atwood, that discusses a programmers "Bill of Rights" which includes some commentary on workstation hardware.

The basic theme I found in all that I read was, it does not really make sense to buy the bleeding edge, latest technology.  However, it is a very good idea to outfit your devs with the best hardware you can afford.

An argument in favour of this is a review of cost and productivity.

Some considerations on developer hardware:

$25/hr x 1 min/hr saved by faster hardware = $0.42 per hour

37 hrs/week * 52 weeks = 1,924 hours / year / developer

1,924 hrs * $0.42 per hour = $808.08 / year / developer

$808.08 * 20 devs = $16,161.60 total cost of lost productivity

So, if a more powerful dev workstation saved each dev only 1 minute of unproductive time per hour, that would result in a return of over $800/yr in increased productivity.

I highly suspect that the 1 min/hour is a conservative estimate.  I also suspect that for most locales, $25/hr for a professional software developer is also conservative.

If you used $40/hr instead, you would save $0.67/hr or $1,289.08 / year / developer.  That would be $25,781.60/yr for a team of 20 devs.

The ROI for fast dev machines seems apparent.

Benchmarks:

Now for the discussion about how much time a developer would actually save by having a faster machine.  I got some inspiration for doing some benchmarks from this blog by Scott Hanselman.  I used his idea of using the NHibernate.Everything.sln and source for benchmarking the machines that I had easy access to and the results of this are shown in Scenario 1.  I then added to the mix some other scenarios that developers in our organization might be likely to do in their day to day work, with our source code.  When using MSBuild.exe I used the /t:rebuild switch as well as the /m switch for parallel builds in B scenarios.

Results Comments

Scenario 1

Builds the source code for the open source project Nhibernate.  Parallel builds seems to have a small effect here, as shown in differences between 1A and 1B results.  Machine #1 is on average 41% faster than Machine #2.  For every hour of compile time, an extra 25 minutes would be saved by using the faster machine.

Scenario 2

Builds the database project for a single database.  Parallel builds seems to have a negligible effect here, as shown in a lack of differences between 2A and 2B results.  This makes sense since there is only 1 project to build.  Machine #1 is on average 44% faster than Machine #2.  For every hour of compile time, an extra 26 minutes would be saved by using the faster machine. 

Scenario 3

Deploys the database project from Scenario 2 to SQL Server, actually creating the database.  I do not believe that parallel processing is possible for database project deployments.  Machine #1 is on average 59% faster than Machine #2.  For every hour of time spent deploying databases, an extra 35 minutes would be saved by using the faster machine.   

Scenario 4

Builds the database projects for 5 databases and one shared server database project.  Parallel processing has a significant effect here, as a lack of dependencies between database projects allows a multi-core machine to build the projects concurrently instead of one after the other.  Machine #1 is on average 58% faster than Machine #2 for Scenario 4.  For every hour of time spent building the full database solution, an extra 35 minutes would be saved by using the faster machine.  Considering Scenario 4B only, when leveraging multiple cores and parallelism, Machine #1 is on average 69% faster than Machine #2 for Scenario 4B.  For every hour of time spent building the full database solution, an extra 41 minutes would be saved by using the faster machine.       

Final Thoughts

It seems that providing good quality workstations to your developers can result in increased productivity, that should more than cover the extra cost of acquiring faster hardware.

 

I recently took on a new challenge, the restoration of a 145 year old century home.  The house has triple brick walls and some of the restoration work we are doing includes repointing the lime based mortar.  This involves manually taking the old mortar out and then replacing it with new mortar.

I took a 2 day workshop to learn how, and then I thought that making a How To video of the steps I am taking would be fun.  So here it is!

I recently had the opportunity to be an exhibitor at the Adventures In Innovation event held at Trent University in Peterborough on October 29, 2010.

The event was organized by the Workforce Development Board and the objectives of the event were to:

• educate local Grade 10 students about employment opportunities, educational requirements and "day to day" responsibilities of a variety of careers
• assist students in making informed career choices

Seeing as how we work in the field of Information Technology and more specifically, Software Development, we provided information about the types of employment positions that are typically found in that sector.

It was interesting to speak with some students who shared the same curious desire to take things apart and figure out how they worked, just as I did when I was their age.  Several students expressed a genuine interest in building software.  While some others, did a good job of faking it, in order to get one of our "spring" pens.  The unique pens proved to be a good draw of traffic.

After a couple of hours, we had succeeded in speaking with several students, and I'd say the event was a success.

Here is a co-worker and I at our exhibitor booth.  Unfortunately, our table had a bit of a sag in the middle which made things look a bit funny, but we persevered.