Building codes

When I was at my last government contract, we were developing a Single Sign-on solution that dragged on forever due to Oracle bugs, misunderstanding of the requirements, politics, and the other usual suspects. In the meantime, across the street and plainly visible from my seat, a building went up, a nice 8-story office building with a parking garage. They literally broke ground, dug the foundation, erected cranes, put up the building, added HVAC, walls, windows, and it was basically done, while we still hadn't implemented a working single sign-on solution across all the applications that were supposed to have it. We were just typing, and these guys had brought in truckloads of materials and assembled this giant structure.

This has always struck a nerve for me, especially because I think erecting a building is the single best analogy for software development. I've heard others, like from my crazy first boss who always said that if we were missing a certain feature, it was like a car with three doors. But a car isn't a good analogy for development - they are mass-produced, never modified, consumer products with a pretty small set of complexity - combustion, electrical, mechanical, suspension, seat cushions.

Buildings, on the other hand, share a TON of interesting features with software. They are large projects, similar to each other in form but each unique in their implementation. There are a number of skilled workers, with different areas of expertise that must participate. There is a complex schedule that must account for the dependencies between pouring the foundation and inspecting the concrete and so on.

Pre-fab is another nice part of the analogy. I don't know much about it, but I think there are a lot of standards in buildings that make it possible to get lots of your materials in a partially constructed state. Door frames are a similar size, and you can just buy the door already hinged into a frame, nice and square and level. I see trucks with rafters for houses, already assembled and ready to "raise the roof". Same goes in software, where standards like those from the JCP let us plug in pre-assembled components rather than building them from scratch.

Looking further, there is an agency problem. The people who will ultimately inhabit and use the building are rarely stakeholders during the construction. The builders do the construction, but don't have to live in the structure or deal with the problems that the maintenance company uncovers. In software, end users are similarly more like tenants than they are landlords.

Yet, in real estate, there is much less sense of risk or mystery about the quality of the work, whether the building will stay standing for 5 years, whether it's safe and structurally sound, if it was built by qualified craftsmen. When you see a new building go up, you're pretty confident that it will get finished and be a successful project, as long as the funding stays intact and the contractors aren't too disreputable. But in software, while companies focus a lot on a structured development process and testing, they don't have a grasp on what the code ends up looking like, whether the system is structurally sound and safe from fires (= production emergencies of course).

I want to explore why this is. I think I'll look at it over a series of posts and maybe develop this into an article, because I think there's something very interesting that software development could gain from civil engineering practices.

To start answering questions, I'm thinking of how buildings work. First, there are house inspectors. I can't just look around a house they might buy, and figure out if things are structurally sound, yet I expect I could hire someone with this skill to give an honest, impartial appraisal. I'm sure this is the case for new, commercial construction as well. Yet I've never heard of a third-party auditing/appraisal service for software.

Next, the inspector has a set of building codes, enforced by local law, that guide him to check many important features, and provide an objective baseline of criteria that the building should satisfy. The most popular set of codes is the International Building Code - I think I'll poke around in there and see how they manage to capture the complexity of what they assess. Just as with software, I'm sure there are a lot of grey areas and places where there's some discretion the architect can take, yet there's a right and wrong way to assemble the house. We do have some such guidelines in software, but I think this could be improved based on how the civil engineers do it.

Finally, there's the qualifications of the craftsmen. I like posts like this from Ken Auer on apprenticeship in software that talk about how software engineers learn their craft. You really don't learn it in school, or from a book. (Maybe Cisco or MS engineers can do book learning and take a certification test, but I don't know any good software engineers who do this.) Sure, programming is not all science, there is art to it as well. But there's also art in architecture, and maybe even in quality welding, for all I know, and those guys don't just learn their craft by copy/pasting some code and trial-and-error.

So, if I keep this line of thinking running through my head, I think I'll write about:
- How building code works, how it is applied to real world buildings, and whether the software analogy works
- How building inspectors can apply the building code, and whether there are such people for software
- The way craftsmen like electricians, welders, as well as artists like architects and designers, learn their craft and conform to the code

How do buildings go up faster and with less risk than software??

I'm interested in comments!