Slide from my presentation — “Effective mobile engineering”

The focus of an engineer’s early career is code. We aim to code fast, elegantly and with few mistakes.

As we gain experience, we learn that code is only worth something when it becomes a working product. We also learn how much more to the job there is than coding. Internal app distribution, updating images and translations, version control, releasing to the App Store/Google Play and many other competing business priorities 🤯.

Very often, you hate the non-coding stuff. Like that visit to the gym, you find imaginative excuses to do it as rarely as possible. Like once per month. And it takes forever.

But there is another way. Build automatic processes. Let a machine do the tedious work for you. Once per week, once per day or on demand.

Can you ship your app once per week?

Two years ago we were releasing the Azimo apps once per month. We sometimes waited 30 days to release a completed feature. We then had to wait another 7–21 days until we had enough data to validate whether users liked the feature or not. If the feature failed, it failed slowly 🐢. We needed at least another month to release an iteration.

We now release once per week. This frequency brings a number of advantages:

Fewer things can go wrong (see: Murphy’s Law). The larger release, the larger the list of things that can crash.

Fewer things to keep in mind. Can you remember your last four weeks of code? What happens when QA catches a bug from the first few lines that you wrote? They’re unlikely to be fresh in the memory.

The business learns faster. Less of your work is thrown in the trash because you have more chances to adapt your approach.

Slide from my presentation — “Effective mobile engineering”

Identify all the steps

As junior engineers, we thought a release cycle looked like this:

Coding Testing

a. Something wrong?

b. Fix it Release

How could something so simple take an entire month? Usually because important things are hidden between the lines. The reality looks more like this:

Coding

a. Manual tests

b. Write down what’s new

c. Import new assets — translations, images

d. Compile and build APK

e. Distribute APK internally Testing

a. Something wrong? Return to step 1.

b. All fine? Continue to:

c. Build and sign production APK

d. Add release notes ✍️

e. Internal distribution of production app

f. Manual testing of production app

g. Store upload, including screenshots, what’s new, copy updates Release

a. Staged rollout from 0 to 100%

b. Monitor issues

c. The app is finally live to 100% of your users

How long does it take to complete the above? Those are our numbers before we improved and automated our process:

Internal build and testing: 2–3 hours, multiplied by the number of times QA send back the build

Testing process: 1–2 days, assuming QA is available immediately

Production app distribution: 2–3 hours

With a weekly release cycle, that doesn’t leave much time for coding.