When I design a software system, I'll typically design the system in my mind first, then map it into code. Depending on the complexity of the system, there is a ton to keep track of, and as the system is coded, new issues are identified and the design is modified.

When I become distracted, it takes a really long time to get back up to speed. If I lose the mental model of the system I'm building, I need to regenerate the model before I can continue to build. This is why long stints of uninterrupted time are most productive for a software developer: A very complex system can be designed and mapped to code. Interruptions to this process add significant overhead, and can easily double or triple development time.

Over the last few months though, I've noticed in myself another distraction that is more costly than interruption. If I am in a situation where I know it is possible that I will be interrupted, I'm limited in how much concentration I can bring to a task. This anxiety comes in many forms, but is almost always external. It can be as simple as sitting next to a friend or co-worker who you think might say something to you. It can also be something like knowing that you have an appointment coming up within the hour, and that you won't be able to get very far with your task before having to abandon the mental model and focus on something else. 

When building a software system, the effect is that I cannot get very deep into the mental model, which limits the scope, complexity, and quality of the system I am working on.

There are many ways to deal with this anxiety. In a work environment, the best is probably the headphone rule: If someone is wearing headphones, you don't bother them, unless something is really important. We're talking imminent physical danger important, like a fire (or worse, if the website goes down). To be effective, this shouldn't be implied, it should be explicit. In order for me to really concentrate, I have to know that people around me aren't simply deterred because of the headphones: they should know that this is a concrete rule.

In startups, for people who do both business and technical activities, try Paul Graham's maker time vs. manager time. Picking a time when you know it is unlikely you'll get a phone call or visit, and can devote yourself completely to some productive task, leaves you free from the anxiety of distraction.

I think this is also a great argument for having co-founders who are specialized, and another argument against being a single founder. Having one person be a full-time developer, and trusting another co-founder to take care of every other task, can be an incredibly powerful combination.

In corporations, if your developers are on a four-hour work, lunch break, four-hour work schedule, make sure those four-hour blocks are uninterrupted. If I come in to the office at 9am, and have a 10:30 meeting scheduled, and then lunch is typically around noon, it will be 1pm before I actually can confidently dive into a complex project. If the decision is made to leave sacred certain times for developers, make that decision a policy that everyone knows, and encourage developers to fight back if someone encroaches on that time. 

The ability to quickly design and code very complex systems with a high degree of quality is why really good developers are worth 50x or 100x as much as average developers, and the biggest software companies have budgets in the hundreds of thousands of dollars range to recruit them. Don't let the threat of someone tapping your developer on the shoulder cripple them.