Office Space, Part 2

Brent's post on Office Space requires some additional commentary on my part.

Just to qualify, at an older institution like JPL there are some pretty cozy, and fairly randomly organized engineering spaces that were repurposed from older offices in 1950's era buildings. The older part of the Spacecraft Assembly Facility for example--where 10base2 snaked through the building and the wooden floors creaked.

Yes we've got the Dilbertian cube farm disease pretty badly here. It's unfortunate that most of the engineering office space decisions were dictated by the old owner--who was about as out of touch with the creative process as a human could possibly be. Additionally, pragmatic modifications to the layout or configuration require that you engage the highly bureaucratic facilities department that contracts the work out to an expensive outside company. The result: a soul crushing cube farm that cannot be easily tuned or improved.

Smaller companies and companies for whom creative work is a primary product (like Google) have it lucky in the creative worker's environmental department. This difference is a barrier to competitiveness that I don't think management really appreciates.

The solution isn't hard--simply recognize the differences in work environments required for different types of work. At a company such as ours which does manufacturing, we know that the production floor requires a different type of environment from (say) accounting. As should engineering work.

Just because a work environment is different doesn't mean it has to be more expensive. Start with a different set of goals--mainly to balance privacy with collaboration and provide enough variety to culture the muse. Then implement towards those goals at a reasonable cost.

How Do I Manage Seasoned Programmers?

This recent post on Slashdot caught my eye. My advice:

Take genuine and deep interest in what they do. Celebrate their successes and get involved in their problems. Most programmers do what they do because they enjoy the work. They want somebody to appreciate their work, and they want somebody to understand the difficulties.

Understand what excites them and brag on this work. Be clear about obligations, deadlines and expectations, then ask what you can do to help. Take requests for help seriously. Your role (as a manager) is to be of service to them, not the other way around.

Spend time with them one-on-one to find true problems and understand the good things. Also spend time with them in a group (short daily meetings are a requirement), and look for recurring themes that could be problems that need your attention. Also look for issues of interpersonal dynamics within the group. When you see the "elephants head in the corner" bring it up point-blank. Preferably to the entire group. Facilitate the use of the group's skills to solve the problem.

Look for a member with leadership skills (who may or may not be the best technically). Delegate to them. The amount of delegation depends on if you'd like a backup, go-to guy who can solve unexpected problems when your gone, or if you'd like to train your replacement.

Martin Fowler on DSLs

Martin Fowler's post on Domain Specific Languages reminds me of the time we did a study of user performance of a graphical workflow editor. The graphical workflow editor is really a DSL represented with a graphical user interface. The domain is workflow automation. The language is some workflow description language--or in this case the graphical tool used to write the workflow description.

The purpose of the study was to see how programmers and non-programmers fared when given the same tool and same tasks. The results were very different between the two groups. If I remember correctly, the programmers were more rigorous and accommodating of edge cases and logical fallacies in the task. Whereas the non-programmers plowed through the task without regard for "what if" situations where the workflow could get stuck or produce the incorrect results. The users had different intentions, with the programmers looking for accuracy and correctness, and the non-programmers looking for simple automation.

The point is that there's more to the task at hand than the tools. Besides the obvious "skills" related issues, there's also the user's intent. If we give everybody guns, will we need police any more? If you assume everybody has the same intentions as the police (to uphold the law), then I guess not.