The tale of the software and the sartorial incompatibility

Here’s a cautionary tale that it’s not always the software you need to check when you have a bug: you might also need to try different clothing.

As a small side project, I’ve been writing my own little fitness tracker app for the iPhone. The main novel feature is its privacy statement: the app doesn’t upload your data anywhere. All the iPhone apps I looked at did this, and I don’t want that. If you have an Apple Watch then you get such ap app built in, but I can’t wear anything on my wrists (RSI related), so I had to fix this myself by writing a little app that does the same thing just on the phone.

Not the prettiest of apps, but gets the job done, and no-one is harvesting my data.

My plan is to release this at some point, but I’d been holding off due to how bad the GPS data was when I was out on my daily run - it was unacceptably so at times, making it look more like I was doing the steeplechase through neighbours’ gardens than jogging slowly along the roads:

It’s not just that it looks silly on the map, but this also means that my intermediary announcements (which I find help me a lot when running) would come are quite different points as the errors accumulated, which was frustrating. Had I really just done a 5k, or had I done 4.8l? or 5.2k? If I release this I’ll just get complaints, so I wanted to fix it first. I’d already tried throwing away obviously poor data, so there was clearly more I needed to do to get the trace better, as other apps never seem that bad.

My understanding is that it is common practice for fitness apps to take the raw GPS trace and then on a server try to fit your GPS trace to a map better, fixing it to roads etc. That makes sense, particularly in dense urban environments where GPS performance is likely to be worse yet you have good data about the constraints of routes, but that’s not really suitable for an app where the premise is that the data doesn’t leave the phone, and it’s also somewhat outside my side-project time budget.

I tried a bunch of different tweaks to how I averaged data and how I set the threshold for throwing away data that looks suspicious, but nothing seemed to work.

Then one day, I made a single trivial change, and with that the data was rock solid every run:

That small change?

I wore a different top, as spring time made the mornings warmer. 🤦‍♀️

It seems to be that the baggy pocket on my warmer winter jacket was causing the issue, and when I moved to my lighter weight jacket, which had a much tighter pocket for the phone to sit in, the problem cleared up. I infer from this that when the GPS signal is poor (the area on my run where it always struggles is under large trees), that the phone can use the accelerometer to compensate, but not if it’s bouncing around in a baggy pocket.

The lesson here is obviously one of the dangers limited testing. I was in a slight catch-22 where I didn’t want to release the app to more people to test until I’d fixed the GPS issue, but had I done so I’d probably have realized much more quickly that it wasn’t a software issue (or at least, an issue with the software I wrote). Because I had limited data I fell into the trap of assuming it was a bug in my code - which is usually a safe first bet with ones own code - and once I started down that path I didn’t stop to step back and think what else might be responsible.

So, next time you’re scratching your head on an issue that doesn’t make sense, hopefully you’ll remember this silly incident and take a step back to see what other externalities might be causing your issue. Where as for me, I’m going to add a sartorial dependencies field to my bug tracker ;)