Silos and Architecture Astronauts

Joel Spolsky‘s latest post is about what went wrong with the Chandler project. I’ve been eagerly awaiting Chandler since I first heard about the project, but I began to lose interest when, after several years of development, they didn’t even have a useful prototype. After reading an account of the project in the book Dreaming in Code, Joel concludes that the problem was that “the vision was too grand and the details were a little short.”

The only concrete design ideas, as far as I could tell from Rosenberg’s book, were “peer-to-peer,” “no silos,” and “natural language date interpretation.” This may be the a limitation of the book, but the initial design sure seemed to be extremely vague.

This idea of “no silos” is one that really hits home for me. It’s something that’s bugged me for years about information management software. We have all these bits of information — emails, text files, Word documents, bookmarks, etc. — and we have all these specialized applications for managing them. I’m not arguing against specialized applications, but it’s frustrating when there are completely different conventions for each type of data. I can use tags to organize emails and bookmarks, but not regular files. If I want to send a photo to someone, I attach it to an email, but if I want to send an email, then I don’t “attach”, I “forward”. It’s not hard to imagine how confusing this might be for some people.

That’s what I think of when I hear “no silos”. And given what I know about the Chandler project, I think that’s what they mean too. Joel came to a totally different conclusion, a strawman which he easily knocks down:

As soon as you start asking questions about “No Silos,” you realize it’s not going to work. Do you put your email on the calendar? Where? On the day when it arrived? So now I have 200 Viagra ads on Friday obscuring the one really important shareholder meeting?

I seriously doubt that anyone ever proposed putting every email that you receive into your calendar. Anyways, Joel uses this example to pull out his favourite whipping boy, the “architecture astronaut”:

I think the idea of “No Silos” is most appealing to architecture astronauts, the people who look at subclasses and see abstract base classes, and who love to move functionality from the subclass into the base class for no good reason other than architectural aesthetics.

Personally, I agree that you shouldn’t waste time designing for things that you may never need. I believe in writing the simplest thing that could possibly work and then making iterative upgrades. But I don’t think Joel is being fair here, since he obviously doesn’t understand what the real idea was behind “no silos”. Instead of actually critiquing the idea, he pulls out his “architecture astronaut” trump card, just like how any discussion of the war in Iraq can get you labeled “unpatriotic” in the US.

I think there is such a thing as being an “architecture astronaut”, and it’s something I’m often guilty of, but there’s obviously a fine balance between trying to write beautiful code and trying to write working code. If you focus too much on just getting code to work, it will be unmaintainable. On the other hand, you could spend forever refactoring your code, and it would never be perfect. The trick (as with everything in life) is to find the right balance.

I just wish Joel wouldn’t vilify that sort of high-level thinking so much. I think it’s important to always try to think big-picture. If we use the construction analogy, Joel would be advocating thinking only about the houses and not about the communities. He’d be building sprawling suburbs instead of livable cities.

(Photo by Jan Tik on Flickr)