blog.lukhnos.org

Good Backend Performance Is This Long-Term Thing

I never looked back at the diverse ways I managed my to-do lists after I bought Cultured Code's Things. I first bought their iPhone version (USD 10) then the Mac version (USD 50)1. It's very well designed, straightforward to use. You don't need to be an expert of David Allen's GTD methodology to use it2. Things for Mac earned an Apple Design Award this year, and I think Cultured Code deserves the honor.

Still, for all my love and appreciation for the app, it exhibits two long-term problems:

  1. Its data sync between the Mac and iPhone apps is terribly slow and unreliable. Sometimes it adds peekaboo items that were long dead, done or cancelled. Sometimes it adds blank items that actually bear titles. Sometimes it even misses some items. This part is improving, but some occasional glitch can still happen.
  2. Both versions are already painfully slow after 6 months of use. I always have around two dozens of projects at any given time, and complete on average about a dozen of items every day. Juggling items around projects quickly become a slow drag: UI becomes unresponsive, the waiting time, especially the perceived time, is horrible (to the extend I already have developed anxious reflexes when I undo or move items).

I suspect part of the problem is Things is not backed by a super fast data mode, and its current backstore has a scalability bottleneck at around 1k items. The situation is certainly improving, and I believe the developers at Cultured Code are working hard on that. Still, I estimate they need to perform big overhaul on the backend in order to boost the performance.

That's the flip side of an application with such a great user interface, though. And Things is not alone. Many Mac apps seem to share this backend problem, and while their interfaces make you fall in love with them at the first sight, using them in the long run is another matter. This is when catching up in that part becomes crucial. iPhoto, for example, has been a laggard. Its performance is not stellar. Picasa for Mac, on the other hand, is a super fast roadrunner even with a huge data set, but its interface on Mac is terrible3.

Good user interface only gets you this far (admittedly the business goal is already achieved). The halo effect of good UI wears out after using it for a while, and then you take it for granted. Bad backend performance, on the other hand, can only aggravate the pain as the time goes by, and the problem grows. A good application has to excel at both4—hence all the more challenges for software developers.

  1. It turns out I use its Mac version way far more often than its iPhone version. The iPhone version, a premium app given its "exorbitant" price in the one-dollar ecosystem that is the App Store. The iPhone version now mostly serves as today's to-do list and a quick inbox when I'm on the road. I seldom use it for tasks more complicated than those two. Two observations: First, Mac app can sell at a unit price far more than "premium" iPhone app. And, for all the talks on how (first web apps, then) mobile apps will kill the desktop, in many cases the role of the desktop as the flight carrier is only reinforced. ↩

  2. The book Getting Things Done is a perfect example of the problem of book writing described in this essay by Philip Greenspun. In short, it's just an idea that's worth 20 pages, but you have a book with later chapters that are, to say with an understatement, less than insightful. The best part of Allen's book is its first chapter, in which the author gives you a historical perspective on the origin and evolution of to-do management. Similar things can be said of Merlin Mann's inbox zero and many other self management techniques. ↩

  3. Picasa's user interface is terrible, Windows and Mac. It's a total mess down to the level of its information architecture and data set design, and its interface only faithfully reflects the confusion of an app that tries to be your photo album manager, photo files (actual files residing on your file system) manager, and a syncing tool to its eponymous web service at the same time and can't decide what to highlight. ↩

  4. Developers who are good at UI can be bad backend technicians. Backend wizards can be terrible UI designers. I don't know which is harder though—for the UI wizard to come up with reasonable, long-term backend design, or for the backend wizard to come up with visually acceptable and actually usable interface. ↩