A failed app

Two weeks ago I failed. I came up against a program I could not write. It took the laws of physics itself to break me, but it happened. I’m disappointed my app couldn’t be made to work, but I’m reminded that no time spent programming is wasted.

The app itself would have been fairly interesting. It started from my forays into cooking. I’d wanted to follow a recipe that listed some ingredients by weight, and I didn’t have a kitchen scale. I had been using the accelerometer a lot at work over the past year, and I knew that it could be used to detect forces. When an object strikes the phone, the accelerometer will go off in proportion to the strength of the hit. I knew that the hit would cause a converging ripple, similar to an RLC circuit or PID controller but that after a little while it will converge to a steady state. I also knew that an accelerometer can detect long lasting forces- that they should always read around 9.8 in total vector force due to gravity when at rest. So I thought it would be a simple matter of detecting the change in acceleration and figuring out a few ratios and I should be done in an hour.

Lesson number 1: Always calibrate your hardware.

I’m kind of cheating on this one, I actually knew this ahead of time. But an accelerometer should read about 9.8 m/s^2 acceleration when the 3 vectors are summed due to gravity. My phone read 10.23, and the reading bounced up and down a bit due to noise. Did my experiments in creating localized black holes finally work? No, my device just isn’t properly calibrated. But if I had written my app without calibrating for this, I would have been off by .43 m/s^2, a fairly significant amount. So before we attempt to measure anything, we’d need to tare the scale, just like you did back in chem class. So at app startup I’d take the last 20 measurements or so and get an average value. That’s the value I’d use in place of 9.8.

Lesson number 2: Understand how things actually work.

Even after calibrating, I was seeing an unexpected result. No matter what I put on there in terms of weight, it always converged back to 10.23. I had been going off of an incorrect understanding of how an accelerometer works. The explanation I had read before was simplified- that a force caused two electronic components to move closer or further from each other, and that moving closer caused a change in capacitance that could be measured. Sounds pretty much like a scale in my mind- scales work the same way but with a spring and using Hooke’s Law instead of capacitance. The difference is in how the device is set up. In a scale, the spring is anchored to the base of the device, so the weight will continue to depress it. In an accelerometer, both the moving part and the detector are attached to the same part of the phone- a force hitting the device will push it down briefly as the two will move independently briefly (sort of like how a stick will bend when you swing it) but it since the two pieces are both attaches to the circuit board they’ll be effected equally strongly in the end. So the weight will not effect the sensor after the initial movement.

This is a general problem in programming. How much of the code you use do you actually understand fully? How many of the libraries you use could you write yourself? Every black box is an opportunity for major misunderstandings like the one above.

Lesson number 3: Think things all the way through before coding

So we have a pulse of acceleration rather than a permanent increase. I can still measure that peak, can’t I? So I’ll look for big changes in values and count that as the acceleration due to weight. Not too much of a change. I quickly coded it up. The problem was it wasn’t consistent. As I put the same weight on a few times I got very different values. After swearing for a minute or two I really thought things through. According to Newton, F=ma. But that’s a simplification- really force is the change in momentum, delta mv. Putting an object on the phone the final v is 0, so F=m*v_initial. The problem is that there’s no way I can place the object down with the same v_initial every time. This wasn’t going to work either.

Every coder wants to jump into coding. Its fun, or we wouldn’t be doing it. But if you jump into coding without thinking things through, you make mistakes. You’ll spend more time fixing those mistakes than it would take to do it the right way from the start. Understand what you’re doing before you do it.

Lesson number 4: There’s a time to give up

At this point I knew I wouldn’t be releasing this app, but I was in a stubborn mood. I had one more thing to try. If I dropped an item on the phone from rest, the only force on it is gravity. That would cause it to hit with a fixed speed if dropped from a fixed height. There were two problems with this. First, the smaller the distance you drop it from the more small mistakes in distance matter. And you don’t really want to drop things on your phone from a foot off- not unless you want to get rid of your phone. The other I was reminded of when I tried dropping a bag of flour (hey it had a weight on it, I knew what it should read!) on it. In the real world, collisions aren’t perfectly inelastic- the bag moves inward when it hits, taking some of the energy of the collision and causing the reading to be too low. And that was it- no way to fix that problem. And given the number of other issues, I wasn’t about to continue to look for subcases that could be solved. I was done.

I failed, but I learned. And in the end, that’s what I’m looking for in these little apps. I’m not going to sell one of them for millions- I’m just looking to figure out how to do things and have some fun. I even ended up with a couple pieces of code that could be repurposed for later use. I’ve had worse failures in the end.

One thought on “A failed app

  1. Binghammer

    This is very cool. I just had my own failure like this too. Wasn’t for an app, but for a library. I was spending ridiculous amounts of time on it. I knew even if it was a useful library, it wouldn’t be worth my time let-alone the amount upkeep it was going to need. Then you fall in this circle of – “Well i have spent so much time on it, I need to keep going” vs “I have spent too much time on this, I need to move on”.

    When I finally threw in the towel, I felt like i had wasted the past four weeks. But like you said, “No time spent programming is wasted”.

Leave a Reply