John Murdoch

In the late 1300s Gilbert de Clare, an Anglo-Norman lord with political and military ambitions, seized extensive holdings in south Wales. Facing an impending counterattack by the Welsh, he commissioned the building of a castle--what would become Caerphilly, a 30-acre colossus just north of the city of Newport, Wales. I was there last week, and it is genuinely breathtaking. The web site (http://www.castlewales.com/caerphil.html) and the official brochure don't come close to doing it justice--it is an engineering marvel.

Which, ahem, is kind of the point: as I walked through Caerphilly, with Daughter #2, I marveled again and again at the brilliance of the engineering, and how well that brilliance has stood the test of time. More than seven hundred years later, the walls and towers of Caerphilly (with one unfortunate exception) are plumb and square. Despite wind, weather, and time, a structure largely built within a two-month period with hand labor has stood, indestructible, for centuries. It isn't just that the castle has thick walls (it does), a big moat (it does), or ample storage room to endure a long siege (yup--that, too). The design of the castle so thoroughly addresses the problem at hand that any potential attacker would recognize instantly that the fortress really was impregnable. The castle was besieged, but never fell--reportedly because the attack was half-hearted, it being plain to all concerned that any attack was pointless.

Terrific engineering--but were they engineers?

There is very little we know, in truth, about fourteenth century Wales. One thing we can be certain of, though, is that nobody involved with the construction of Caerphilly was a licensed Professional Engineer. Nobody had a degree in engineering--but in less time than you or I would take to document a project design in UML static structure diagrams they managed to design and build a thirty-acre fortress that has lasted hundreds of years. And it will still be there, long after you and I are gone and forgotten.

My business card says that I'm an "Engineering Software Leader." My employer tells me that I'm to lead teams of software engineers, doing engineering. My associates, without exception, have degrees in computer engineering, software engineering, electrical engineering, or computer science. Many of them are firm in the belief that they are engineers--heirs to the engineering traditions of the Greeks and the Romans, of Fulton and Morse and Roebling and I.K. Brunel, of Edison and Westinghouse.

Let's posit, for sake of argument, that they're engineers. Are they doing engineering?

If you haven't guessed by now, I'm profoundly skeptical of the notion that software is a form of engineering. I've been a software developer for almost twenty years, my stepfather was a civil engineer, and a lifelong interest (and university major) in 19th-century American economic history (think "railroads") convince me that while we sometimes talk and think (and every once in a while act) like engineers, the overwhelming bulk of what software developers do has little to do with engineering.

It is one thing to assert that--it is something else entirely to state the proposition and defend it. And that's what I propose to do over the next month or two--state and defend the notion that software development isn't a branch of science (my high school computer teacher wore a lab coat to demonstrate that he was a scientist), or a branch of engineering. If anything, software development is, in the main, a form of communication. If you have happened to stumble across these pages as I write, I welcome your comments.

For the moment, though, it's time to wrap up this post and go to bed. But let me leave you with a last thought: two weeks ago I was chatting with a colleague in the hallway at work. The earliest piece of code that I have written that is still in use (as far as I know) dates from the early 1990s. My colleague has still-functioning code from the late 1980s. That puts us in a very small minority among developers--there are lots of developers working today who don't have functioning code that dates from last year. If we're supposed to be engineers, why is it that so many of our best-trained and best-qualified can't write code that will run, unchanged, for more than a few months? And what can we learn--from the engineers who built Caerphilly, among others--to do what we do better?

Hint: it's about communication.