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.

I started thinking about putting a plan together for attending conferences.  I started doing some research about the different conferences that were geared towards the Microsoft Technology stack, or that were of interest to me.

As the information I gathered started to grow, I decided it might warrant a blog post.  Some of the events noted have already passed, as the collection of the information has been a bit of work in progress during spots of free time.

I blogged about TFS and the maximum file path length issue a while back, and thought I had covered it pretty well.  However, the issue came back to sting me again, so I thought it deserved another post.

Our issue was, sometimes, but not all the time, we would get this error on our team build on the build server (but the local developer build would always work fine).

[Any CPU/Release] CSC(0,0): error CS0006: Metadata file '..\..\..\..\SharedAssemblies\MSApplicationBlocks\Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll' could not be found

It took some time to figure this out... the path was correct on the server and the DLL was there.  Now if you are the intuitive type, you may have already guessed from this blogs title that the problem is related to Windows path length limitation, but why was the problem intermittent?

It turns out that this assembly reference was on a VS.NET Team Test Unit Test project.  When you used the right click "Create Unit Tests" menu to create a new test, the wizard automatically adds assembly references, including a reference to this ExceptionHandling.dll.  This would break the build on our build server.  Our quick solution was to remove the reference from the unit test project, everything still compiled and it didn't seem to be needed.  The builds now worked again on the build server, UNTIL someone added a new unit test and the cycle would start over again.  This explained our intermittent problem.

It still didn't explain why the build failed when this assembly was referenced, until I happened to find this blog entry... the same blog entry I noted in Part 1 of this blog series, but I didn't connect the dots until now. Aaron's blog entry talks about the 260 character path limit, but doesn't mention the error message we were seeing.

It turns out, that for our unit test project,  this ExceptionHandling.dll reference was the longest path of all of them, and was just long enough to be too long, but ONLY on the build server.  The way the build server paths are structured is different than our dev boxes, which was shorter by about 25 characters and this explains why the build would break on our build server but not on our local boxes.

The other severely annoying thing is that the actual error message mentions NOTHING about the path length... just that the file cannot be found.

Using Aaron's tip about these variables ($(BuildDefinitionPath) and $(BuildDefinitionId)) in the properties of the Build Agent I switched to using the $(BuildDefinitionId) which shortened the path on our build server by about 23 characters.  Now the builds always work.

The moral of the story is... if you see the error message above, double-check your path lengths.

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

WTF?

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.

This story actually starts over a year ago when I decided that I might like to upgrade my computer.  I used to be an avid gamer... that dried up a little, but partly because my hardware was a little deficient for the latest titles.  I don't play XBox or any of the other consoles... I just never got into them.  When I do play video games, they are on the computer.  These days, it is probably more like 85% power user and 15% gamer.  I don't need the latest and greatest hardware, but it is a nice indulgence once in a while.

As I said, I started doing my research for new hardware over a year ago.  I got about half way through picking components, and got sidetracked by something else.  By the time I got back to it a couple weeks ago, I had to start all over again.

For this upgrade I would be replacing almost the entire box and its contents.  First a look at what I am replacing:

• AMD Athlon 64 3400+ CPU @ 2.2GHz (socket 754)
• ABIT KV8 Pro v1.1 motherboard
• 1GB RAM Kingston Value RAM PC3200
• 200 GB Western Digital Caviar SATA WD2000JD Hard Drive (Configured with a 12GB System partition and a 188GB Data partition)
• DVD-RW - NEC ND-3500A
• ATI All-In-Wonder X800XT Video Card
• Cambridge Soundworks 4 Point Surround speakers
  
• Windows XP SP2

It is a bit funny to look back now.  I first got the CPU in November 2004.  Back then, 64-bit computing was going to be all the rage, and I thought my purchase would help to future-proof my machine.  Well, here we are 4 years later, and the machine never did see a 64 bit operating system.  Only now are 64 bits becoming more adopted and stable/supported enough to make the switch.

During this round of research, I was surprised to discover that SLI (Scalable Link Interface for the semi-techs - "hooking up multiple graphics cards together so they work as one" for the non-techs) had made a comeback.  However, I was disappointed to find out that NVidia had held exclusive licensing rights which meant the only chipset that supported SLI was the NVidia nForce chipsets.  Based on what I read, these chipsets are generally of lesser quality than their Intel based competition.  So it seems that choosing a motherboard/chipset now required you to choose which video card manufacturer would get your business (ATI or NVidia), because if you wanted to support SLI (or CrossFireX) then support from the motherboard was required.

This powerplay by NVidia has finally come to an end with the X58 chipset from Intel.  This is the latest chipset that supports the latest socket 1366 Core i7 CPU's recently released from Intel.  These processors are quad core and represent the first round in some fundamental changes to CPU architecture, compared with their predacessors.

Now normally, I am an analytical, common sense kinda guy.  I don't buy brand new cars... I buy 1 year old with 30,000 KM on them.  The same goes for computer hardware, don't buy the latest, greatest model of anything otherwise you pay through the nose now, and in 6 months, the same item can be had for 1/2 the price.  I would much rather buy the 2nd generation product and save money.

<beginJustification>
This time, I couldn't get over the NVidia chipset thing.  I wanted to try NVidia video card(s) this time, because I had seen first hand some of the low quality drivers/software created by ATI over the years.  To be fair, my research indicated that ATI has gotten better in the last year or two... but I still wanted to try walking on the green grass on the other side of the fence this time.  Choosing NVidia meant wanting to support SLI (just in case I ever move to 2 cards).  Supporting SLI meant being forcefed the nForce chipset, or bite the expensive bullet and jump to the top of price mountain and go for the X58 chipset that supports both SLI and CrossFireX.  Guess what I did.
</beginJustification>

Edit: Well, about 2 or 3 weeks after buying my nVidia GTX280 based video card, they mothballed that model in favour of the GTX285.  I guess I won't be going SLI anytime soon.  I do still like the versatility of supporting both ATI and nVidia though.

Now, for a look at what I upgraded to:

• Intel Core i7 920
• ASUS P6T Deluxe motherboard
• 6GB RAM G.Skill PC10666 triple channel
• 150GB Western Digital VelociRaptor WD1500HLFS (10,000 RPM for System Drive)
• 1TB Western Digital Caviar Black (Data Drive)
  
• DVD-RW - NEC ND-3500A
• XFX GTX280 1024MB Video Card
• Coolermaster Stacker 830 Evolution case
  
• Logitech X-540 5.1 Speakers
• Windows Vista Business x64

So far, things are running great, and I am happy with the upgrade.

After returning from PDC 2008, I've finally had a chance to process some video that I recorded of Scott Guthrie who participated in an Open Space meeting for about an hour.  Unfortunately, I only recorded about 15 minutes of the action before my memory card filled up, but I guess that is better than nothing.

I did my best to clean up the audio, which had alot of ambient room noise.  I wish it could be better, but I think it is clear enough now to be understandable, if not somewhat enjoyable.

The video is hosted on YouTube and due to time restrictions on uploaded video, the content is split into 2 parts. 

In the first part,  Scott talks about:

• ASP.NET and MVC Framework - the future of both and them co-existing with each other
• Data Access - LINQ and the Entity Framework

In the second part, he discusses:

• Functional Programming - programming WHAT you want done, versus the more typical HOW to do something, citing LINQ as a simple example
• Moore's Law - gradually being replaced by new rules where the number of machine cores will begin doubling
• Parallelism - efforts to make it easier for developers to take advantage of multiple cores through explicit APIs and implicitly through improvements to the CLR
• F# and .NET 4.0
• Dynamic Languages
• WPF and Silverlight

Part 1
http://www.youtube.com/watch?v=9-62sSDTIMY

Part 2
http://www.youtube.com/watch?v=lXm60VnyZwo

I just got back from the PDC 2008 in Los Angeles where Microsoft unveiled their plans for Windows Azure.  Azure is their answer to computing in the cloud.

After having spent nearly an hour at the Azure desk, speaking with a Group Program Manager from Microsoft, I was approached by a CNET news reporter and asked if I would be willing to comment on Azure.  They were looking for developer reaction to the announcement.  Of course I said yes.

The questions (and subsequent article) seemed like they were looking to find a negative angle to explore, but I don't think they were able to find one.  In the end, I think the article came out reasonably fair.

Azure has some challenges ahead, as were conceded by Ray Ozzie.  There will be companies who will not adopt computing in the cloud and trusting Microsoft is an issue for some.  However, I think that like many other technologies, it is right for some and not others.  Azure offers some definite benefits, and I for one, welcome the choice, regardless of whether or not it is right for my projects.

Not all of my comments were included in the article of course.  We chatted for probably 5 or 10 minutes, and only a soundbite quote made it into the article.  The quote is ok... it is neither overly positive or negative.  The intent of the quote was meant to be positive.  Prior to the quote that was used, I indicated that I would be evaluating Azure with an open mind for our projects.  I said that there were lots of third party hosting companies located in North America, and it was common for companies to pay for hosting, thereby placing their intellectual property into the hands of others and that requires a degree of trust.

The quote that made it into the article followed this, which basically said that I don't see much difference between paying for hosting with another company and paying for hosting within the Microsoft Windows Azure platform.  In fact, it appears that there would be additional benefits to the Azure platform than just simple hosting, including a number of open standards based framework services.

Overall, I was glad to be interviewed.  It was fun.  You can read the full article here:

http://news.cnet.com/8301-13860_3-10078496-56.html

 
               View from my chair at the keynote where Ray Ozzie announced Windows Azure.

260 Characters.  This seems like alot, and it is, however...

I ran into this issue a while back with an existing project I worked on and it was a royal pain.  When attempting to follow the naming conventions adopted for the folders and projects within a Visual Studio solution, the newly added filename + path exceeded this hardcoded limit within windows (many core Windows APIs still have this hardcoded limit, and many of the more recent APIs, including the .NET framework still depend upon many of these core APIs).  This issue became apparent when trying to check the file into Visual SourceSafe, when an error was thrown.

Now having moved on to a new project, and new technology (Team Foundation Server), I somehow thought that the issue would magically disappear.  Not so.

While 260 characters seems like alot, it is quite possible to hit this limit when you:

• use nice descriptive names for folders within projects instead of more cryptic abbreviations
  

• root your TFS workspace in a subfolder, that will ultimately add unnecessary characters to the total path (D:\work  vs. D:\CompanyName\ProjectName\Source) 

• use a VS.NET database project, which has its own built in folder structure (Schema Objects\Tables\Keys\) and file naming conventions, which if you have descriptive table names, means the file name of a foreign key constraint SQL file could be really long, just over 100 characters alone for the filename itself without the path in a recent database that I reverse engineered

There is no real fix for this that I have found, except using a shorter path.  Being aware of this limitation when setting up the naming conventions on a new project can save alot of hassle later on, and could avoid having to rename the existing files/paths or changing your naming conventions part way through a project to accommodate this limitation.

References:
http://www.shifd.net/post/2008/02/Maximum-file-path-length-in-TFS-Team-Build.aspx
http://blogs.msdn.com/aaronhallberg/archive/2007/06/20/team-build-and-260-character-paths.aspx
http://neovolve.com/archive/2006/11/09/So-you-still-can_2700_t-have-a-path-more-than-260-characters_3F003F003F00_.aspx
http://blogs.msdn.com/saraford/archive/2005/12/15/504240.aspx

Edit:  I've posted Part 2 on this topic here.