Books like Peopleware reported studies emphasizing the importance of providing a distraction-free environment for developers to achieve high productivity; however the pair programming movement seems to discount the idea that developers need a quiet place to concentrate to do their best work. Certainly there are trade-offs. As I've heard it said, more often than not whatever issue your having, someone around you probably already has the answer. I am currently working in a noisy open environment and have become more and more aware of the difficulty of getting into "the zone". Although programming gets done, it seems that my thinking is at a very shallow level. I find it hard to hold several concepts in my head at the same time or switch between tactical and strategic thinking. I easily "lose my place" and have to constantly restart the sequential process of analysis. I find myself craving that quiet moment to truly concentrate - to slip into a state of flow, so much so that I am more likely to stay late or work from home just to get that experience. There must be some way to find the right balance between the benefits of collaboration and the need for extended concentration.
Beginning in the era of the industrial revolution, managers were trained and encouraged to focus on increasing productivity though increased efficiency. This trend has continued into modern management with techniques such as Total Quality Management that focus on identifying and eliminating waste in a system. It can't be denied that this approach can be very effective when applied to a consistent, repeatable process like a manufacturing assembly line. However, this focus on efficiency is inappropriate and even detrimental when applied to creative, problem solving activities like software development, and unfortunately these lessons learned from manufacturing dominate the way software development is organized and managed. It even influences some of the practices taught under the banner of Agile. This fallacy, that software development can be organized into consistently repeatable processes, was the assumption of the waterfall methodology. Software developm...
Comments
Post a Comment