Why We Released Buggy Software | Hacker News Reader

Why We Released Buggy Software

blog.holler.com

17 pointsnatasham2523 comments

"Because this is the first iPhone app I ever built, after taking a 6 week class on iPhone development in Atlanta".

You could have just said that, and people would have nodded and said "good on you". The rest of this post actually sapped your credibility.

If that was the point of the post that's what I would have written.

Oh. Why did you release buggy software then? I assumed the point of the post was the answer to the question posed in the title. Sorry.

It wasn't because I had just learned ios development. It was because we wanted to get feedback.

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 dont think that would have made for a good blog post.

Agreed :)

"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.

No one is born writing elite code, and the question is one of overcoming fear to conquer new ground, even if modestly at first.

Yes, but subjecting other people (especially paying ones) to your novice code is kinda iffy.

Not if it gets the job done.

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.

(signout from subthread)

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.

Hey. Kudos on shipping!

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 :)

Thanks for the feedback! I'll update the post ... that's what I get for a midnight article :)

> 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.

Well, does your updated version still crash once in a while?

Not only do they release buggy software, they also crash IE8 instantly.

The homepage crashes in IE8 for you?

http://blog.holler.com/ crashed IE8 (using Vista SP1).

Reply on news.ycombinator.com