The Importance of Baking Your Apps

Baking your applicationsI see a lot of companies who move at a neck breaking pace and crank out their application iterations at alarming speeds. Just as users upgrade their client and run it, they are met with another update message. Users start finding themselves constantly updating to keep up. This is usually the result of short cycle agile methodologies that doesn’t wait to batch their fixes and features. From a development standpoint this seems advantageous. We can crank out the next update and appear very responsive to the user’s demands. Have a bug? Don’t worry, a new fix will be out in a day. Have a feature request? We like it, it will be out the next day.

You may like the constant rollouts, your users may not

So what is the problem with this? Well if you are a power user that loves tech there is no problem with it. If you are a “normal” user then it can get quite tiring to see that update icon/message popping up every other day. Then when they update they don’t really see a difference. That is because the update was to add a different options screen deep down in the app that no one encounters much anyways. I am sure everyone has seen an update and thought “Wow, a new version! Let me check it out!” and then download. Then they are left asking “What exactly was changed?” Some power users may eventually go search for a version log file only to see like 3 changes which address severe edge cases. But most people really won’t take the time to do that and may abandon the software entirely.

When cracks start appearing

I have seen software companies that move so fast that they eventually start rolling out subpar features and inadequate fixes. They send out a fix only to have to issue a fix for their fix. Then a fix to fix that fix. Or they release a feature before the idea has been fully refined. They instead let the users voice their concerns as a way to refine the concept. So you end up seeing the same feature go through multiple iterations which may even be dramatic and give the message that “this is unstable”. Prime example is Facebook which is redoing a feature every other day. I have seen software go out with multiple versions in a single month. I have seen software go out where the same feature was fixed three times in the same week. Stop the madness!

Take a moment to solidfy what you are doing

When asked, I always advise that these companies take a moment every once in awhile to hold back some updates, strengthen the code base and features and then release one really solid update. In other words “let the application bake with QA for two or three cycles”. It is perfectly ok to release regularly and often as long as the features and fixes come out solid but when you start seeing fixes to fixes, don’t be afraid to put on the brakes and work on a general improvement of the application as a whole. You may want to do this even if you don’t see the cracks! This will give your users a chance to catch their breath as well. Then when the new update finally comes it is a wonderful update and they can see what has been changed and everything works like it should. If you are releasing every week, maybe every few months take a whole month and strengthen the code base (not add a new feature, just fix what you have been doing).

The sky won’t fall

I find that a lot of software companies think that if they slow down just a bit that the market they are pioneering will wither away and die. That if they don’t get their software out on a Monday that Tuesday will be too late. Only on the rare occasion, where you are beating a competitor to the punch, would that be true. It often doesn’t matter if you take a few extra cycles if it means that once the app is released it will be solid and something you can go back into fast iteration with. The sky won’t fall while you are making these adjustments. If anything you are reinforcing the sky with stronger pillars.

In the end it is all about quality and image

If your company is known for releasing top quality applications and has the image of respect in the market place, your users will wait for the next update. They won’t wait forever but they will give you some lead time to make sure things work great when they do get it. They don’t want to be constantly updating to feel like they need to catch up. They wan’t timely updates but in the end they want quality. They want software that just works and want to support companies that aren’t afraid to take a step back and make sure what they are putting out there is the best for their users. In a way, it is saying to the user “we care about you”. I have seen this concept work and apps that were once 2 star apps go to 4 star apps overnight. Be agile, just not too agile.

Thanks for reading! 🙂

About The Author

Martyr2 is the founder of the Coders Lexicon and author of the new ebooks "The Programmers Idea Book" and "Diagnosing the Problem" . He has been a programmer for over 20 years. He works for a hot application development company in Vancouver Canada which service some of the biggest tech companies in the world. He has won numerous awards for his mentoring in software development and contributes regularly to several communities around the web. He is an expert in numerous languages including .NET, PHP, C/C++, Java and more.