The following is from a draft from 2010-09-29. It’s not particularly insightful, which is probably why I never hit the “publish” button. At the same time, it’s just interesting enough to me that this rule of thumb appears to apply to mobile apps. Maybe someone has an idea as to why it might be the case?
Having just had a discussion with an esteemed colleague on the time taken on developing mobile (iOS, Android) apps, here’s a pearl of wisdom: if it takes longer than a month or so to develop, you’re doing something wrong.
I need to qualify this a little (but not much).
- I’m talking about a man-month, but also about a wall time month. Writing a new app tends to involve a lot of boilerplate code, where adding a second developer does not do as much as you might think. After about two weeks into the project, your second developer will be helpful. So if you have two developers, make that about 6 man-weeks, to be completed within a wall time month.
- That’s development time. Adding another two weeks of bugfixing and QA is not wrong, just make sure that not a single line of code is spent on new features or tweaks to existing features.
- You could also spend about a week before designing what the app should do and look like. Again, that’s not wrong.
And then you release.
Unless you’re in (the very small segment of) the market for highly paid apps, chances are you need to release at that point to get an impression for what users make of your app. If it’s picked up well enough, then you can repeat the exercise.
And at that point it becomes fair enough to release a new version after two weeks, or even two months, just don’t make it longer. You should be best served with hitting one-month release cycles.
First of all, there’s a good chance nobody will like your app. It’s not that people will hate it per se, it’s that on average you won’t be scratching exactly the itch the majority of people have. You’ll be doing something very similar instead, and people don’t tend to like that.
So don’t waste months and months of your development time only to figure out that people don’t like your app. Get feedback often. Getting feedback too early – say, after a week’s or so development time – can result in your app being too light on features to receive any positive feedback. A month is plenty of time, as a rule of thumb, to get something useful done.
Second, if you listen to your customers and release a new version a few weeks after the first, you’ll stay in their minds. They’ll get the update notification. Their download might even contribute to your overall download ratings, and push your app higher up the list in the App Store/Android Market. You’ll prompt users that previously gave mediocre feedback to re-assess their opinion and possibly give better feedback.
So if your concept is too large to fit into a month’s development time, chances are that your concept is bad, either at it’s core, or simply that it’s way larger than it should be. Trim it down to the point where you can get it done in about a month, and you’re good to go. Then iterate.