To me, this was the point of the post: You see, the app, and more broadly Holler in general, can never possibly meet our expectations. We have spent months dreaming about the immense value we could bring to peoples’ lives with our product.
The reality is that it is only the users that will be able to tell us what value we can bring though. That’s why we decided to launch.
So even though the app wasn't perfect, not just incomplete but actually buggy, it was still usable enough to start getting feedback from users. Of course there's a line somewhere, if the app crashes for everyone you aren't going to get useful feedback. But if it mostly works and crashes occasionally, you probably will.
"I was merely a web developer, not an iPhone developer"
Thinking that alone is a mistake -- there is nothing magical about iPhone developers, and ios programming can be learned quickly. If you're doing a startup, you can't believe anything other people are doing is impossible to master.
(that may very well be the case, but it always warrants investigation)
That's not really true. For the most part (no, this isn't true everywhere, but for the most part), the tolerances are a lot looser in web development, in pretty much all areas. Unless you're getting pummeled on inadequate hardware, your performance choices in the backend of a web site or web app are probably going not going to harm anything.
If you make bad performance choices on an iOS application, you'll create a stuttery, ugly mess (smooth scrolling in an iOS application is surprisingly nontrivial) that will--unforgivably--sap a user's battery and ruin their experience.
People are a lot more forgiving of 2ms greater response time on a web page than a web app that drains 4% of battery in five minutes.
Yes, even if it gets the job done. Because if it gets the job done poorly, by causing significant battery drain or performance problems or other hallmarks of bad code, you are mistreating your users.
Novice code isn't necessarily imbecilic code, you're conflating the two. If I'm otherwise proficient and have a grasp of hardware conceptually, my iOS code isn't likely to do those things you stated.
I agree with the 'release fast and often' approach. However, this is just an example of really poor testing. If a key button on your app causes it to crash, then there is no justification for that. You also pissed off a bunch of your users and many won't even bother to update.
It's all fine and good getting a very basic v.1 out to get feedback - but it shouldn't crash due to an easy to detect bug.
My honest feedback would be that your main point is lost in the story. Even though I read the whole article, the thing I was left thinking when I finished was that the root cause of your problem was 1) the failure of your contract developer to deliver and 2) you rushed an early version of the app out in 6 weeks without sufficient testing.
For what it's worth, leading with a clear apology to those affected by the problem would do no harm.
It would also help if you explained more clearly what _exactly_ you wanted to learn from the release that justified the impact of this bug on users. Eg, some key hypothesis or assumption in your business model or product roadmap etc.
> We are now well aware of the problem and have since submitted a version that fixes the problem for the vast majority of users.
Well, you either found the problem and fixed it or you fixed something and now hoping it was what was crashing your app. Or you have multiple crash points in the app. If it still crashes - fine, you have more work ahead of you. Just don't try and twist words to make things look better than they are.
I can only laugh at this comment "don't try and twist words to make things look better than they are". Not twisting words, it's pretty straight forward.
23 comments
[ 2.7 ms ] story [ 55.3 ms ] threadYou could have just said that, and people would have nodded and said "good on you". The rest of this post actually sapped your credibility.
The reality is that it is only the users that will be able to tell us what value we can bring though. That’s why we decided to launch.
So even though the app wasn't perfect, not just incomplete but actually buggy, it was still usable enough to start getting feedback from users. Of course there's a line somewhere, if the app crashes for everyone you aren't going to get useful feedback. But if it mostly works and crashes occasionally, you probably will.
Thinking that alone is a mistake -- there is nothing magical about iPhone developers, and ios programming can be learned quickly. If you're doing a startup, you can't believe anything other people are doing is impossible to master.
(that may very well be the case, but it always warrants investigation)
If you make bad performance choices on an iOS application, you'll create a stuttery, ugly mess (smooth scrolling in an iOS application is surprisingly nontrivial) that will--unforgivably--sap a user's battery and ruin their experience.
People are a lot more forgiving of 2ms greater response time on a web page than a web app that drains 4% of battery in five minutes.
(signout from subthread)
It's all fine and good getting a very basic v.1 out to get feedback - but it shouldn't crash due to an easy to detect bug.
My honest feedback would be that your main point is lost in the story. Even though I read the whole article, the thing I was left thinking when I finished was that the root cause of your problem was 1) the failure of your contract developer to deliver and 2) you rushed an early version of the app out in 6 weeks without sufficient testing.
For what it's worth, leading with a clear apology to those affected by the problem would do no harm.
It would also help if you explained more clearly what _exactly_ you wanted to learn from the release that justified the impact of this bug on users. Eg, some key hypothesis or assumption in your business model or product roadmap etc.
Good luck with the next iteration :)
Well, you either found the problem and fixed it or you fixed something and now hoping it was what was crashing your app. Or you have multiple crash points in the app. If it still crashes - fine, you have more work ahead of you. Just don't try and twist words to make things look better than they are.