eventually consistent

Here’s another example of Apple’s iPhone AppStore model failure – the TwitterFon example.

TwitterFon is a (great) Twitter client for the iPhone. All Twitter clients rely on Twitter’s public API. Twitter is one of the stars of the Internet social medias / social networking applications. Like most Internet application startups, they have an agile development model which involves doing lots of incremental modifications/enhancements on their platform with frequent release cycles. Also like most Internet applications/platforms, they offer a public API for 3rd party applications to connect to their platform. Note that In the case of Twitter, the bulk of their traffic comes from their API and not from twitter.com. More generally, this model is the new model for Internet applications and platforms development.

This is where iPhone app developers have a problem: they develop native iPhone apps that connect to these Internet applications through their API but can’t keep up with these because of the slow AppStore approval process.

Case in point: TwitterFon. This morning when I tried to launch TwitterFon, it crashed on startup. Tried again, no go. Tweetted about it from my laptop and received a reply of similar problems from a friend. A few minutes later, the @twitterfon Twitter user started following me so I went to check it’s user profile and tweet stream to see that it was discussing the issues and also gave a link to it’s blog, here’s a quote:

The root cause is that twitter respond JSON contents which contain unexpected values.
[...]
I have already submitted a new version which implemented a workaround to address the issue, but it will take a few days to get an approval from AppStore. Also, I reported the issue to Twitter. I hope they fix the issue soon. Otherwise, you have to wait until Apple approves the new version of TwitterFon.

Now, can you see the problem? On one side you have agile Internet application developers which move fast, release often. On the other side you have Apple’s slow, bureaucratic AppStore approval process. In the middle you have the iPhone who want to be the best mobile Internet device.

If you want to be the best mobile Internet device you have to be able to cope efficiently with the Internet speed development style, period. In the TwitterFon example, we don’t really care if Twitter introduced a bug or not in their API that killed TwitterFon: by today’s standards, everyone must be able to move fast and in our example the only one that can’t move fast is Apple with its boggus AppStore model. Fail!

Correctly choosing your partners, colleagues or employees is critical and must not be overlooked, in particular in a startup environment where resources are scarce and each individual contribution must be maximized. Conflicts between colleagues will drain energy and divert focus from the important issues.

When doing interviews, one personally trait that is important to asses is perfectionism.

It is easy to be fooled by someone admitting to be a perfectionist because, somehow, we often view this as a quality. We probably believe that a perfectionist will be someone striving for accomplishments, who will be motivated to persevere in the face of discouragement and obstacles. It is important to pay attention to the level of perfectionism in an individual to make sure it will stay at a healthy level of motivation and energy.

Unhealthy perfectionists will exhibit some of these personality traits: emotional guardedness, need for control, fear of failure, need to be above criticism, tendency to be stubborn or confrontational. Negative perfectionism can result in low productivity as individuals lose time and energy on small irrelevant details of larger projects. In the context of a startup, negative perfectionism can have serious consequences on the enterprise, yourself and your team.

One of the important concepts of an agile development environment is to “release early and release often” which condemns you to making lots of compromises. To release early and release often means that you have to be able to accept the fact that the product will not be at the quality or completion level where (you think) you want to bring it in time. To achieve this, scopes must be kept small and progress most be done in iterations. This means that you must be ready to make compromises on some aspects of the project and stay focused of the really important stuff. In other words, you must be ready to accept to do less and probably below your “quality” level and then iterate toward improvement.

When choosing a colleague in an agile startup, make sure you choose someone who will be able to cope with the compromises required for such an environment.