Developer Computers

This is a thought I had to a post I read this morning. Doug, who’s running a company that does software development, has published a post about Developer Computers. It is interesting to observe developers position vs. business people position. Yes, developers want the latest and the greatest, and if possible, something that will be still up-to-date tomorrow. Business people often do the opposite; especially highlighting the fact that developer’s appetite for new hardware is not justifiable. Being developer myself, I’d like to show a few things, material for a thought.

Developers are often (if not always) required to be highly efficient, productive, and make ROI as quick as possible. What developers use as a tool to create software? They use computers. Hardware it is. Now, imagine Formula 1 race driver to be expected to win a race with a “decent hardware”. Sounds ironic, doesn’t it? Well, let’s have a pick look at what (most of) developers run these days on the hardware to create software efficiently and with higher quality.

At a company where CI is practiced, running build, unit tests, and code coverage is a normal thing. So it’s no longer “a single window you should stick to”, i.e. IDE. Here a question of a single monitor is arriving – do developers really need multiple monitors? Well, context switching is proved to be counter-productive. How about context switching with windows switching? Reading failed test message AND being able to see the source code that caused the test to fail is helpful. Less switching.

How about the tools that we run? I cannot imagine developer working without tools for refactoring (Resharper or an equivalent tool). Resharper requirements, for instance, state it very clear:

image

Visual Studio .NET 2010 Beta 2:

image

If you ever played a game on PC, you know that minimum requirements are never enough. And these are not games, but tools. If you use IDE and applying good practices (like a class per file, proper projects/solution structure, etc.) then number of files is quite significant. That means a lot of work OS has to do with files being consistently moved around, updated, created, deleted. I am not saying developers should take a coffee break they rename a widely used class in solution, but I do see the frustration they experience when such a logically trivial operation takes more than just a few seconds. Would you expect business folks to patiently wait for a web site page to load within just 10 minutes? Barely can imagine that.

The bottom line is simple. If you want developers to be productive, allow them to concentrate on work by removing hardware impediments. Hardware is not as expensive as it used to be and is becoming cheaper and cheaper. Monitors, memory, hard disks, they are way cheaper than the valuable time it can save. Always consider if saving a buck today will cause you to pay ten tomorrow.

2 Comments

  • Hi Sean,

    My post started out as a "light" reflection on the differences in perspective between techies and management.

    After reading your post I was inspired to think about how to actually justify hardware improvements from a business perspective.

    With development this is not as easy as it sounds. I didn't want to take the easy way out either and just say spend XX dollars per year.

    The real goal should be to solve real issues and improve development team's ability to develop efficiently. To me this is what agile and continous improvement are all about.

    Cheers,

    Doug

  • Golden path is the ultimate. I agree, no predetermined amounts, each case should be reviewed and decided on it's own. Glad my thoughts could help.

Comments have been disabled for this content.