I heard a story on the way to work this morning. This story starts out like many stories about software projects start out: with a weird specification.

Of course, I'm talking about 601 Lexington Avenue, also known as Citigroup Center, in New York City. And it's a true story.

The Premise

When the building now identified as 601 Lexington Avenue was conceived, there was one problem. On the plot of land where it was to be built, there was already a church. Good news was the church let them use the land. Since the church building was fairly small, they could build however they wanted as long as the church remained intact and in place, with no connection to the new building.

If you want to fill a square plot of land with a skyscraper and there's a small church in the way, there's one easy solution: either build around it and waste space, or … build over it. Put four solid pillars in the corners of the building to raise it up above the church.

The problem with 601 Lexington Avenue was that the church was in the corner of the plot, so they couldn't put pillars there.

It was decided to move the pillars away from the corners of the building and into the middle of the sides. This gives the building a very rickety look, but it can be made structurally sound with solid engineering work. And it looks really cool from the ground.

The Design

To hold the building up, it was fitted with load-bearing, upside-down, stacked chevrons on each side. Basically giant versions of the letter V that transfer weight from the corners onto the sides, distributing it over the pillars. This is both good design and cool engineering.

The building was also made light. A light building is, perhaps contrary to intuition, easier to topple over. The reason is Newtonian physics: the more mass something has, the harder it is to get it moving. This was a cutting edge building though, so they had technically impressive measures in place to prevent it from swaying too much in the wind. (When your office sways in the wind, two things happen: 1. You get motion sick, and 2. You want to call your mother because you think solid buildings aren't supposed to sway in the wind.)

The Testing

This was a building kind that had never been attempted before, so of course they rigorously tested the design. They checked that it lived up to all kinds of security codes with ample safety margins. They did this both through physical experiments with models and by doing the maths.

One of those building codes say that if your building can take winds head-on with a decent safety margin, they can also take winds on a corner. Of course they can; buildings are strongest at the corners. Everyone knows that. Corners have the support of not only one, but two walls.

So they tested the ability of the new 601 Lexington Avenue skyscraper to take winds head-on, and it passed with flying colours.

The Optimisation

Since this odd building was structurally sound, it was built. The contractor who built it – Bethlehem Steel, a name you might recognise from Mad Men – made an observation on how they could save money on the building. They called the responsible engineer, and told them they had run the maths on their side too, and if they replaced some welds with bolts, they'd still follow building codes with ample margins. They'd get the same thing, except much cheaper.

The engineer gave them the go-ahead. Not that it matters, because it was such an obvious optimisation anyway. The call was mostly out of courtesy.

The Bug

Remember how the maths based on building codes gave them ample safety margins? Remember how a corner is the strongest part of a building?

Not this one.

With the pillars on the edges, the V-shaped load distributors, and the light mass of the building, the corners are the weakest part of the building. The safety margins in the original calculation were still so good it would have worked, though. The straw that broke the camel's back was the optimisation of switching out stronger welded joints for weaker bolted joints.

This was not discovered until the building had been standing for a year. But it was clear as day: the building would topple over on average after somewhere between 16 and 55 years (the higher number is assuming the anti-wind-sway technology is powered on, which is not as likely as you'd think in a strong storm where the risk of city-wide blackout was determined to be significant).

It was therefore predicted 601 Lexington Avenue would after just a few years come crashing down on downtown New York City, taking several other skyscrapers and, more importantly lives, with it. It was only waiting for a storm strong enough to hit it diagonally.

A Retrospect

Any software engineers reading this will nod quietly in recognition. This is exactly the kind of thing that happens when you try to build something complex that hasn't been attempted before. A series of independently sound design decisions can lead to catastrophe. Doubly so when the original requirements contain special cases.

The reason I call this engineering fault a "bug" is that it arises the same way other bugs do. I've often heard people ask "how come software contains so many bugs and building projects never do?" and to an extent it's true: the quicker turn-around time for software (you can just deploy a new version in place of the old one) makes it less economical to thoroughly test software. But there's another big reason why software deals in bugs.

Software is a very young field. Almost everything we software engineers do is a cutting-edge project in some sense. Of course there are exceptions, such as the many CRUD apps that get created, but most of my work is about building new things according to unique requirements from the customer. When you attempt stuff that hasn't been attempted before, bugs happen. 601 Lexington Avenue bears witness to that.