Guide to developing mobile apps – Don’t optimize too early

This is the 3rd in a series of posts that are intended to remind us all about some of the important do’s and don’ts of mobile app development.  Be sure to check out the first post on allowing for rapid development and the second on testing.

Don’t optimize too early

There are 2 important ways that I avoid optimizing too early, because I have been screwed by both of these several times.

  1. Don’t optimize your functions for performance or to reduce the amount of code.  There are so many instances where it is possible to take 5 lines of code and to alter it so it can be one line of code.  If this is the kind of thing that makes you happy, then great, do it at the end of the project.  Doing this type of thing early on is detrimental because it makes the code less readable and less understandable.  As a result of this, the code is much harder to debug and update, and you will almost certainly have to come back to this code and at least understand it and probably have to to update it.  There are some times when it will be important to leave yourself a comment to come back and update something because it is written in a way that is not as performant as it could be, but you can leave it that way at the beginning just so it is easier to understand.
  2. Don’t go out and find the latest and greatest library for your app.  I spoke on this earlier in allowing for rapid development when I told you to use libraries and frameworks that you are comfortable with.  When you use new and unfamiliar libraries, there are many pieces of it that you probably don’t understand yet how it will affect your app.  If the library is really new, there are many pieces of it that not many people truly understand yet.  So when issues start popping up, you can’t just hop on over to stackoverflow, because even if the questions have been asked, there is a solid chance they haven’t been answered yet. I have been burned enough times on this that I don’t make this mistake anymore.  There are too many catastrophes to list, but I will point out one successful use of this technique in Jumble-tron 2.  For the original animations in the game, I was using jQuery.  Anyone that has done much mobile web app development knows that jQuery animations are not super performant, but they are super simple to use and they are widely used.  So towards the end of our development cycle for the initial release, it was becoming more and more obvious that the animations were laggy and just didn’t look that great.  At this point I started researching alternatives and found GreenSock.  Now that pretty much the entire app was written, I was able to plug in GreenSock in a small test case and see if there were any repercussions.  There were only a few small changes that I needed to make and the library didn’t break anything else in the app.

For now, this wraps up my short guides to developing mobile apps.  We have covered allowing for rapid development, testing and not optimizing too early.  If you are at least aware of these 3 things as you are developing, you will be a lot less likely to make as many of the dumb mistakes that we made in developing Jumble-tron 2 – Electric Boogaloo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s