> Steve Jobs described the whole point to the design: he wanted people to frequently bump into each other, rather than being hidden away in private offices. He noted it was one of his favorite aspects of the Pixar office. It's strange that anybody would blame Jony Ive for a design that Jobs chose. Jobs took what he thought worked about Pixar's office to spur creativity & innovation, and used it in building the new Apple campus design.
Perhaps it spurs creativity and innovation, but only few programming activities are highly creative and innovative. Rather to me, programming is about writing bug-free code. In this sense, I tend to compare programming activities with Air Traffic Control.
I'll tell you as someone in a large IT organization creating a new paradigm for us re: public cloud vs. private: Collaboration and communication are huge. Absolutely critical that people are talking more often than not. It's decision making and design at that point, not just DevSecOps.
Programmers working on products like the iPhone or on networked services can end up applying creativity more often than you think. Sometimes there are difficult problems that can only be solved with applied creativity, and you also get much better results if your thinking is informed by the people who will be using your product (or taking it across the finish line once your code is 'done').
In my past jobs working on tools and infrastructure, the best results usually come from sitting next to the people who use the tools or at least watching them use them. The traditional model used by the teams I've helped typically was partitioned off and people tossed things over the wall, but I always got significantly improved results by actually collaborating with the users.
You can compare programming with Air Traffic Control but in that case you need to realize that ATCs are in constant communication with their customers (i.e. pilots) in order to deliver the best results for passengers. If ATCs behaved like programmers in monolithic organizations they'd simply issue flight plans without talking to pilots at all and they'd be ill-equipped to respond to emergencies and sudden changes in flight situations.
> Sometimes there are difficult problems that can only be solved with applied creativity
For these really hard problems, long hours of completely undisturbed concentrated working are the key to success.
Strong collaboration ("bumping into each others") is rather helpful if the "problem" is not that the problem is hard, but it is unclear what problem is even to solve, e.g. you don't know what the customer wants.
Addendum: My comparison with ATC is rather meant the way that it is of central importance to avoid mistakes (bugs in software, plane crashing in ATC) and the work environment should be centrally concern itself around this theme.
Perhaps it spurs creativity and innovation, but only few programming activities are highly creative and innovative. Rather to me, programming is about writing bug-free code. In this sense, I tend to compare programming activities with Air Traffic Control.