By Scott Berkun, March 2004

Do engineers design? Can designers engineer? Looking back at great projects throughout history, it seems these kinds of questions never needed to be asked. There was a philosophy in great works that to do anything well required more than one skill set or discipline. On the contrary, unchecked specialization breeds fragile and shallow ideas.

As technology has progressed we’ve lost our connections with the great works of the past and the philosophies and attitudes that enabled them. The design and engineering of modern technology, software and the web has bred a hubris that anything older than a few years can’t possibly be relevant, and it’s a mistake. To argue this point, there is no better place to start as a basis of comparison and learning than the story of the Brooklyn Bridge.

The one minute history of the Brooklyn bridge

At the time (1860s) the bridge was planned, construction was the hot industry, the Internet of its day. New materials and engineering techniques saw the building of some of the largest structures in history, and bridges played a critical role in the urban development of the United States. Brooklyn, then its own city, was an obvious candidate to link to Manhattan, but all the newspapers and leading engineers said it couldn’t be done. Too far. Too risky. Everyone said the land quality was too poor for the bridge bases. They claimed that suspension bridges were too cutting edge in design. (Fun to realize all things dubbed cutting edge will someday be ancient). Popular and expert opinion was largely against the entire idea.

John Roebling, an established suspension bridge builder, worked for over a decade to plan and convince the city to build his design for the bridge. Eventually successful in this effort, he died in 1869, just a few years into construction, from a freak accident inspecting a construction site. His son Washington, a civil war hero and also an engineer, took over. He became painfully immobilized from the bends in 1872, but continued to lead the project with extraordinary help from his wife (Emily Roebling ). For many years he watched the construction progress through his apartment window.

The two towers for the bridge needed to be submerged deep underground, requiring the first air pressurization systems ever for this depth. They didn’t work well, and many people became sick (Most notably W. Roebling). The project saw the worst of Tammany hall corrupt politics, business scandals, bridge and caisson fires, funding and work stoppages… many of the things that can go wrong on large projects did, with the Roeblings often as victims to the greed and shallow ideas of others. The bridge finally opened in 1883. In the entire 14 years of its construction, there was no electricity, no power tools. No assembly lines. No wireless Internet service or lattes Most work was done with hand or horses. Unlike modern “death march” projects, 27 people actually died in the course of engineering the Brooklyn bridge.

Modern web developer	Washington Roebling’s team
3 week / month release cycle	14 year release cycle
Electricity	Horses
Coffee, doughnuts and air conditioning	Water and the elements (think muggy NYC summers)
Carpal tunnel syndrome	The bends
Layoffs	27 Deaths

If nothing else, the Brooklyn bridge is a reminder of how truly difficult projects can be. Sitting at a desk all day arguing through bug triage meetings might be frustrating, but it’s nothing compared to what these people had to go through. I think of all of my war stories shipping software and web things (browser wars? hmmmm), and they all seem hollow and pretentious in comparison. If I ever want to align myself in even the most remote way with the best of design and engineering, I have to re-examine my own experiences against a much wider context.

Where should the history of software engineering begin?

At Microsoft, programmers have the job title “Software development engineer.” I don’t know what they were called before I started there, but back in 1994 this was the term folks used, and it is still in use today (SDE for short). Many other companies use similar titles for even line level employees and new hires from college. My bet is that if you asked people who have this moniker on their business cards what they do, they’d smile and shrug and say “Look, I’m just a programmer”. I suspect the intent of the title on the part of whoever came up with it (I suppose the VP of job titles) was to elevate the idea of a programmer to something broader and more strategic in value. That instead of just writing code, they were thinking about the development process, and trying to make it into a true form of engineering – instead of just the craft of coding. But I think the verdict for the industry is still out.

As far as I can tell, the vast majority of people who call themselves software engineers focus on the internals of their creations, rather than their real impacts and values on or for the people that use them. In fact at CMU, it seemed most of the other CS students chose computer science in large part because of its abstraction from the real world (and the people in it).

If you look at the curriculums for computer science, there is only trivial attention paid to the deeper history of engineering and its social and philosophical context. There are no discussions of the connections between C++ and Da Vinci (Is there a golden ratio for algorithms?), or parallels between software architecture and the Roman aqueducts, or even the idea of beauty in code compared with the aesthetics of the Brooklyn bridge. Many computer science folks seem to want to claim the heritage of engineering, without inheriting the breadth of knowledge and perspective that comes with it.

I sometimes think of John and William Roebling, and the renaissance like role they played as chief engineers. They upheld an important tradition for their day by taking skills that were technical and abstract, and using them to deliver something everyone in the world could appreciate: not only for its scale and purpose (what could be grander than uniting two cities of people?) but for how beautiful and careful the design of every brick and visual line was.

Engineering for them was about fully delivering on commitments and working towards a superior level of craftsmanship. The bridge was built to a standard 5 times as strong and stable as the laws of physics required. They wanted to build something that would last and endure despite any oversights by anyone involved in the project. They understood the potential for (their own) arrogance, and planned for it. How many software or web projects can say the same thing?

I think given the narrowly defined role of programmers, there is little reward in many organizations for would be junior Roeblings or Da Vincis to grow their non technical abilities. There is often someone else, a project manager, a marketer, or even a designer, trying to keep the engineer focused on adding more features or fixing more bugs instead of understanding a broader view of what engineering is about. Specialization has disadvantages when taken too far.

If the organizational rewards don’t encourage people to grow outside their domains, the odds of Roeblings surfacing, or great works occurring, is slim to none. In fact the culture of software engineers often looks down on those that want to understand politics or user centered design, skills needed for great works to happen: acquisition of those skills is somehow seen to betray the abstraction and supposed purity that many want to protect.

More important perhaps is this question: what standards do software engineers, programmers and designers set for the quality of their work? And how effective are they (we) at convincing others of the significance of these standards? For what its worth, I do see Roebling as a heroic figure for the making of great things, in that he fought the same kind of battles to achieve what he did (perhaps as Michelangelo did with the Pope?), that many of us do to achieve the great website or the great piece of software. I can’t imagine how a modern software architect could possibly convince a VP to pay for code 5 times as reliable as a baseline equation dictated. It’s rare enough it seems for software efforts to even meet the skimpiest baselines, whatever they are.

When design became style, engineering became something else

Back in post the civil war world of the Brooklyn Bridge (1868), design was a functional word. It implied an intelligence and economy of resources, combined with a simple, clever and often restrained aesthetic. Products rarely had many competitors and the basis for most comparisons were quality and cost. The industrial revolution was not at full speed yet, and it would be decades before Ford would perfect the assembly line and began the mass production of the automobile. Most people didn’t own many things, and much of what they did have was made by hand.

But somewhere between the time of the Brooklyn bridge and the 21st century, the word design took on a very specific and consumer focused meaning. According to some design history books, it was the 50s and 60s, when pop art and design surfaced as a response against the earlier Bauhaus movement (which defined a restrained and minimalist philosophy, but pushed for integration of diverse skill sets).

Design, around this time, came into its own as something separate from engineering and product craftsmanship. Bright colors were popularized to celebrate the post war economy (for those my age out there, this might explain some of those hot pinks your parents wore), and there was a sense that anything could be desirable. Some of this momentum carried on into the 60s and 70s, and it is safe to say that designer fashions and consumer goods eventually became the most popular and well recognized uses of the word “designer”, forever changing the general population’s idea of what designers do. ( A great counterpoint to this, and also an outstanding book on design, is Victor Papanek’s design for the real world).

And as design became (popularly) indistinguishable from style, I think engineering retreated back away towards technology. There was now another set of ideas, partially divorced from the spirit of Roebling and DaVinci, driving how engineers valued their contributions. Instead of seeing themselves as driving a holistic vision, there was increasing pressure to focus on what designers could not do, and what their knowledge of mathematics and physics prohibited others from contributing to.

The noble idea of the engineer

During the mid 1800s very few people in the world had the ability to design or engineer things that thousands of people would use (I suppose this is still true today). Roebling and others took that opportunity and held themselves to a very high standard. They believed in the idea of noble works, and that their skill should be used to satisfy the highest ideals for humanity and be comprehensive in approaching their work from all the necessary perspectives. All of their plans involved not only issues of construction and suspension, but included significant efforts to balance other factors into their plan. Designing the bridge, to the Roeblings, meant something like this:

design = aesthetics + engineering + performance

It had to be beautiful, reliable, and functional (The idea of usability or interaction design would surface somewhere within performance). They saw their role not just to build something that would transport people, or last 50 years (or 200), but to contribute to the landscape and the human experience of everyone that came into contact with their creation.

Every sketch and diagram John Roebling made considered not only its physical purpose and structure, but also its visual appeal to those walking on the bridge, and those looking at it from across the river. Like DaVinci and Michelangelo (who both had major efforts in architecture), Roebling saw his works from multiple perspectives. This is probably, at least in part, why Roebling was able to convince the government of Manhattan to fund the project at all. It was a bold and crazy idea for its day, and Roebling’s ability to consider and make arguments from the political, business and social points of view must have been an asset. Had he been a engineer (little e instead of big E), he probably would have failed to even get the project off the ground.

Exploring the models of power

Unlike the team based approaches many web and software developers take to projects, architecture and major construction generally operate with strong hierarchies. Roebling had a team of 10 or 12 senior engineers that helped him plan and lead construction, but the remaining hundreds of workers generally operated in highly specialized and tactical capacities. This is a model of power that goes back to the construction projects of Egypt (think pyramids) and the autocratic governments and military system of that time (or depending on your spouse’s personality, still goes on today).

Architects or chief engineers were the top of the hierarchy, and had responsibility not only for the planning and design of the bridge, but for managing the daily business of its production. It was assumed that not only did they need to bring the design vision to the table, but they had to have the leadership, planning and organization skills to drive multi-year projects to completion.

This centralization of power allows for one mind to drive the work of dozens or hundreds of people. Great ideas do not need to be filtered by committees, or tainted by the whims of area specialists. The vision for the project could be delivered relatively intact, and achieve something that a fragmented and distributed power model could not. Like a novel or a painting, great works often demand that one person and one mind have more authority over the creative aspects of a work, than any other. This generally means that the level of creative control most contributors to a project have is smaller, but that their potential satisfaction in the result might be greater (e.g. you can contribute to the Parthenon as a mason, or be master architect for a wooden shack).

Include or exclude, that is the question

Perhaps what’s most important is not whether the system of power is a hierarchy or a republic, but that whatever individual or collective wields decision making power has knowledge and experience of many aspects of what’s being built. If that one autocrat knows design and engineering and marketing, then they are probably more effective in certain ways, than three individuals who are experts in those roles, but who don’t get along well, or fight on discipline boundaries that the one autocrat dude doesn’t even see. So the real issue is making sure the right expertise is applied to the right problem at the right time, and often this requires the involvement of more than one person.

For any decision, say how tall the spires of the bridge should be, or what features should get cut from v2 of the search engine UI, it’s impossible to involve or include everyone. There are too many people contributing to most projects, and non everyone has the same level of expertise or experience with any subject. Just to get everyone in a room together, or up to speed on the issues, would take considerable amounts of time. But there are probably 4 or 5 or 10 people who do have the right experience or knowledge, who should probably be included in that decision. It’s the leader’s job to figure out who the right people are to involve in any single decision, and take whatever pains necessary to make it happen. More so, to make a culture of it (that all managers and leaders are encouraged to do the same thing, and that admitting ignorance is a strength not a weakness). Sometimes this needs to extend all the way to delegating the decision to an individual or group of people, and sometimes it means the head honcho goes up on the hill to meditate, and returns with a decision.

Autocratic or not, it’s the right level of inclusion and exclusion of people on a team that increases the probability of success. My suspicion is that even the great creative tyrants throughout history knew when to include certain people, and when to exclude others. I couldn’t find anything on Roebling regarding this, but I’d bet a dozen cookies he knew when to include people. Design and engineering are as much social processes as technical ones: anyone with the best interests of the project at heart, has to learn about the people they’re working with, looking beyond their job titles or stereotypes, to fully understand the ways in which they might contribute. I think its the only way great works ever happen.

Think about who you involve in the decisions beyond your expertise. Do you go to your friend down the hall? Or do you try and find the person who actually has the knowledge you need? Odds are there is an expert who knows best, and is willing to help, but who is not in your daily sphere of contact.

Some parting advice for those in or visiting NYC

Even though I grew in Queens, I only saw the bridge a handful of times and didn’t pay much attention to it (I was busy chasing girls or playing basketball, or both). I have vague memories of childhood trips to the South street seaport (they had the best pickles there, yum) where from the corner deli on the second floor, you could look out the windows and see it hovering the distance. Years later, in a course I took on the history of NYC, I finally read the book the great bridge by McCullough and was blown away. During the last class we took a walk out on the bridge, and I will never forget that day. It was a sunny January afternoon, sun just starting to descend as we stood at the center of the span, quietly looking out over the Hudson, imagining in my mind all the things the Roeblings did to make it possible for me to stand there. Think about what you do for a living: will you ever attempt to do something half as great as the bridge?

If you live in NYC and haven’t done this yet, go grab a bagel and some coffee and head out. You’ll get triple extra bonus enjoyment points if you read McCulloughs book or watch Ken Burn’s excellent film beforehand -really, you will. (If you go, send me your digital pics – I miss the bridge :).

“It’s the spirit behind the Brooklyn bridge, and the spirit in the structure itself. The spirit that you anticipate and appreciate even if you’ve never studied engineering, even if you’ve never studied aesthetics. It’s there. And in one degree or another people that use it and have their eyes open respond to it” – Lewis Mumford