30. January 2013 02:44
by Troy

Office Space vs. The Programmer

30. January 2013 02:44 by Troy | 1 Comments

The office is a place to get work done.  Why then, do so many complain they can't get any actual work done while "at work"?  This problem is common among most office bound employees, but I'm most interested in how it affects my field, The Programmer.  Specifically, how does the office space support or hinder the programmers' productivity?

There is no shortage of innovative office spaces out there, each with it's own advantages and disadvantages.  Everything from windowless plain white boxes to funky open concept, natural material spaces that invite the outdoors in and spur the imagination to wander.  When it comes to office space, some characteristics come to mind:

  • comfortable
  • no distractions
  • distractions
  • controlled dimmable light
  • natural light
  • quiet
  • moderate noise, hustle and bustle
  • no interruption
  • interruption and collaboration is great

I believe that all of those are important.  Of course the ones in bold represent the exact opposite of the others, with the exception of being "comfortable".  The reason for this is because my ideal office space depends on what I'm doing.  Programmers are most productive when they can get into "The Zone" where nothing else exists in their mind except what they are working on.  All of the items in bold support the ability to get into "The Zone", while the others usually serve to disrupt or prevent getting into and staying in The Zone.

Comfortable is the easiest item to deal with because it is constant, the need for it doesn't change with the type of work you are doing at that moment.  People always want to be comfortable.  Not being comfortable is a distraction so you want to get this right.  Office temperature and good equipment (desks, chairs and computer hardware) serve the employee and allow productivity.  A worker who is in pain from shoulder fatigue or shivering under a blanket will not do their best work.

The Zone is important for productivity.  Being knocked out of The Zone is costly for the business, because studies show that once a developer drops out of The Zone, it can take at least 10-15 minutes before they can become productive again and get back to where they were at the time of interruption.

Getting back to our office space, lets consider some of our options:

Office TypePromotesGood For The ZoneGood For Collaboration
Open Concept distractions, natural light, moderate noise, collaboration, hustle and bustle No Yes
Cubicles reduced distractions, natural light, moderate noise, reduced hustle and bustle A bit better It Depends
Individual Offices no distractions, controllable light, quiet, no interruption Yes No

So, it looks like we can maximize collaboration or The Zone, but we can't have an office space that is best for both.  Personally, I'm not really a fan of cubicles.  I'm not sure that their cost is worth the little bit of privacy and reduction of visual distraction that they provide.

What is the perfect developer office space?  An article posted on TechCrunch talked about Facebook's Mark Zuckerberg hiring famous architect Frank Gehry to design the ultimate space for employees to get their geek on.  Zuckerberg says: 

The idea is to make the perfect engineering space: one giant room that fits thousands of people, all close enough to collaborate together.

Ok, the largest open floor plan in the world sounds cool, and is something I wouldn't mind seeing, but I don't think my concentration level would ever approach The Zone in a room with thousands of people.  Of course, this level of extreme is beyond the scope of most corporations anyway, but the general idea is the same.  How can the business maximize employees and minimize the floor space needed?  Clearly the Open Concept floor plan wins if that is your primary objective.  Also gaining popularity is Agile Software Development which emphasizes collaboration with an open concept work area called a "bullpen".  It seems that the cards are stacked in favour of the Open Concept design.

Now, Zuckerberg is not oblivious to The Zone.  He also said:

It will be the largest open floor plan in the world, but it will also have plenty of private, quiet spaces as well.

If your devs are not chained to their desks because they use laptops and your building has enough space to create shared, private spaces that workers can move to when they want to find The Zone, that may be one option.  If workstations include multiple monitors, then the private spaces should be likewise equipped for this to be a viable option.  Even then, this solution may not be perfect, as the dev may lose access to visual cues they use when at their desk, like post-it notes, whiteboards, corkboards, etc.

This brings me to the first iteration of what my ideal office space might look like.  This assumes the use of Agile Software Development, which arranges its people in cross-functional teams of around 6 or 8 people.

The image above shows a mock-up floor plan that I think would work well for the following reasons: 

  • one team per office/room is cheaper than separate offices for each
  • collaboration is encouraged by placing team members together, with a center table they can roll up to
  • The Zone is supported by short dividers between desks to reduce visual distractions
  • keeping dividers short, collaboration is supported by allowing teammates to simply lean back in their chair to see each other
  • Agile is supported by whiteboards and/or scrum boards for the team along the bottom wall
  • The Zone is supported by a room with a door to reduce non-team related distractions
  • separating teams in different rooms allows each team to find their own rhythm, without disrupting the other, so one could be in The Zone while the other openly discusses a new feature
  • cross-team collaboration can be facilitated with meetings, or ad-hoc discussions around common areas like the lunch room or a games room
  • A company policy of don't knock, don't come in could support team-wide entry into The Zone for scheduled periods of time
  • An open door would invite collaboration with other teams at other times during the day

Now, some people will obviously wonder why headphones are not mentioned as a possible solution to some of these challenges.  For some developers, headphones work well.  For others, not so much.  I personally don't want to destroy my hearing with excessive volume because I am trying to drown out the others in my area.  Plus, headphones do nothing for visual distractions.

I think there are advantages and trade-offs to every office layout but this one provides a decent balance of the two extremes.  Programmers benefit from an environment that allows them to get into The Zone to get the work done, but a collaborative environment is essential for deciding what work to do.


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.