The art of interrupting software engineers
There seems to be a lot of misunderstanding about this article.<p>First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams:<p>1) All production programming is done in pairs, all the time.<p>2) Everybody sits in a shared team room at dedicated &quot;pairing stations.&quot;<p>3) The atmosphere is highly collaborative and friendly, and there&#x27;s always a low buzz of conversation in the room. Interruptions are normal and expected, as the team&#x27;s overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.<p>4) Requirements are conveyed verbally, not through written documents. Stories are short &quot;reminders to hold a conversation,&quot; not fully-fleshed out.<p>5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they&#x27;re on the right track, particularly about nitpicky details that are difficult to anticipate in advance.<p>Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers&#x27; points of view.<p>This material is not meant for people who aren&#x27;t on an XP team. It&#x27;s good advice for product managers who are.