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!

Eclipse Europa and Modeling

I needed to whip up some class and sequence diagrams today, but had some time to spare first. So I thought I'd reevaluate how easily I could get a modeling tool working that's code-aware.

First, I saw that sometime over the last week, Eclipse released Europa. I'm still a little confused how that relates to Eclipse 3.3 - I think 3.3 is the new version, which is released, however they encourage people to get Europa instead, which is a bundled release for 3.3 along the lines of Callisto.

That was only the beginning of how fragmented the development efforts around Eclipse seem to be. I started poking around in the ever-disappointing GEF/EMF/MDT/UML tooling. It seems like they've abandoned/renamed/re-organized these projects more frequently than they've gotten meaningful releases out the door, and although there's a project called UML2 Tools that's supposed to provide class and sequence diagramming, there's zero documentation on how one would use it in Eclipse. I get the impression that despite the large number of eclipse tools and projects that make up the modeling stack, none of them is meant to be used by "users", they're all for "toolsmiths" (http://wiki.eclipse.org/GMF_Tutorial)

And this toolstack always caused the dreaded Eclipse plugin spaghetti mess for me in the past, so I'm still not really impressed with it. Maybe I'm completely misusing it, but I've put in a good faith effort to read some docs and learn what to do, and it can't be that hard. So, time to move up the stack to the vendors who build on top of the eclipse tooling.

One tool I've used before, Omondo, seems to have gone through some nasty personnel issues, because now there's a competing plugin, eUML2 that apparently came from Omondo's CTO and a mass defection of engineers. So I gave eUML2 a try.

It's nice to see it builds on the Europa/Eclipse toolstack concisely. It helped me through the reverse engineering, although I got XDoclet-style annotations in my source files rather than Java5 annotations. It's terribly slow even on my MacBook Pro, but it does eventually pull in the classes I want, has a very nice presentation (including full package name, yellow warning icons, etc), and manages to discover some of the connections between the classes. The sequence diagram editor had some problems with the view falling a step behind the true model state, which I had to work around. Also, it didn't leave enough margin for some text, although it did so consistently. Overall, it was usable, and I got my diagrams done... I think it would drive me nuts for a real design phase though.

Also used the new Spring IDE 2.0 which was just released - I didn't hit any new features but I do enjoy the bean dependency graph, that makes for nice quick documentation too.