I often disagree with Joel (and if he allowed comments on his blog, he would know that). But in this case I agree with him. I was at the “When 2.0” conference at Stanford in December 2005 when Chandler was represented on a panel by Mitch Kapor. I admit that I the time I didn’t understand what the hell the problem was Chandler was trying to address – but it seemed to me it all came down to “Outlook isn’t smart enough to know that 2PM MY time might NOT be 2PM your time”.
I downloaded the beta of the Chandler “do it all” application – and guess what? It didn’t do anything. I’m not saying it didn’t do anything well – it literally didn’t do anything. It was an incompletely written, completely broken application. It may be better now. It doesn’t matter to me – I gave them a chance to show me something and they showed me a boatload of nothing. Probably not a good way to market your project. They showed me a skeleton of what was probably once a very good idea.
But getting back to this essay by Joel – it doesn’t apply just to software, or course. It’s long been an adage that “too many cooks spoil the soup”. The same thing is true in software design.
In 2004, when I was first thinking about a widget based social networking site I had a lot of the project designed in my mind. I had some of it on paper. I thought I knew what the site would look and feel like. I thought I understood the flow.
But a funny thing happened – I started talking about the idea, and bringing people in – eventually starting a company of 7 – me, 5 programmers, a Biz-Dev guy, and Quality. The company still exists – but they aren’t building a social networking application – or anything related. We spent so much time talking about what the site might do or could do that I honestly never even got a login routine for the site. I had some glitz. I had some stuff in the works that still hasn’t shown up on any social networking application. It was social, users owned their own data – they could delete all of it, or any part of it. They knew everything we knew about them because they had the same views of their data that we had.
Screens didn’t just allow you to move widgets around the page, or even just create tabbed pages. We had that. And Zoomers and Scrollers and RSS feeds, blogs, etc.
We also had too many people making decisions – about what the product would be, and how every feature was to be implemented. It was disorganization by committee. It was prescribed failure – and as much as I value the opinions of the really smart people I like to surround myself with – I’ll never let myself be put into a position again where there isn’t someone who completely, clearly, and ultimately makes the final call. We need decision-makers. If they are also people that can inspire others, raise a call to arms, generate action – then that’s even better. But someone ultimately needs to be able to say “yes” and “no”. You cannot run a business by committee, and you cannot build software that way. At least not if the committee is larger than two.
Say, for example, that your vision is to rebuild an old DOS personal information manager, which was really really great but totally unappreciated. It seems easy. Everything about how the whole thing works seems so obvious, you don’t even try to design the thing& you just hire a bunch of programmers and start banging out code. Now you’ve made two mistakes. Number one, you fell for that old overconfidence trick of your mind. “Oh, yeah, we totally know how to do this! It’s all totally clear to us. No need to spec it out. Just write the code.” Number two, you hired programmers before you designed the thing. Because the only thing harder than trying to design software is trying to design software as a team.
Source: Joel on Software