Impact of Solid State Drives for Software Development in a .Net World

                The real measurement of a software delivery department’s value to an organization is delivering the right business solutions as quickly as possible with high quality.  In this article I am going to focus on the quickly aspect.  There are many articles on this topic but there are few that talk about the simplest easiest improvement that is often overlooked – give your developers the most efficient machines that you can afford.  In this article we are going to talk about the options that you have for these machines and real world metrics on the ROI of those options.

            I want to mention that some of you reading this will consider this as a no-brainer.  However, before I started this proposal I looked around for some quantitative metrics and evidence and I did not find anything useful to use as an off the shelf business case.  I am writing this mostly for teams that need a little support on getting this accepted in their organizations.

                Just to put this in perspective, our team develops software on Microsoft .NET in C# using Particular’s NServiceBus platform.  It is an enterprise level application that is built with event driven architecture on top of SOA concepts.  The application itself is over 600K lines of code comprising 30 services with over 11,000 automated unit tests.  These projects are very disk intensive.  There are thousands of mainly small files in the Visual Studio project [if you are developing correctly – SRP!] that need to be opened, processed, and written.  Any delay in that file processing compounds the time to get anything done. 

                With laptops these days there are three main factors that you can upgrade to improve performance – CPU, Memory (RAM), and disk.  The conventional wisdom holds that CPU and Memory are the biggest performance bottlenecks. However, after provisioning developer machines with suitable multi-core CPUs and memory, the hard drives quickly become the key bottleneck. Our developer machines were originally provisioned with 7200rpm HDDs. Developers complained about how slow their machines were – but developers always complain, right?  We embarked on a detailed investigation.  First we looked at the tasks that the developers were doing daily.  They were compiling, standing up projects for manual testing, running unit tests, checking in files, and jumping back and forth with other applications to get requirements and communicate.  We benchmarked the time it took to run each of these tasks with the current standard laptop.  We then determined the number of times that a developer would do each task in a given day. 

                Next, we took a developer machine and cloned/replaced the disk drive to a solid state drive.  We then reran the same metrics.  The solid state drives decreased the daily task breakdown by 3,677 seconds per day.  Based on an average developer salary the cost of the drive was recuperated in less than four days.  Some additional findings were as follows: We did a benchmark test to measure the effect of hyperthreading and found no consistent measurable difference with or without hyperthreading. We attribute this to the I/O bound nature of the development process which negates the additional processing power available via hyperthreading. We also compared i7 CPU performance with i5 CPU performance using our benchmarks and found that we could obtain a significant proportion of the i7 development benefit from a lower priced i5 CPU which could offset the additional SSD cost. The observed benefit was consistent with having 2 non-hyperthreaded core on the i5 versus 4 non-hyperthreaded cores on the i7. We are currently piloting an i5 laptop configuration with our development team.

                One other area to consider is the effectiveness of the developer.   I have been writing software for over 20 years and I can tell you from experience that any disruption (email, phone calls, loud coworkers, etc.) while I am in the zone slows me down exponentially.  Anything that slows me down from debugging, testing, or getting information I need in my train of thought can be a disaster that can add wasted minutes to hours to my tasks (and my project schedule). The SSD upgrade helped make developers more effective and lowered the aggravation caused by delays in such multi-tasking.  

                In the end with the hard facts the justification and selling it to the business was easy.  In fact, our efforts had an unintended side-effect. The productivity gains were so compelling that our Executives began requesting SSDs as almost the default configuration for their use and others. In the end as a technology leader seeing my team happy because they can focus on writing great software and solving business problems with less distractions is what makes me happy to come to work each day.

Jamie Romanowski        

For those that need the metrics to help with their justification – here you go

High Level Overview of the items to discuss and the differences between them.

Description of the laptops we used and the software we used for disk bench marking.

The raw differences between both drives for small and large files.

Breakdown of daily developer tasks and how often.

The overall ROI slide with an average developer cost [inclusive of benefits, etc.]