I'm not a Things user, but I'd be pretty annoyed if after two years the only thing they've said is "it's really hard" and the actual feature is still months away.
There are two major mistakes here:
> Before closing this article, I would like to offer a
> cursory glance of where we‘re at right now: We have
> created and deployed both server and client-side sync
> components. Both components are completely general and
> can be used for any application. They have been
> successfully tested using a special demo program. We are
> now in the process of integrating this technology into
> Things.
I suspect they're now going to run into problems while mapping their generalized solution to their use case. And since there is only one use case to support in the first place, it won't have accomplished much except wasting a bunch of time.
> Finally, we must consider scalability. Creating a
> solution for a few thousand users is one thing – creating
> a solution for millions of users is a different beast
> entirely. We have all experienced what happens when a web
> service is accessed by more people than it was designed
> for; at first, the service becomes slow, then it fails
> entirely. It has been our primary goal to create an
> architecture where scalability was not an afterthought,
> but rather built-in from the beginning.
Judging by the comments here (and in the original blog post), in the amount of time they've spent trying to build the perfect, scalable sync framework, they've hemorrhaged a vast portion of their customer base to other apps like OmniFocus (despite the fact that OmniFocus is significantly more expensive).
Now I just type in shopping list on my laptop and when I come to grocery store, it's in my iPhone. Feels good man!