What Is SongKiwi and Can I Participate?

Full disclosure – this post is also a bit of shameless self promotion.

I’ve had an idea for a website / webapp for quite some time and I’ve recently been working on bringing it to fruition.  I’ll be chronicling the progress here on this blog.

Due to the nature of the Internet, Startups, and the importance of being “first” to a particular domain I’m going to be keeping a bunch of details under wraps until ready. 😉 However there’s a few details I can share so here goes.

I’ve always been a big music fan and love to share my passion with other music buffs whenever possible but I’ll concede that outside of a one on one chat with a friend I haven’t found a good online experience to share this energy.

Well with this new site I hope to change that.  What if there was a site where you could share the knowledge and experiences you’ve had with music? Do you remember singing along to “The Power Of Love” in Back To The Future… or what band sung the theme song to Friends… or what song is playing in the background of the latest Doritos commercial?

Maybe you are the local expert on all things U2, Britney Spears, Garth Brooks, Psy, One Direction or Daft Punk? If you’ve into music at all you’ll likely enjoy what’s coming with SongKiwi and should sign up for more information and to get on the beta invite list. I promise it will be both fun and useful.

Signup for information on the SongKiwi beta.

I’ll try and give a bit more info in posts to come especially when a bunch of the technical details have been decided upon. HTA6UNSTYW9W

Native Mobile App Design Flaw #1

This isn’t going to be (or at least it certainly isn’t intended to be) a fight-inducing post about native-vs-HTML5 apps on mobile… but rather something I’ve noted as a bit of a flaw of the new Native Mobile App model where you download an app from a specific App Store/World/Marketplace.

For those of you that have been around the Interwebz since the beginning (or at least say… circa 2000) you’ve likely noticed that most applications you download for your computer (PC, Mac, or Linux) have gotten faster and faster as the years go by.

There’s 3 major reasons for this:

  1. Internet connection speeds have massively increased from our measly 56k dial up modems
  2. Use of CDN (Content Delivery Networks) has improved things so that you download from a server that is geographically closer to your location
  3. Vendors now provide a quick download installer that fetches the required resources only when you start installing the application

Item #3 is the key.  When you download the latest version of say “Mozilla Firefox” you get a tiny installer that downloads in seconds.  Only once you start it up does it do a quick inspection of your hardware (to find out if you need the “Windows 7 32bit” files, or the “Windows 8 64bit” files for example) and maybe asks if you want language packs, extra features, etc. then downloads only the assets you need for your installation.

The same applies whenever you want to get an update! You download the new parts that you need and essentially “patch” your existing installation.

This is where the flaw comes into play with Mobile Apps downloaded on your smartphone or tablet.  The publisher of say “Angry Birds” (Rovio Entertainment Ltd. btw) (weighs in at: 39.9MB) might have fixed a typo or a silly off-by-one error amounting to less than 100 bytes… yet every user that wants to get that update has to re-download just shy of 40 MB of data!

Not only is this a major waste of network bandwidth but if you are applying these updates over your 4G cellular network while whipping down the highway at 75 miles/hour (120km/h for the metric folks) you’re not only putting unnecessary stress on the cellular network, and your battery… but brutally eating into your bandwidth cap (for those that have them) or (gasp! roaming data charges!). You should be saving that precious bandwidth for watching funny cat videos! 😛

This feels like an epic failure to me to have come so far with online software delivery… and then just throw it down the toilet and re-download entire apps whenever there is the slightest change.

Now I do realize this is quite a challenge to solve as you’d need to provide a smart solution that accounts for literally 1,000’s of developers coding styles/structures.  Some sort of magical binary diff… but that’s what motivates us developers! A Challenge! Announce: “It can’t be done!” and dozens of developers will stay up all night to try and prove you wrong!

Ok, time to play Devil’s Advocate

  • I guess if you had a hybrid app with a small native wrapper that loaded most of the content from a remote server on install/access and cached it as “app related files” then you can overcome the “big download hit” for updates.
  • HTML5 advocates will point out that this is how & why the HTML5 appcache was designed.  Enable smart caching of the resources that can be cached and used offline and only fetch fresh resources as/when needed.
  • A native app with a collection of simple WebViews could combine the benefits of the above 2 items for an app that might never need updating yet always be up-to-date.
  • I’m sure there are a bunch of bright developers that have already taken one or more of the approaches above (even for completely different reasons) but serendipitously solved this problem.

What’s your thoughts? Are we messing things up? Will it all not matter the closer we get to wireless “Gig-E”? Or will the big mobile vendors (Apple, BlackBerry, Microsoft, Google, Mozilla) come up with an ingenious solution?

Scary Code – Red Flags

Every time I navigate through code there are things I see that I would call “Red Flags” that are indicators that either the previous developer(s) didn’t know what they were doing or they built a fragile system.

Here’s a few of the one’s I’ve seen that scare me (and an explanation why if it isn’t obvious). Sadly there are many so I suspect this will be a recurring thread 😉

Red Flag Warning

1.) Anytime I see a variable or parameter named something like “ignoreErrors”.  This could be a totally legit case… but more likely points to either depending on code that often throws random errors or simply not dealing with errors properly and just trying to provide a duct tape solution.

2.) Anytime I see “temp” in a variable name. Again there might be a rare case when shuffling 2 indexes in an array but any other scenario suggests that the developer didn’t spend the time to properly name things and may well have not spent the time to write good logic either.

3.) Anytime I see a catch statement with nothing in it.  If commented with an explanation of how failure is ok then this is fine.  However any other time I see this it looks like the developer left the stub in there to handle later but never came back.

4.) Anytime I see documentation for a method that exceeds the size of the method itself.  This is typically a sign of code master… uhm… what’s that word for when you have the ultimate fun by yourself?  This is a sign of a developer that is actually thinks so much of themselves they feel the need to advertize their skills by going on and on about their code.  More importantly code should be self documenting so if you need to add huge blocks of comments to document your code something has gone wrong.

5.) Anytime I see a method name that ends in a number “2” (or worse yet a 3, 4, 5…) e.g “getBillingInfo2”  This is a sure sign of an initial method not quite being up-to-snuff but rather than the developer fix the method to make it more robust (or provide overloaded/helper methods) a previous developer was lazy and simply cloned the original and hacked in their own stuff.  Other classic symptoms of this disease are methods prefixed/suffixed with “Old”, “New”, “VersionTwo”, “VersionThree”.

Got any “Red Flag” warnings of your own? Let me know and we can share the painful burden of maintaining bad code!

Programming Rule #1

The counterpart rule to programming rule #7 is this one.

Programming Rule #1

“Thou shalt only load the data you need, and only when you need it.”

This is a rule that affects everyone as an end user.  Users can see exactly what content loaded on the screen and when it takes longer than expected the experience is ruined.  As a developer every time I see inefficient code that is loading more than it needs to… or well before it is potentially needed or disastrously even when it is not needed – I cringe.  Its a waste of resources & network bandwidth and it makes screens load slower affecting not just the end user but every developer or tester than needs to wait for that page to load.

Of course the exception to this is when you have a ton of data that makes more sense to pre-load.  That’s fine too (and covered in programming rule #7) 😉

Programming Rule #7

I’m pulling the number out of thin air (as I know I’ll have dozens) and the exact order doesn’t matter but here goes with my…

Programming Rule #7


“Thou shalt pre-load, store locally or cache any static data you can when there is a high probability of re-use and/or you can significantly improve screen loading time.”

For many this will seem like a “duh!” kind of thing but I’m surprised how many developers will not take the initiative to improve the usability of an application by doing this.

For the Web this means put all your scripts, stylesheets and images in files that are served up with maximum caching potential.  For mobile apps this means load your static data lists up front in the initial download or from your server on the initial app startup… just make sure your users know that this delay in the initial load is a 1 time thing.  For classic desktop apps… well do whatever you need to do there… but I suspect similar to mobile the initial install (or the initial startup) is when you want to download the critical assets you need.