Incremental Change

Applying Incremental Changes to Our House

A key to success with programming is learning to experiment and make incremental changes. Testing those increments is critical to understanding if your change achieved your goals or made wider reaching impacts than expected.

From year to year, environmental changes are incremental and often barely register in our lives, but from evolutionary or geological perspectives, what is happening is explosive change.


David Suzuki

Like evolution, our code evolves slowing as we add features, we break things, we fix things, and push for the release line. Many commits are required to build the bedrock of the apps we ship and the features our users take for granted.

Sometimes in the rush to ship we miss testing some of these changes. Like evolution, these missed increments can explode when they reach our customers.

I hit my first shipping crash in one of my apps in the AppStore this past week. In this case it was with Selfie Band, my camera remote for the Microsoft Band. Selfie Band tries to install the camera remote tile (it's app view) on it's paired Microsoft Band.

It looks like one user had a very bad experience when they ran into the bug. They tried repeatedly to get past the problem but it looks like they crashed multiple times during this. I know this since I use Crashlytics crash reporting in my apps.

The bug manifested itself when the Microsoft Band had no remaining space for tiles and returned an error. I had incorrectly changed some error handling code and forgot to retest it.

So, being in Swift, my null point access crashed the app instead of silently failing as many of us Objective-C programmers are used to.

It was a silly mistake and I have fixed it and shipped the update to the AppStore. I just need to pass review and the fix will be live.

This bug reminded me to slow down and verify that incremental changes don't lead to a crash.

The competing priorities to ship and to create quality software can be hard as an indie when you have no teammates looking over your shoulder to review your code. The end user will feel the brunt of your mistakes and so will the impression you give your customers.

For me here is how I am addressing this as the sole programmer:

• Commit often to git
• Review my checkin like I would someone else's code
• Why did you do this?
• Was it tested?
• Are there loose ends?
• Should this be committed or reworked/retested?
• Using branches to switch between features that I want to revisit
• Reevaluating a change when it gets too large

Don't let your incremental changes lead to explosive releases.