Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Lessons Learned from Rushing to Market

DZone's Guide to

Lessons Learned from Rushing to Market

· Mobile Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

I’m still working on my Windows 8 application, King Poker, and have I learned some things this week.  (It’s also available for Windows Phone, btw.)

In general, my app is pretty straightforward.  It’s a video poker application designed to look as similar to the real video poker machines in casinos as it can.  Last week, I got ambitious, and decided to add some functionality that goes above and beyond the core functionality you’d expect.

I added Azure Mobile Services, and if the user was online, every single hand was recorded to my cloud storage database.  In the 10 days it’s been live, I’ve recorded over 45,000 random hands of video poker to my database.

In addition, I added Microsoft Account authentication, which means that if you log in with your Microsoft credentials, I could persist your credit count and hand history across all of your devices.  This is where the story gets ugly.

I spent HOURS writing and testing this functionality.  Log in on my Surface RT.  Play some hands of Deuces Wild.  Log out.  Keep playing.  Log in.  Play some more.  Cut the wi-fi connection.  Play some more.  Reconnect.  Sync the hands that were played when disconnected.  Log in to the Windows Phone 8 version.  See the identical credit count.  If you were logged in to these apps, everything worked marvelously.

When you weren’t logged in, it still worked marvelously.  It still logged your hands in my cloud database.  My mistake was that I didn’t notice that even when you were logged out, it was trying to sync your credits.  Anonymously.

So I pushed this new update chock full of new features to the store.  And it passed.  I was so excited!  And then the negative reviews started flowing in. 

“Used to work well on RT. Last update broke it. Lost all my money, well pretend money anyway. Please fix it”

“This is a great poker game. Play it all the time. However installed update yesterday and now it crashes all the time.”

“Credit counter still going crazy...Change the word HELD...back to HOLD, like in Vegas and Atlantic city...”

As it turns out, everyone that wasn’t logged in was synching their credits with everyone else that wasn’t logged in.  Ouch.

I’ve been really careful about thorough manual testing, as well as running a full suite of unit tests, but this one got by me.  I was so focused on what the experience was like for authenticated users, I didn’t give enough to time to think through all of the scenarios for those people that chose not to authenticate. 

I fixed it immediately, but it was Friday night, and the Windows Store team doesn’t approve apps on the weekends.  It wasn’t until Monday afternoon that my new patch was finally released, and almost immediately, I found yet another issue.  (It’s funny how much more obvious bugs are when they’re in production vs. development.)  I now have to wait at least another day before this issue will finally be solved.

Take Your Time

My point in all of this is to take your time.  I was so anxious to get my new set of features into the hands of my users, I completely neglected to remember that apps that have to go through stores are SIGNIFICANTLY harder to fix than a simple website.  If I find an issue on my website, I can fix it instantly.  In your app, your users may have to suffer through days or bugs before you’re able to fix an issue.  Take your time, get it right, and give your users the experience they deserve.  It’s the only way you’re going to get MORE users.

In short, no matter how great your set of features is, a little extra diligence to think through ALL of the user scenarios will benefit everyone in the long run.  That’s how you build a great app.  Keep your users’ confidence high, and give them a reason to tell their friends about it.

If you’d like to.



Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:

Published at DZone with permission of Jeff Blankenburg, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}