> That's because any line of code will impact on dozens of different things in the program
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.
>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.
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.
Ok, but the purpose of my explanation is not to be technically correct, but to get a manager to understand why programmers need to be undisturbed. So if it is a little inaccurate, but accomplishes the goal, then I think developers should use it as needed.
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.