Chapter. Architectural Hubris
BUILDING #2: Bellefield Tower
(Our second building in this architectural triptych, following the discussion of Fallingwater in Chapter X.)
One block from where my mother used to work, on the corner of Fifth Avenue and Bellefield in Pittsburgh, stands a strange sight. A very modern building wraps around in a Jobsian-loving rounded rectangle, narrowly avoiding a gothic Romanesque tower a century its senior. An uglier and more out-of-place architectural juxtaposition I have never yet seen.

Bellefield Towers now houses the Western Psychiatric Institute.
If you weren’t in Pittsburgh in the late 1980’s you wouldn’t have understood how this could have happened. On this ground once stood the original Bellefield church built in the 1880’s. Since its congregation had been moved further down Fifth Avenue, the building was sold a century later to developers trying to exploit the new business attracted by the Pittsburgh Supercomputing Center and the joint CMU/Pitt software building. They wanted to level it and build a new building, but were blocked when people mobilized to save the old tower. The developer then proceeded to honor this by demolishing everything but the tower and building the ironically-named “Bellefield Towers” next to it.
You can see the current Bellefield Presbyterian Church as an common example of the gothic architecture of the area. You can also note Carnegie Library of Pittsburgh and the Cathedral of Learning—both next door, both reflecting the gothic Romanesque architecture, and both figuring prominently in iconic photos of the most famous game in baseball.
Why is Bellefield Towers so obviously ugly? the old Bellefield Church tower stands next to Bellefield Towers with a “sawed-off” quality to it. The curved modern architecture of the latter serves only to emphasize how it was built with no consideration of the surrounding environment. The Oakland and ShadySide areas of the city that the old Bellefield Church straddled contains many unique examples of this Romanesque gothic architecture. When faced with a gorgeous 100-year old example of the area’s architecture, instead of working with the environment like Frank Lloyd Wright did with Fallingwater—in the same area of Pennsylvania no less!—the developer simply sawed it off!
I remember watching it happen, and this (literal) architectural lesson guides me to this day about the follies of architectural hubris in software.
…
Architectural hubris
“What hubris?”
Have you ever seen developers write code without considering the environment in which the code will live?
My big beef with most frameworks is that they’re often written with no consideration of the environment—that is almost by definition. The best frameworks are ones that are less frameworks than applications which force constraints of an environment.
Even if you build it your way and customize the solution for your application, it’s still a framework. But it’s a framework most likely to have at least one successful user… yourself.
“I’m a developer, I can make the software conform to my needs,” you might say.
That sounds a lot like trying to “lord over the environment with an isolated man-made imposition.”
“But what I mean is it’s all man-made in software, there is no environment.”
You don’t develop in a community of developers? That’s environment. You never took over a project you didn’t write or worked at a company with a pre-existing code base? That’s environment. You never dealt with an installation problem because your host was configured differently then your development environment? That’s environment. You never had business needs trump the little feature creature sitting on your shoulder? That’s environment. You’ve never listened to a user request? That’s environment.
“There is no danger of that environment being different.”
When I joined Tagged in 2007, they had a couple services written in Java, Zend Accelerator was the only code cache that worked with their PHP 4 installation, Oracle Real Application Cluster (RAC) powered the back-end, and development occurred by engineers working in cubes with a relatively heavyweight waterfall development process of six major releases the previous year.
Even though I prefer Python to Java for services, we increased our Java development to around 40% of our code base! Even though I much prefer MySQL to Oracle, I still used Oracle as our back-end database. Even the transition to the open office occurred only after it became apparent the company had outgrown the cube-space.
Why? Because that is the environment and your solutions have to work within that environment. Anything else is architectural hubris.
“But that’s not an architecture decision.”
Let’s say it is the early days of social networking and you join a company that is using Java/J2EE instead of PHP, or Oracle instead of MySQL, or they’re using Perl/Mason instead of your favorite (PHP) framework—there are so many to choose from that their number number is second only to Java’s.
Do you go in and say your experience building a CMS or e-store trumps their experience working on a nascent social network? Do you replace all the Java engineers with PHP ones? Do you replace MySQL with Oracle? Do you rewrite the site from scratch using your favorite framework?
These things may have happened and more. I know of over $50 million in valuation that wiped out by just one of those decisions I allude to above.
Maybe if a high-flying startup is attritting many top people, it’s because the new people they’re bringing in are guilty of this same mistake: the architectural hubris of not surveying the existing development before making their decisions. We have jokes in the Valley about the egos of former Apple vice presidents, or the poor management style of former SGI employees, the wastefulness of former Microsoft execs, and the passive aggressiveness of former Yahoo! vice presidents—there will be jokes about former Googlers, Facebookers, or some other startuppers.
And those jokes will be deserved.
“So you’re always right?”
I’m not saying that in all these instances these architects shouldn’t have made the decisions they did. I am not qualified to answer that since I didn’t work at these places.
But what I do know was that in the vast majority of cases, people went in without considering the existing environment. I do know the dynamics of a Facebook.com is different from the dynamics of Gamespot.com or Amazon.com. I do know a social network is different from a CMS or e-store. And all these solutions are very different from ones in enterprise.
Like building Fallingwater without getting an adequate survey done, every day people make the mistake of not looking before acting. They try to make PHP look like “Java with dollar signs.” They expected the environment to conform to their reality so they can lord over it with “some isolated man-made imposition.”
And in those cases, you are far more likely to build a Bellefield Towers than a Fallingwater.
(This discussion will be continued on Chapter X.)