AnDevCon 2013 Recap

Last week I attended AnDevCon, the Android Developer Conference, in San Francisco and had a great time. Although I was probably one of the least technical people there, I did learn a lot and even created my own app (https://github.com/bryanro/later-android). I attended with fellow BlueFletch-er Matt Mehalso, who is far more experienced with Android than I am, and he got a lot out of the conference as well. Props to AnDevCon for catering to a wide variety of skill levels.

Common Themes

We saw some common themes and topics that continued to pop up throughout the conference:

• Android First: In the past companies who wanted to build a mobile presence would start with an iOS app and if that worked out they would move on to an Android app. We heard from multiple people (developers, company founders, consultants, etc.)  that the trend is starting to change and some companies are starting to create Android applications first.
• Automated Testing: Automated testing for Android isn’t fully mature yet, and it seems like a lot of people are trying to get into this space.
• App Monetization: We saw a lot of companies at the exhibit hall that were touting their “#1” status as most used in-app advertiser. (How can everyone be #1?) By the nature of BlueFletch’s enterprise clients, I’m less interested in this aspect of Android applications, but for a single developer or a small app development shop I can understand the need.

Twitter Keynote on Continuous Integration

Jeff Seibert gave a great keynote presentation on Continuous Integration. First of all, Jeff is a very talented engineer and entrepreneur – two of his companies have been acquired, the most recent of which being Crashlytics being acquired by Twitter. And he’s only 24 years old! It makes me feel like I haven’t accomplished anything, but then I realized that he’s just one of the smarted 0.0001% of people in the world.

Jeff started the presentation by talking about continuous integration for the twitter web app:

• Everyone works off main line – no branching, which takes away time for big merges
• Continuous deployments multiple times per day – never ship stale code
• Encourages automation, and enables rapid testing and iteration

Unfortunately, with their mobile app they didn’t control one key aspect of the deployment process: app store review and approval. Apple’s app store review usually takes anywhere from 3-10 days. This puts a big chink in the armor of the continuous integration process…

• Because the app review process takes a long time, we need to make sure everything is tested very thoroughly to make sure it passes
• Because we are taking a long time with QA, we need to include more in our development cycle
• Because we are going to include more in our development cycle, we need to spend more time on design to make sure we’re developing the right thing
• Because we are taking longer with design, we need to take longer with requirements.

Wait a sec – isn’t this waterfall?

In the end, Twitter couldn’t get more than a 4-5 week release cycle. That sounds pretty fast, but that’s only 12 releases per year. And it doesn’t address one of the big issues – what happens when bugs are identified in production?  By the time that happens, the bugs probably can’t even get into the next release (depending on the severity) – so that’s 8 weeks until bugs are fixed.

So what did Twitter do?

Twitter solved this problem by implementing the following:

• Overlap planning with review process: don’t wait for the review process to finish before starting requirements/design on the next release
• Dogfood: get the pre-beta release out to everyone in the company so it’s actively being tested by a lot of people during the development and QA cycles
• Follow-up release with just bug fixes: instead of waiting for the next release for bugs to be fixed along side additional new features, have a follow-up deployment for each release
• Everyone uses main line with feature on/off flags: similar to the continuous integration practices for their web app, the mobile dev team now also only uses the main line with flags to switch features on and off. For example, incomplete features will be turned off until they are ready to be tested, then they will be turned on. This allows different configurations for different groups – a dogfood group, a beta group, and a prod group that all use the same codebase but have different features turned on/off.

More on AnDevCon?

In summary, I learned a ton of new stuff at AnDevCon and would highly recommend it to any Android developers. If I have some time I’ll try to post some additional things I learned from the conference.