I agree interruptions are expensive for personal productivity.<p>However, these discussions very often commit a big mistake: the Ford mass production mistake of being too myopic, optimising too locally.<p>In an organisation there are many people working complex problems toward a common goal. You can optimise for local productivity, i.e. one programmer steams ahead, ignoring the rest of the organisation, and gets a lot done. But when local productivity is optimised at the cost of shutting down quick communication between people, the organisation will grind to a halt.<p>The programmer will, eventually, make the wrong things, in the wrong amount, and at high cost -- not to mention how the other people that needed help from the programmer will just hover around and not know what to do.<p>Or worse, but more likely: they'll improvise an incorrect solution to the problem. Eventually that solution will blow up and the programmer will have even more work to do to fix it.<p>This is similar to the problems Ford made for himself with the mass production paradigm, in that you can install a machine to really efficiently make parts for a car at a rate of 1,000 per second -- but if it needs to make them in batches of 50,000 and it takes hours to set up the batch, you're adding so many hidden costs to the process. Local optimisation can easily kill global optimisation. (Entire books have been written about this, so I won't expand too much on it.)<p>If you truly want good results, you can't take a myopic view of optimisation and only look at your personal ability to crank out solutions to what you think are the right problems.<p>For good results, you need to optimise the productivity of the entire system, and the entire organisation is a good start. (Later, you should include suppliers and other peripheral entities in your optimisation process.)<p>The inefficiencies of the organisation is, in my experience, almost <i>never</i> the ability of a programmer to crank out solutions to what they think are the important problems.<p>In my experience, the inefficiencies are almost <i>always</i> lacking communication. Failure to understand the important problems. Slow feedback. Code lying around not making things better for the users. Code written for a problem someone decided were no longer important. Bad documentation and internal support. Bad teamwork, especially across division and team boundaries.<p>Essentially all the problems we know from the old bad days of manufacturing.<p>Please, realise that the person interrupting you definitely think they are doing it for a good reason, and they are probably trying to spare you from meaningless work -- now, or in the future.<p>If that's not the case, then the discussion must be centered around organisational productivity, not just the idea that personal productivity is more important than anything else.