7. November 2010 07:43
by Troy

Developer Hardware - How Much Is Enough?

7. November 2010 07:43 by Troy | 0 Comments

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.


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.


    #1 #2 #3 #4  
    Laptop Laptop Desktop Desktop Speed Comparison
Hardware Spec CPU Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz, 2667 Mhz Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz, 2267 Mhz Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66GHz, 2666 Mhz Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz, 2668 Mhz Machine #1 Faster than Machine #2 by X%
CPU Cores 2 Core(s), 4 Logical Processor(s)  2 Core(s), 2 Logical Processor(s)  2 Core(s), 2 Logical Processor(s) 4 Core(s), 8 Logical Processor(s)  
DRIVE 7200RPM  5400RPM  7200RPM 10,000RPM & 7200RPM  
Scenario 1A Run 1 18.48 25.16 26.76 17.67 36%
Run 2 18.21 25.63 21.71 17.53 41%
Run 3 18.66 25.94 21.7 17.36 39%
Scenario 1B Run 1 17.31 25.89 20.68 15.79 50%
Run 2 17.02 24.04 20.83 15.74 41%
Run 3 17.05 23.3 21.27 15.4 37%
Scenario 2A Run 1 02:09.50 03:04.48 02:45.51 02:19.46 42%
Run 2 02:07.96 03:03.71 02:40.45 02:19.36 44%
Run 3 02:09.40 03:03.94 02:44.04 02:19.18 42%
Scenario 2B Run 1 02:05.90 03:05.99 02:36.93 02:17.30 48%
Run 2 02:08.44 03:05.76 02:42.41 02:17.60 45%
Run 3 02:08.03 03:05.68 02:37.24 02:17.36 45%
Scenario 3 Run 1 04:32.42 06:41.30 04:04.74 02:55.43 47%
Run 2 04:16.23 07:12.21 03:55.35 02:58.62 69%
Run 3 04:22.14 07:04.65 03:45.49 02:56.92 62%
Scenario 4A Run 1 04:07.97 06:03.83 05:22.14 04:32.37 47%
Run 2 04:06.90 06:04.78 05:27.27 04:30.18 48%
Run 3 04:06.63 06:03.47 05:22.65 04:29.41 47%
Scenario 4B Run 1 02:30.94 04:19.15 03:39.78 02:23.07 72%
Run 2 02:30.15 04:14.75 03:31.28 02:23.98 70%
Run 3 02:32.83 04:14.65 03:32.82 02:23.95 67%

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.


10. March 2009 11:12
by Troy

SQL Server Gotcha - Cannot open database requested in login 'dbName'.

10. March 2009 11:12 by Troy | 0 Comments

So I had a good fight today with a SQL Server 2008 connection that would not work.  The error was:

Cannot open database requested in login myDbName. Login fails. Login failed for user 'myDbUserName'

 This was dumbfounding.  Troubleshooting the usual suspects, the following were attempted:

  • check the database server to ensure that the database exists
  • check the user login to ensure it exists, check the permissions for the user for this database
  • try to connect using SQL Server authentication using this username and password from the Enterprise Manager - this works perfectly fine - but the ASP.NET application still gives this error
  • double, triple and quadruple check the connection string for the ASP.NET application - no problems found
  • drop the database and the login, recreate and try again - no difference
  • reboot the database server - no difference
  • check the event log for error messages - only the one displayed above is shown - nothing else out of the ordinary


I finally figured out, after a couple hours of head-scratching, from going through some event logs within SQL Server Enterprise Manager that the database name had 6 space characters appended to the name. Therefore what appeared in Enterprise manager and everywhere else as "myDbName" was actually "myDbName      ".  Something is obviously wrong with our MSBuild script which is autogenerating the database for us during the build process... I still have to figure out how it happened, but at least now I know why it would work in Enterprise Manager and not from the application.  The app defines the connection string explicitly (with incorrect name missing spaces), while EntMgr connects and gives you a list of databases to choose from, so you never need to define the database name.

Once I renamed the database to remove the blank spaces, everything worked again.

I confirmed my theory by running this query, which highlights the extra spaces:

SELECT '"' + name + '"' FROM sys.databases

Ahhhh, the world makes sense again.