I'd say that's something to avoid whenever possible.
But that's just pushing the metaphor back a level: in order to know how to design your codebase so that it's well-organized and extensible, you have to have a pretty good understanding of what it does, what it needs to do, and how it does it.
For me... once I get into the zone on that, all the noise in the world can't distract me. But conversations by my desk, other people's music, drive-bys by the boss, all those things make it harder to get into the zone. (Though, for me, this means it's way easier to work around strangers in a truly shared space than around co-workers who I'm more likely to talk to.)
On the other hand: Foosball, ping pong, video games -- all those are obviously distractions. They're there to make it easier to take a break without checking out and going home for the day, but I've seen many people (shared office or no) fall into the trap of letting the job be the distraction from the play.
There's also the risk of design paralysis. Where you focus so much on perfect program design that adding a new feature or making a change is offset by excessive, obsessive time spent making sure it fits the design absolutely perfectly. Some programmers think more about the aesthetics and organization of their code than the actual function. They may make large refactors with every minor change or spend hours thinking about the design when just implementing their first intuition would be way more efficient for both their present and future selves.
So, in some cases it may actually take more time to make a change to a well-designed codebase vs. someone who's just plugging things in as they go and refactoring later when they need to. But I would agree the opposite problem of poor design is far more common and that it's usually much faster to make changes to a well-designed application.
What I would say, to anyone old enough to have lived through the HD->SSD transition, is: "Quiet offices are an SSD for programmers' brains."
It's short, it's simple, it's repeatable, it's understandable. I think it's more or less true, and it's hard to argue against SSDs. We buy our programmers SSDs for their computers, so why wouldn't we want them for their brains, too?
I've tried explaining this to manager and business type of people. I've even shown them articles and papers about this topic. All I've ever gotten is mocking and scoffs about how we aren't special snowflakes and how every job requires thinking and concentration. Maybe they are right. I've never been a manager or business person. But it seems to me they spend an awful lot more time talking and creating powerpoints than they do thinking.
As far as I can tell, that's how they do their thinking!
That is far too low of an estimate for any productive programmer. Perhaps when trying to solve some sort of insanely complex bug perhaps?
Software developers on average write only about ten lines a day. The reason the process is so slow is that for each new line of code, you are trying to accomplish a task, and their are a great many different specific ways to do it.
However, you can't pick just any way of doing it. That's because any line of code will impact on dozens of different things in the program, and generally in bad ways. So you have to figure out a line of code that will accomplish the specific thing you are trying to do, but without having any bad consequences for the rest of the program.
This is a complicated puzzle, and to solve it you have to have the whole program, or at least a lot of it, in your mind all at once.
But few if any programmers are smart enough to keep it all in their mind all the time, so for each new line of code they have to sit and think about the program, look up lots of specifics about it, and then get it all organized in their minds. That takes a whole lot of focused attention. Any interruption causes all this to disappear from the programer's mind, and they have to start all over again.
Now I am not a programmer myself, so I may not have this all right. Maybe someone could improve it. Also, it would be helpful to have an analogy for something similar the manager does.