Why Apple products are well designed and buggy
Following the discussion on Hacker News how MS had resources and liberty to experiment with their developer tools, but the new Visual Studio 11 is committee-designed and is based on the same crufty UI which is many years old now.
Both Apple and Microsoft are free to throw away old problematic UI and rethink some parts from scratch. If anybody is hurt in the process, it’s not a bottom line. Microsoft sells Excel and Apple sells computers, they don’t have to prove anybody anything with their developer tools, except for themselves. And they have all resources and expertise for that, of course.
However, there is a difference in approaches. Apple, comparing to others, is not afraid to break things while executing some ideas they think are great. For instance, when Xcode 4 was released, it integrated Interface Builder very neatly into main window, but they broke support for third-party UI components. So while some people would have to type a bit of boring code to setup those components, many others are enjoying unified workflow. Also, the first builds of Xcode were very slow. Xcode team found a way to represent tons of useful information in only three panels with very little cognitive load, but didn’t take time to optimize the performance. It was super-useful and super-annoying at first. But that was a non-trivial decision from their part.
When Apple released Final Cut Pro X with awesome new design, increased productivity and 70% price drop, they omitted some very important features. They finally added missing stuff, but before that they got a huge shitstorm from the customers for not having all they needed from the beginning.
As with Xcode 4 and FCP X, nobody was forced (even in a weak sense of this word) to upgrade. Xcode 3 worked well (I was using it while working on a slow notebook), FCP 7 was not killed too. What Apple had is basically a courage for an “release early, release often” type of operation. Why did they make these particular compromises, not the others? It was important for them to make a great new design and try it out as soon as possible at full scale. There is absolutely nothing interesting in performance optimization and bug fixes. You already know it’ll be awesome if you do them.
When you are designing, you are taking risk to decide for others and you don’t know if your are right until you show it. It also means, you cannot ship half-designed product. The reaction on unfinished design (non-thought through, that is) is skewed. It does not help you to understand if you made it right. It’s not a problem if it’s slow and buggy, those things do not obscure (at least, should not obscure) the vision of how product works.
Since you have to spend time designing every aspect of the product to the last detail to get sensible feedback, you don’t have much time left to resolve less relevant issues. You are already quite late, for that matter. And if your decisions need some improvement it’s better to know it before you start optimizing them.
So in the end, every new Apple product has what they consider a finished design with new ideas, but with rough edges like crashes, performance issues or some less relevant features omitted to be reworked later. Those having time to polish secondary aspects of their products are not pushing forward hard enough.
If you like the post, follow @oleganza on Twitter and buy my well-designed version control app: Gitbox. It’s super-smart, fast, and, of course, sometimes buggy ;-)