In 1990, Mihaly Csikszentmihalyi published his famous book about achieving exceptional productivity and concentration, Flow: The Psychology of Optimal Experience. The book’s basic idea is a familiar one to most developers: Situate yourself in a quiet room without distractions, work on a compelling piece of code, and you’ll soon get into a “flow,” losing track of time and feeling insanely productive. For developers, flow is a little slice of nirvana.
As a longtime developer, I love flow. Flow is such a captivating state of mind, and seems so productive, that most developers and managers believe it is the ideal way to work. They curse open spaces that are full of disruptions, yearning instead for single-person offices with doors. They quote statistics showing productivity losses due to distractions. They are so very right, and yet, so very wrong.
The fallacy of flow is that it leads to desirable products completed more quickly by ensuring that developers are always in flow. It doesn’t. It leads to crappy products—late, misguided, customer-hated products. How can that be? Because the goal of commercial software development isn’t to create code you love—it’s to create products your customers will love.
A time and place
Flow is very important. Working in a quiet room not only removes unproductive context switching and frustrating distractions, it also promotes the joy of being totally engrossed in your task—a state often needed to keep all the complex interconnections in your head.
However, flow necessarily requires isolation. Isolation from design discussions. Isolation from customer engagements. Isolation from iteration and feedback. Instead of continuously converging on what the customer finds compelling, you go forward alone.
Maybe being a solo artist is fine for a startup, a hobbyist, or a researcher (actually it isn’t), but flying solo is a disaster for a commercial software developer. The customer must be at the center—not your self-absorbed mind in flow. Flow has its place, but it can’t replace the customer at the core.
I want to be left alone
To align yourself with the customer, you must constantly be engaged with your team, so sitting together is the ideal environment for developing. However, having people from other areas in your team space is a disaster—the least productive situation. Still, you want to be as close to each other as possible in order to engage in reviews and feedback before heading off course.
As for flow, it works best when there is a specific, narrowly scoped piece of code that must be written. For that work, being in a quiet place free from distraction is ideal. Just don’t stay isolated too long. Flow is intoxicating and addictive.
If you stay away from your team for a couple of weeks instead of a couple of days, then you’ll quickly lose touch with the team and the customer. You’ll super-productively produce super-sucky product.
The code might be technically perfect, but it likely will be far removed from what the customer desires. Remember: a McLaren P1 driven in the wrong direction for a week will take you much farther than a Ford Focus driven in the right direction, but the Focus will get you far closer to your destination.
Eric Aside
One of the 54 rules in the Dynamics of Software Development is “Beware of a guy in a room.” Nothing can sink a product quite like an individual who shuts his door and goes dark. Yes, flow is great, but sometimes productivity can be hazardous to your health and your project.
All for one, one for all
If you’re a manager, you need to make your team productive as a whole, not as individual parts. What matters to customers is the whole deliverable, not any particular check in.
Ideally, you’d have an isolated team space that also affords privacy for flowing individuals. The perfect setup would be a central team space surrounded by sliding-door offices, but instead, most “team spaces” are usually just open spaces with all kinds of distractions and inadequate headphones. The best team spaces on Microsoft’s Redmond campus are team hallways—three to four offices with doors on each side of a shared hallway, apart from other teams.
If you can’t get a team hallway, and must choose between headphones or having your team widely separated, I’d still choose the headphones and encourage engineers to find quiet places as needed. It’s a tough call, but flowing in the wrong direction gets you nowhere.
Eric Aside
For more on team spaces, read Collaboration cache—colocation.
No man is an island
I know it’s romantic to think that one person can create an incredible product in isolation. If that’s what you believe, stick to reading romance novels, and stay the heck out of software development.
Real products require real teamwork. Nothing substantial exists in isolation. Teamwork only happens when teams discuss together, design together, and deliver together. Specific, narrowly scoped parts can be done with individual flow, but that can’t be the primary thrust of the effort.
We don’t win when one person completes his piece. We win when everyone comes together, with the customer at the center, to create something far bigger than ourselves.
Wow. It's hard to believe how badly you misunderstood the concept of flow as a tool. Truly, you couldn't have got it more wrong.
Let me use a metaphor: exercise offers enormous mental and physical benefit and can help a person work more effectively. But only a total and complete moron would write an article called 'the fallacy of exercise' in which they argue that if you exercise all day long, you won't get other work done.
This is the mistake you've made. Flow is a great state to be in. It's highly productive and useful for burning through operational tasks. But it doesn't mean that the person has become a self-contained unit. It doesn't mean that there aren't still customers, markets, and a world to interact with. It doesn't mean the person no longer needs to collaborate or information.
Flow is a tool that's useful when you have already gathered all the information you need to complete a particular work unit, and you want to burn through it efficiently and effectively.
That's not a metaphor. It's an analogy.
/trash
/trash
/trash
/trash
/trash
/trash
How is it possible to so fundamentally misunderstand the concept of flow? Or perhaps the author was just looking for a link bait of any kind and ended up choosing this one.
That exercise analogy doesn't work because it is presumed that the exerciser is not working while exercising.
The problem I have with the article is that flow time granularity can be sufficiently small to accommodate all necessary interruptions. With asynchronous communications via chat and email (and maybe the occasional pone call), all necessary information can be communicated in sufficient time. The need to so frequently that flow is constantly interrupted is a sign of other problems. Good teams will communicate as needed despite the workspace and any imposed communication patterns.
Flow doesn't mean code 10 hours without interruption. It means having at least one sufficient block of uninterrupted time each to day get work done.
Good remote teams do this every day. I haven't met most of my team face to face. We are very productive. and we can turn on a dime.
I guess it shouldn't surprise anybody that a blog called "I. M. Wright" contains badly misinformed screeds by incompetent middle managers.
In my experience, customer happiness correlates strongly with developers in flow. When you're in flow you can pick up customer requests very quickly. That's just what customers like.
Isolating team members so that they can individually achieve flow is more the topic of this essay.
I'm confused. You spent the first half of this post arguing how important it is for programmers to be in the presence of the customer (9 of the 11 instances of the word "customer" appear in the first half of this post). Then you spend the second half of the post arguing how you solve this by putting the programmer with their team (10 of the 14 instances of the word "team" appear in the second half of the post). Finally, you conclude by going back to the original assertion that programmers should put "the customer at the center".
If you believe that access to the customer is the most important part (and you're not alone here: Kent Beck has been saying this for years), then why is the customer conspicuously absent your "perfect setup"?
I think you have a good point in here somewhere, but I'm not sure exactly what it is. As it stands now, it's a classic bait-and-switch.
There's an assumption here, made but not supported, that the other team members are more in touch with the customer than any particular developer. Is your assumption that, in aggregate, the rest of the team knows more about the customer's desire? Are the other team members to be used as a proxy for the customer in design discussions? Or are there specific team members who know more about the customer whom the developer should be in closer communication with?
I also agree with the other commenters that you can get a good flow period for, say, an afternoon, allowing high productivity on an individual task without going off track. Talk to your team members to come up with an idea/design/goal, but let the developers be maximally productive while implementing it.
Wrong, wrong, wrong. If one were (as you assume) in complete isolation when in "flow" how would you have anything to work on? Instead of thinking about flow as requiring complete isolation, think about a swimmer doing a butterfly. They're up taking a breath, then down under the water swimming, then up again.
Heh. I draw the foreverscape alone and in isolation. it's just fine. I code in isolation. Never had an upset customer.
Do you have any actual data to back up these assertions? Did you speak to individuals at Microsoft and get their thoughts about how software teams should be located? I think that some teams use a more open environment e.g. Xbox, if memory serves. Did you talk to any of their managers and get their opinions on this subject vs., say Server division, where I work, where we pretty much stick to the old one-developer-in-an-office-leave-me-alone-I'm-coding model. And FYI just for the record, we've been able to ship a few products that have made money for the company.
Yup, right to target that assumption. This column doesn't hang together, and is well below the general standard of the blog.
I was going to add some witty reply, but it looks like Eric is getting the savaging he richly deserves.
some additional points:
even ignoring Eric's lame strawman 'flow', offices are far superior to open space. Open space is good for social aspects of you job – but not for all the time (that's all you get).
Eric sits in an office, so I guess he needs flow or something? move out and maybe you'll have more credibility.
I like to fart in my office, and eat microwaved curried salmon with garlic and steamed kale. Perhaps it would be better if I confined my odors to my office and didn't share them? Perhaps everyone should have that privilege and not just Elite Eric the build guy?
I like loud music with objectionable lyrics and high-end open-back headphones, I don't think my co-workers need to hear it.
I have employees that commute long distances and would love to sleep in their offices to stay late and work more – but they don't have offices, so I (and the company) are robbed of this extra productivity.
I have employees that really can't concentrate because they sit in a high-traffic area, so they spend valuable time going to the library to find a cubby.
I have employees that don't like the way other employees smell. So I get to deal with Mr. Stink's lead, and he gets to deal with Mr. Stinkbutt. Now we've wasted my time, a leads time, an employee subjected to funks time, and Mr. Stinkbutt's time.
Customers aren't sitting in our open spaces, you are making quite a leap when you suggest that sitting together == customer connection.
seriously Eric, every advantage you mention is covered by IM, CodeFlow, and available meeting rooms. You clearly don't need that office you occupy, I suggest you go fins somewhere else to sit (like at Google.)
"To align yourself with the customer, you must constantly be engaged with your team"
I think _this_ is actually the most fundamental fallacy. Developers don't build the wrong product because they don't talk with their team. Teams build the wrong product because they "group think" themselves into believing either a) they "understand" the customer, when their world view is fundamentally different in big ways b) they are "smarter" than the customer, i.e. they "know" what the customer "really" wants OR c) They bleed in their own organizations requirements so much that the customer's needs are drowned out in a sea of architectural mandates, business-marketing must haves, or company directives that really don't serve the end customer at all.
In any semi-functional shop, despite common lore, Developers rarely get to "cowboy" in functionality that won't immediately get bugged out of existence. Developers who do this repeatedly either get shown the door or promoted. 🙂
"If you stay away from your team for a couple of weeks instead of a couple of days,"
You are capable of staying in a flow state for a couple of *weeks*?!? Wow. Most of the rest us have to break flow to eat, eliminate or even just sleep *at least* once every 12 hours or so.
I enjoyed this article. Thanks for your insights. I look forward to your posts every month. Keep up the good work!
Your words are less useful than a downvoted Stack Overflow post.
A very thought-provoking essay. The question is really about local optimization vs group optimization.
I used to be firmly in the "separate offices, flow" camp. I loved – and still love – the feeling when you realize that two hours have just slipped away because I was so engrossed in a task.
But there are some big downsides to separate offices:
1) People regularly spend 30 minutes trying to figure out how to do something rather than just asking somebody because they would have to get up, walk down the hall, and interrupt somebody (assuming that somebody is there). IM helps *a bit* with this, but there's still a barrier.
2) It encourages the "lone coder" approach. You get designs that aren't as good, and much less knowledge transfer between team members.
3) You aren't a team, you are a group of people who work together.
I'm currently on a team who are all together in one room. As I write this, one of our team members is verifying a story with one of our product owners on the desk next to me, and four others are having an informal discussion at our scrum board. 6 feet away from me two other team members are pairing on some new code. This is an everyday sort of thing for us.
We have 5 different teams that are set up this way, and the vast majority (>90%) of the people would never go back to individual offices; they love the team environment. *However* – and this is a big however – you need to have a good physical design. Teams need to have small spaces they are dedicated to a specific team, and they need to not be "on display". If you have spaces with multiple teams in them and/or they are not really separate, you get a library, not a team room.
Working closely with a group of people in constant interaction is a different way of working. It takes some getting used to, and is not for everybody. But I encourage those who have never tried such a way of working to consider experimenting with it. If you have questions about how our teams work, I'd be happy to answer them.
Imagine writing great poetry by committee. Blah!
this was good. http://www.fastcompany.com/…/offices-for-all-why-open-office-layouts-are-bad-for-employees-bosses-and-productivity
"Flow doesn't mean code 10 hours without interruption. It means having at least one sufficient block of uninterrupted time each to day get work done."
Exactly. There are days when I have less than 30 minutes alone without interruption.
When I was in open space, I got work done early in the morning when no one else was there, or when others were at a meeting. With an office, I still get interrupted a lot, but not nearly as much as when there were five different people whose interruptions could interrupt me.
That said, I wouldn't mind going back to open space if I was actually sitting with the people who were working on the same things I was, across disciplines, without distractions unrelated to my work, then we could do TDD and pair programming and be way more productive than me alone in my office. So far at Microsoft, anyway, I haven't seen any open spaces designed like this. I also haven't seen any teams who want to make the effort to move people every time they change the tester or PM working on the feature.
The theory that you could make teams more effective by shaping the environment they work in without any consideration for their members personalities is wrong.
jobs is an island who create ipad. he insists himself.
the evidence that open office plans suck continues to roll in : http://www.newyorker.com/…/the-open-office-trap.html
and Eric still has his office…