Thursday, July 30, 2015

The Library and the Bazaar

In Christopher Alexander’s discussion of his Workspace Enclosure pattern, he mentions this interesting concept:

You should not be able to hear noises very different from the kind of noise you make, from your workplace. (Your workplace should be sufficiently enclosed to cut out noises which are of a different kind from the ones you make. There is some evidence that one can concentrate on a task better if people around him are doing the same thing, not something else.)

This is an idea that seems simple, perhaps common sense, but as I’ve come to realize through my investigations into office design, common sense is not so common.

Here’s a paraphrasing of the idea, as simply as I can state it:

Put things that sound similar together, and isolate them from things that sound different.

This idea (should) affect every aspect of office layout.

Here are some examples:

  • Don’t put people who talk on the phone often within earshot of people who don’t. Put the “phone people” together, away from the non-phone people.
  • Don’t put a copy machine and/or printer within earshot of desks. Machines and people make different sounds.
  • Team rooms: people who work day in and day out on a certain project should be sound-isolated from those who don’t. Overhearing someone’s conversation is a lot less annoying if it’s highly relevant to you.
  • Group non-work things together and sound-isolate them from work things. It’s cool if the microwave and the air hockey table can hear each other, but put a wall between them and any desk.
Nope Yep
Ping pong and desk bad Ping pong and lunchroom good

There’s a fantastic white paper written by the GSA called Sound Matters, which is free and a quick read. Within, they explain the concept of the Library and the Bazaar:

The contrasting needs of the modern workplace can be seen as “The Bazaar” and “The Library,” with different acoustic needs and responses appropriate for each.

“The Library” is an analogy for a workplace environment where both quiet and speech privacy are expected to optimize the ability to concentrate.

“The Bazaar” is an analogy for the expectation that the area is not private, where sharing is the norm… Noise is far more acceptable to workers in the bazaar and a high level of intermittent background noise is expected.

The workplace needs libraries and bazaars, with sufficient noise isolation between them. The problem with many trendy open-plan offices is how they place everyone’s workspace into a bazaar.

Which way to the library?
In staged glamour shots like this, no one has to work at these desks.

There’s a certain fantasy promoted by open plan enthusiasts about how surrounding your people with a sea of random conversations and noises all day will lead to serendipitous collaboration / synergy / magic. What I’d suggest is that the bazaar is the place for these conversations, not the library.

Even if you don’t believe in a private office for every individual, don’t force everyone into a bazaar.

Tuesday, July 14, 2015

Technicians Get No Respect

I believe one of the fastest ways we developers can lose the respect of so-called “business people” is to behave like technicians.

Technician

What do I mean by technician? Here are some things a technician might do:

  • Become visibly angry when a business reality compromises their carefully planned inheritance chain
  • Declare that they are blocked on implementing the automated notification system the business requested until someone tells them what the subject line of the emails should be
  • After hearing the description of a report the business would like to see, their response is, “Can I use D3?”

The technician thinks primarily in terms of technology and expects the non-technical person to adapt to this way of thinking when the two interface. As Chad Fowler explains in My Job Went to India:

You might be “just a programmer,” but being able to speak to your business clients in the language of their business domain is a critical skill. Imagine how much easier life would be if everyone you had to work with really understood how software development works. You wouldn’t have to explain to them why it’s a bad idea to return 30,000 records in a single page on a web application or why they shouldn’t pass out links to your development server. This is how your business clients feel about you: Imagine how much easier it would be to work with these programmers if they just understood what I was asking them for without me having to dumb everything down and be so ridiculously specific!

The technician believes that careful choice of technology is primarily what makes a software project successful. Peopleware tells us otherwise:

The main reason we tend to focus on the technical rather than the human side of the work is not because it's more crucial, but because it's easier to do. […] Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work.

If you find yourself concentrating on the technology rather than the sociology, you're like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, "The light is better there."

Imagine that you were feeling depressed and decided to see a psychotherapist. After an emotional retelling of your troubles and the pain you’re feeling, the therapist responded with, “Would you like me to treat you with Gestalt therapy, ACT, or psychoanalysis?”

Avoid being labeled a technician:

  • Exercise independent judgment regarding non-technical decisions. You’re not a code monkey!
  • Also, don’t foist technical decisions on non-technical people.
  • Care about the high-level objectives of the software you make. Show a holistic concern for the success of the project.
  • Ask stakeholders about the why behind the features they want.
  • Use the language of the business when talking to non-technical people (and as much as possible with technical people).

As you move from technician to solution provider, people treat you differently.

Further Reading