|
I'm going to give everyone a pass on 1 and 3, because wifi's importance and characterstics weren't necessarily known enough to design around for a 2004 building. Especially the desire to reject external radar. 2 is not really the architect's fault. The client should have speced wired ethernet, and the architect should have included it in the design, and the construction manager should have verified it as installed during construction, if speced. There's some wiggle room for the architect to suggest ethernet, but without meeting notes who knows. If the problem is no ethernet in the hallways or no ethernet in the ceiling, again that's more of a timing issue. Navigation could be client or architect driven; I don't know about MIT, but I've been in Facebook's MPK 20 and 21 designed by Gehry, and they're also hard to navigate, but that's true of most of Facebook's buildings, and Gehry clearly adopted the client's style of ignoring the navigational needs of a building's users. Simple things like walking paths that are visually and texturally distinct from the sea of desks are super useful, but missing. Again, it's hard to know if the architect suggested these things and then followed direction from the client to ignore them, but design is a collaboration and there's plenty of blame to go around. Wifi seemed fine in MPK 20 though, so there's improvement ;) For 5, I probably can't blame the client here. I'd expect a modern building to be generally leak free for at least 20 years; and weird angles and such might well interfere with that. Could be construction errors and not design errors though. (I see on wikipedia there was a lawsuit about some of the leaks; Gehry casts blame on client cost cutting, so maybe there's some blame to share, but I didn't find details of the settlement, just that most issues had been resolved) There may be a client/user issue though; sometimes leaks happen and they're addressable, but they need to be reported and acted on. If people are only complaining to peers and not to building management or if building management is unresponsive, that's not the architect's fault. I suspect there might be some of that from the pest problems reported here as well. Managing pests in a building is a solvable problem, but it requires active participation of management and users once they're inside the building; weird shapes may be enabling some of the ingress though. Anyway, I'm not saying I'd recommend that Gehry design your building, I'm just saying the design is a collaboration between the client and the architect (and the builder), so you can't put all the blame on the architect. I don't know that you'd want to pay Gehry to make a boring building with straight walls and drop ceiling, but if you did, I'd guess it would go pretty smoothly and you'd have a nice standardish flexible building where you could put access points everywhere. |
At least for Stata/CSAIL, the “irregular connectivity” was a celebrated aspect of the design from its inception and approval.
Stata was meant to be the spiritual successor to the old, decrepit (though illustrious) Building 20, which had a long history of ad hoc collaboration, often driven by the constraints of the physical space (i.e. the wall between your office and the next has a hole in it where some piece of equipment was routed in 1957).
During the Stata hype phase, there was a lot of talk at MIT that the idiosyncratic structure would encourage the same kinds of collaboration through random-walk encounters.