Silos and Architecture Astronauts

January 22, 2007 ⋅ 2 Comments »


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)


  1. Colin Stewart - February 7, 2007:

    I'm certainly not one to vilify chasing big ideas, but you do have to be able to connect the vision to some idea of reality. Just saying "no silos" isn't enough; there needs to be an alternative. Something concrete enough that you can counter all of the silly misinterpretations people are going to come up with. I looked through the Chandler philosophy documents and I can't say I "get it".

    I do agree that the analogy to architectural astronauts is a little off the mark. The real problem with architectural astronauts is not the idealism so much as is the misplaced emphasis on code quality, rather than product quality. I would say the two kinds of quality are only weakly correlated.

  2. Patrick - February 7, 2007:

    It's true, the Chandler people never really made it clear what their solution was, in concrete form. The were lots of sweeping "vision" statements, but no real answer of "what's it going to do for me?" But I still think they correctly identified the problem, even if they haven't come up with a solution.

    Well, I'm not sure I agree that emphasis on code quality is misplaced. When you're developing software, you want a quality product with minimal development time. Code quality may be only weakly correlated to product quality, but I think it's strongly related to development time. In a messy code base, changes (improvements as well as bug fixes) take longer to make, and carry a greater risk of introducing breakage.

    But, I do think it's important to clarify what "code quality" means. On my old team at IBM, we used to have a rule: it's okay to be bogus, just be consistently bogus. I think that quality code is code that is consistent, simple, and easy to understand. The problem is that for many people, "quality code" means that code that is ridiculously general purpose, refactored to the nth degree for no reason.