Recently a co-worker of mine prompted me to re-read Joel Spolsky’s 2001 article Don’t Let Architecture Astronauts Scare You. Now, it’s not really fair to go arguing with an article from over 10 years ago, but in my defense, I’m bored. Some of this will probably get a little nit-picky, but I think each section is a valid point. Here goes.
Something about this article struck me as not quite right. Joel essentially posits that people who think about large-scale system architecture, and the technical details of them, are missing the point. He’s not flat-out wrong: people who are trying to produce a functional system that they will be giving to customers should be more concerned about what the system actually does than its architecture. But he also says things like this:
“These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture.”
To me this is a little like saying “Damn those [actual] architects! Why do they spend all their time studying the concept of buildings and drawing up lots of fancy pictures of buildings? Why won’t they go lay some brick and mortar and be productive?” In other words, the issue is not so much “don’t be an astronaut architect” as “your coders and architects should not be the same people.”
Beyond that, not a single one of his concrete examples was convincing (to me). Let’s review:
Napster & BitTorrent
The Architecture Astronauts will say things like: “Can you imagine a program like Napster where you can download anything, not just songs? Then they’ll build applications like Groove that they think are more general than Napster, but which seem to have neglected that wee little feature that lets you type the name of a song and then listen to it — the feature we wanted in the first place.”
I’ll grant that Napster’s ability to instantly get a song just by typing its name was a very important part of what made it so popular – but it was not THE feature. Joel himself has missed the point here: the key was the ability to instantly get a song for free. If you doubt me, try to remember the last time you heard someone talk about downloading something on Napster. It was probably somewhere around July of 2001 (~3 months after Joel wrote is article), when the free version of Napster was shut down.
On the other hand, think about a program like BitTorrent. It’s infinitely less user friendly than Napster was in its heyday. You certainly can’t just type in the name of a song and then listen to it. You can’t even download anything without first using a completely separate program (usually a web browser) to find a torrent file! However, 1) it’s free and 2) you can download anything, not just songs. This is due to the fact that BitTorrent consumes a generic, abstracted protocol (the torrent) concerned with transporting the most generic of all data, bits. It doesn’t care if these bits comprise a song, or a movie, or a book; they are just bits, in a specific order. That sounds suspiciously like what Joel was mocking his Architecture Astronauts for thinking of.
Joel goes on to list a variety of architectures, and then says this:
I’m not saying there’s anything wrong with these architectures… by no means. They are quite good architectures. What bugs me is the stupendous amount of millennial hype that surrounds them.
Fine. That’s a fair point. Except that doesn’t actually have anything to do with software design. Please forward these complaints to the marketing department.
Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. Soap + WSDL may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA.
A couple of problems with this. First, Joel seems to be arguing that if you can solve a problem, in any way, with an existing technology then there is nothing interesting about a new solution to that problem. Technically, yes, you can create a distributed services platform with CORBA. Would you want to? You can perform complex calculations on a slide rule, why on earth would you want a graphing calculator?! Second, once again we find Joel mocking architecture astronauts for proposing something that is now a very important concept of software design: “Distributed Services Nirvana.” The Cloud would like a word with you, Joel.
Fast-forward to 2008
As I mentioned in my intro, I feel a little guilty for picking on a decade old article. Fortunately, in doing a bit of research for this post, I dug up another more recent article of Joel’s. In Architecture Astronauts Take Over (2008), Joel continues his tirade against the evils of high-level architecture. Excellent! That means I can continue my tirade against Joel’s tirade. Now, to be fair this particular article isn’t so much about architecture astronauts as it is a long-winded complaint about Microsoft and two of its products, Hailstorm and Live Mesh. Those are fair complaints – I’ve been working at a .NET shop for almost 5 years now, and I had to look these up to find out what they were. But once again, Joel is using specific cases to tentpole his overarching theory about astronauts. And once again, his theory looks good, as long as you only look at the bad examples.
Underneath his complaints about specific Microsoft products, you can catch a glimpse of Joel’s real point. In summary “The Cloud is not something people want.” In asking the question “what is Live Mesh,” Joel says the following:
“Imagine all your devices—PCs, and soon Macs and mobile phones—working together to give you anywhere access to the information you care about.”
Wait a minute. Something smells fishy here. Isn’t that exactly what Hailstorm was supposed to be? I smell an architecture astronaut.
Just as he loves to do, Joel has taken a useful, desirable concept and dismissed it out of hand by pointing to one or two terrible implementations of the idea. Again, I don’t disagree on the specific case. I am a huge fan of many Microsoft products, but they definitely do have a tendency to be over-engineered, bulky, and frequently not very usable in their first few iterations. That does NOT mean that no one should attempt to solve the problem that Microsoft is trying to address. Does anyone think that Apple is going in the wrong direction with iCloud? Should Google stop developing services like Google Docs, Google Calendar, or GMail?
Perhaps even more damning, Joel goes on to say this:
When did the first sync web sites start coming out? 1999? There were a million versions. xdrive, mydrive, idrive, youdrive, wealldrive for ice cream. Nobody cared then and nobody cares now, because synchronizing files is just not a killer application. I’m sorry. It seems like it should be. But it’s not.
Anyone who has ever used an application like Dropbox knows exactly how preposterous this claim is. Now, at the time Joel wrote this article his argument might have held a little more water. The proliferation of mobile devices hadn’t really begun to occur yet. Modern smartphones were just starting to get off the ground (I keep having to remind myself that the iPhone only came out in ’07) and netbooks were really only an early concept; tablets existed, but each implementation was more laughable than the next. You were basically limited to a desktop or a laptop, so having all your devices synchronized wasn’t as big of an issue. Normally I would say something like “no one can predict the future” – but that’s part of a technology professional’s job. Syncronization is now not only a killer app, it’s THE killer app.
I want to be very clear about this: I have tremendous respect for Joel Spolsky. He’s a very intelligent man, and his work shows it. He co-founded StackOverflow (and eventually the StackExchange network), which I consider to be THE place to go when I want to figure out how to solve a software problem. He also co-founded Fog Creek, where any self-respecting developer would kill to work. More importantly, I don’t totally disagree with his point about Architecture Astronauts. When you are building a complex high-level architecture, you must be extremely careful to solve a real problem that is useful to someone. The higher your level of abstraction, the more you should check, double-check, and triple-check yourself to make sure that what you ultimately produce will be a product. If you are not careful, what you’ll get instead is essentially a very expensive solution to brainteaser.
Here’s the important distinction: that does not mean you shouldn’t try to solve the problem anyways. Just make sure you are solving it for someone and doing it better than anyone has done it before.