Smart Hardware Purchases for Developers

As developers, we spend a lot of time working on the ins and outs of software. But hardware plays a huge role in our lives, and it can make a difference in both the quality and quantity of the software we're able to create. I share my hardware purchasing secrets with you: desktop or laptop; multiple monitors—good or bad; buying speed for your hard drives; and what about those Solid State Drives.

Related: Transforming Retail with Mobile Apps

Some Lessons to Learn from Farming

There are two big lessons that developers and IT shops can learn from farming. First, spending money to make money makes sense. Just as increased adoption of mechanization and automation have boosted the productivity levels of individual, improved access to hardware for developers can boost their productivity and make built testing and validation logic that much more capable of creating better software. This increase in productivity can definitely translate into better revenues or decreased development costs for internal applications.

But the second lesson to learn is to spend cautiously: today's farmers are typically in debt to the tune of millions of dollars in order to afford all of the equipment needed to make them productive. A single bad season can reduce income enough to make them default on loans and ruin them financial ruin. So, while paying for increased productivity makes sense, it obviously needs to be balanced with some caution. With that in mind, I thought I would touch on hardware enhancements that have helped boost my productivity without causing me to bet the farm.

Related:
Mix10: Microsoft Unveils IE9, enhancements to jQuery, & SDK for OData

Desktops vs. Laptops

I'm always amazed at the number of organizations that think having their developers program primarily from laptops makes sense. Until I learned better, I used to be a pretty big proponent of laptops myself. By regularly buying what I called “kitchen sink” laptops (big, beefy laptops with everything in them including the kitchen sink), I was able to get decent enough processors and disks to handle development tasks without what I thought were any significant issues. But I found that I was frequently upgrading to new machines to take advantage of increased processing power. The reason for that, obviously, is that laptops aren't really built with expandability or extensibility in mind.

About two years ago I ditched using a laptop as my PRIMARY machine, and invested a bit of time in researching a desktop that I built myself. Above and beyond the benefits of an adult-sized keyboard, the performance I've enjoyed from this machine over the years has been beyond reproach. More importantly, by upgrading components here and there (more RAM, better disks, and so on), I've been able to keep my primary desktop insanely fast and responsive. Now I think that I’d only buy a new machine (fully two years later) for fun, not out of necessity. For example, I currently have a 5.4 performance score in Windows Vista; another $400 would let me get a 5.9 if I wanted it by upgrading to some faster RAM and a slightly faster CPU. More importantly, if I want to upgrade to a new Core i7 processor, I just need to buy a new CPU, motherboard, and some RAM, which I could do for much less than trying to find a new kitchen-sink laptop that was beefy enough to meet my needs.

So, from atop my soapbox, I'd encourage anyone within the sound of my voice to drop laptops as primary developer machines wherever possible. Yes, your developers may still need a laptop for on-site meetings and such. But unless you're actively developing in multiple locations, just get a smaller laptop or net-book that meets your mobility needs, and save your budget for a more beefy box back in the office where you're actively writing and testing code. With a well-purchased desktop you'll have vastly increased upgrade options, and you'll find that each time a new version of Visual Studio ships you don't need a brand new box to actually take advantage of all of the features.

Related: Mobile Web Is the Web

Multiple Monitors

The benefits of multiple monitors have been touted to death on the web. So I won't belabor the point here, other than to say that if you're not using multiple monitors in your primary development environment, then you're taking a massive productivity hit. In fact, traditional sentiment is that a second monitor adds about 20-30% to productivity, but I'd personally suspect that it's just a bit higher for developers as we're frequently engaged in activities (such as debugging) where not having to switch back and forth from one screen to another can save us a lot of time. Best of all, multiple monitors typically don't cost that much. In fact, a top-of-the-line 20" widescreen can typically come in at less than $200—a paltry amount to spend in order to pick up a greater than 20% productivity boost.

I loved having a second monitor so much that I actually picked up a third, and it's been a great boost. I even toyed with four monitors (and since I've got 2 video cards I can technically pull it off), but that actually became a bit ridiculous in a hurry, and really didn't provide ANY productivity boost. In fact I know of a few people who would prefer two monitors to three—so make sure to match your needs, wants, and workflow correctly.

Faster Drives

The best way to get a faster hard-drive is to get drives with the fastest rotation speed possible, because faster rotation speeds yield decreased seek times and improved throughput. Consequently, a 7200RPM drive is roughly 30% faster than a 5400RPM drive. Likewise, a 10,000RPM drive is 30% faster than a 7200RPM drive—and nearly twice as fast as a 5400 RPM drive. In server environments, disk speed (and bus type/speed) are critical considerations for success when provisioning new systems, but spindle speed frequently gets overlooked when purchasing commodity desktops and laptops where 5400 RPM drives are a common occurrence.

Scott Guthrie actually touched upon the benefits of faster hard-drives a while back in a blog-post dedicated to improving Visual Studio performance. And, happily, even if you're running a laptop, it's pretty easy to switch to a 7200RPM drive if you find you're running a 5400 RPM drive. Even better, if you're using a desktop (that supports an SATA bus), then 7200 RPM drives are a dime a dozen, and you can even swing for 10,000RPM disk for pretty cheap. This will provide some great throughput, improved build times and speeds, along with making your overall system a bit peppier and more responsive.

Since I work with Virtual Machines and video a lot, I'm also a huge proponent of using RAID-0 as a way to boost disk performance. For the uninitiated, Wikipedia's summary of RAID-0 provides a quick overview of the benefits of using a RAID-0. A RAID-0 (also known as a stripe set or striped volume) splits data evenly across two or more disks (striped) with no parity information for redundancy ... RAID 0 is normally used to increase performance, although it can also be used as a way to create a small number of large virtual disks out of a large number of small physical ones.

The key to figuring out whether a RAID-0 will be beneficial to you is in knowing a bit about the stripe-size used to split up data between the members of your RAID. Typically this stripe size is between 64KB and 128KB, so any files you access or write that are smaller than this stripe-size won't be able to benefit from having a RAID-0. Given that the VAST majority of operating system and application interactions with the disk-subsystem are with smaller files, a RAID-0 usually won't give you tons of benefit in day-to-day operations. But, if you routinely work with larger files (especially if you're moving them around a lot) then you'll notice some tangible improvements from using a RAID-0. More importantly, having a RAID-0 on your system won't slow you down in any way, it ONLY offers performance benefits where possible.

Of course, there is a common sentiment among many gaming enthusiasts and developers that tend to discredit the use of RAID-0 in desktop environments - mostly because the performance benefits are strictly limited to larger files and because of some idiotic notion that having a RAID-0 puts your data at greater risk. Frankly, that notion is crap. To be certain: with a RAID-0 in play you're splitting data across multiple drives to the point where if a single hard-drive in the RAID-0 fails, you lose ALL of your data - with no exceptions. My retort to that worry though is that a physical hard-drive failure on a single (non-RAID) system is also going to result in you losing your data. In other words, if you care about your data, then you should be backing it up, whether you're running a single drive, a RAID-0, or even a RAID-1 or a RAID-10.

I've been running a RAID-0 for almost two years now, and it gives me solid benefits when it comes to working with video or when I need to shunt virtual machines around. It also provides performance boosts here and there, and every little bit counts, especially since running a RAID-0 comes with no performance penalties. The only downsides are that a RAID-0 requires a suitable controller, takes a bit of effort to set up (but once you set one up it's just like a 'normal' disk in that it can be partitioned, and you can deploy Windows to it, and so on), and that it requires at least two identical hard-drives. I'd also say that it requires some careful planning in order to make sure that you're regularly backing up your data, but that's a moot point as you should be doing that with a non-RAID system as well. On my system, for example, I backup any data that I care about every 30 minutes to another, onboard, non-RAID-0 volume and then make full backups nightly.

Related: Play It Again, Sam: Hardware for Your Exchange 2000 Environment

Solid State Drives

It has taken some time, but consumer-grade Solid State Drives (SSDs) are finally almost becoming feasible. In fact, I've been running 2 of them in a 120GB RAID-0 on my desktop for a few months now. For the most part, the experience has been fantastic and then some. Windows boots pretty quickly (around 14-18 seconds most of the time) and applications just FLY open. Outlook goes from closed to fully loaded (and already doing Send/Receive) in less than 2 seconds, or roughly 3 seconds if it hasn't been opened since a reboot. Likewise, Visual Studio just flies open and is totally ready to use in 2-3 seconds.

Since I'm running 2 cheaper MLC devices (I spent $250 total on them), I do however run into problems with stuttering when doing larger installs, or when Windows Update is going on. Some people suffering from these effects have made it clear that it practically cripples their systems. My experience hasn't been that bad, but I think it's either because I'm running mine in a RAID-0 or maybe because my controllers just somehow do a great job with queuing; I don't know for sure. This problem is annoying when I bump into it, but it hasn't been severe enough (or encountered often enough) to make me think of ditching my SSDs.

Importantly, the SSD industry and Windows 7 are taking active steps to ameliorate this problem—all while SSD prices continue to drop. Consequently, with a bit of research on internal SSD controllers, you should be able to find a relatively cheap SSD (or set of SSDs) with the new, non-stuttering, controllers. Better yet, given how much of a black-eye the SSD industry got over stuttering controllers, it's a fairly safe bet that the non-stuttering replacements will continue to filter out into the market and slowly replace their less performing counterparts, while prices still continue to drop. Likewise, don't fall prey to the idea that you need to get a huge SSD to store all of your data on. A 32GB SSD will work fine as a boot partition and let your OS and core applications run just fine, while you can store less-needed data on a cheaper SATA disk as needed in order to save a bundle.

Conclusion

With all of the suggestions I've offered, the trick to maximizing productivity is to avoid spending a huge amount on any upgrades. Moreover, since larger or huge upgrades can be disruptive, you can't just count productivity benefits against cost alone - as you'll typically incur some down-time with most of the suggestions I've outlined. But with a bit of planning, it's easy to boost system performance and developer productivity without spending a fortune.