Brooklyn iOS Developer Meetup recap: Shake completely redid all of its code

Shake got a new VP of Engineering and it didn’t take long for him to settle into the work of completely rewriting its entire code base.

Shake was one of three organizations that presented at the latest meeting of the Brooklyn iOS Developer Meetup group. The event took place at NYU MAGNET.

We previously wrote about Shake’s Brooklyn based cofounder.  The company makes easy-to-understand, customizable contracts that can be shared and signed on mobile. The service is only available on iOS devices so far, but Android and web versions are coming.

Jonathon Storer, VP of Engineering at Shake. (Photo by Brady Dale)

Jonathon Storer joined Shake eight months ago.

He described the app’s code base when he came on as two years old and loaded with technical debt.

Storer said that a good developer who’s working hard to get better should be pretty disgusted with their own code within a week or so of writing it. One aspect of the code base that particularly bothered Storer was what he viewed as an over-reliance on notifications, as opposed to delegates.

Storer also wanted to up the company’s commitment to testing. He said, “I’ve come to learn that testing is less of a thing in iOS.” He showed a number of tools that teams can use to write tests for their code, to make sure the app does what it’s meant to do for each task.

He has settled on Frank for his team, a testing system based on Zucchini. He said he likes Frank because the system doesn’t need to know or understand anything about your app.

When it was all said and done, the Shake team had added 4,518 lines of code and taken 4,608 out. It was nearly a complete refactoring.

Klaas Annema, mobile developer at Karma. (Photo by Brady Dale)

Karma is a hardware device that provides you with pay-as-you-go Internet access anywhere.

Klaas Annema, the sole mobile developer at the company who built and maintains both the Android and iOS apps, described his basic process for iterating as a one-person team.

He lets five principles guide his work:

• Keep it simple stupid. Make small changes, small iterations. Don’t worry about solving every possible user problem with every possible feature if no one is asking for it yet. He realized, for example, that if the app defaulted to using the credit card the customer used to buy their device from the start, it made the app easier for everyone.
• Stay fresh. Annema ships a new beta every Friday, even if it just has a very small change. It’s a standing deadline he has for himself to keep moving.
• Non-modal. Don’t add elements that hinder a user’s flow through the app.
• Test first. See above.
• Early feedback. Annema has a group of roughly 30 beta users who try out new features.

As a one-person shop, Annema’s larger workflow is, effectively, take a week to develop a feature for either Android or iOS. Ship it. Then do the same feature for the other version.

The company is currently looking for an Android developer and a few other roles.

Orta Therox, of the Artsy iOS app. (Photo by Brady Dale)

Orta Therox told the story of Artsy’s breakneck mobile app build process.

Traditionally a website, the company realized it wanted a mobile app that could do much of what the website could.

Artsy is a sort of Pandora for visual art, and it has 65 employees and 15 developers.

The organization has 150,000 artworks in its digital collection, with permission to use all of them. A big vertical for the company is Artsy for galleries and art fairs. “There are an awful lot of stakeholders involved in planning Artsy,” Therox said.

Therox said that when the team began work on its mobile app, they isolated a few ways that people tend to use mobile apps: when they know what they want (verification), when they sort of know what they want (search), when they just want to be entertained (discovery) and when they want to know about things they are interested in changing (alerts).

A few tips from Artsy’s process of building from scratch:

• Reveal was the tool the team really came to rely on to see what was going on in the app.
• “Authentication is the first thing I would do from now on,” Therox said. With the Artsy app, they did it last and regretted it.
• He did so much QA in the app that he actually started to lose skin on his finger from all the swiping.
• Use open source code. The Artsy team used as much as they could and contributed what they made or forked.
• Create an offline mode. Therox always builds a robust offline mode into all his apps. It’s food, for example, for permitting him to keep doing QA when he doesn’t have mobile Internet access.

See his slides here.

Once he got the app done, shipped and it seemed to be working, Therox built in some Easter Eggs. If you’re an Artsy user, you can see the whole app rendered in ASCII (including the art) by using the Konami Code, (↑↑↓↓←→←→BA). Try it out.