|Have you ever been deep in a task, really focused and in the zone, only for someone to come along and say "Would you mind having a look at this problem for me please". This probably happens several times a day. And each time it happens, you lose time. You lose time while you try to get your head around the new issue you've been asked to look at, and you lose time again trying to retrace where you where previously so you can get yourself back in the zone on the original task.
The time it takes for you to re-focus back on the original task (after having already lost time looking at the problem you were interrupted for), is called thrashing. It takes time for the brain to get back into gear, and re-focus on what you were doing previously. You don't just switch from one task immediately to the next. The time it takes for your brain to get back to the same point it was before you were interrupted is thrashing, and is a constant cause of consternation.
Unfortunately, thrashing is inevitable. You are always going to be asked to look at other problems and issues, all whilst being deeply focused on your current task. But whilst it is inevitable, it can be reduced with a change of working culture.
At a previous company where I worked, the Development Team were only allowed to be interrupted in the afternoons. The mornings were off limits to all members of staff, except under exceptional circumstances. So basically, the developers were left alone in the mornings to get on with their work, allowing them to focus on their project work. In the afternoons, you were allowed to interrupt them to look at any other issues or problems that arose.
So if an issue was raised in the morning, the person would have to wait until the afternoon to raise it with the appropriate member of the Development Team.
Over the course of a typical day, thrashing can cost a developer 10, 20, 30 minutes. Over the period of a week, this can run into hours. It's not the time it takes to resolve the issue that is the problem, it's the time it takes for the developer to focus-re-focus-focus that is the problem. It's inevitable that the unexpected will arise, and things go wrong and break, and require the assistance of a member of the Development Team to resolve them. That's a given. However, to mitigate the impact this has on the developer, and reduce the cost of lost time to the business, it's surely far better to schedule these times.
This is better for the developer (as they can focus on their project work during set periods without interruption), and better for the business (as it reduces the time lost due to thrashing).
So to beat the thrashing, schedule periods of time when the Development Team are not interruptable, and periods when they can be interrupted. Simples.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare