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.
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.
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.
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.
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.
For more on team spaces, read Collaboration cache—colocation.
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.