Back to Apping, Part II

When people find out (I try not to mention) that I’m a programmer, invariably they chirp in with, “Oh! I’ve got a great idea for an app! It’s a doozy!” And (unprompted) they go on to tell me how, for example,

  • it calculates sums of numbers (App already included with every phone), or
  • it makes amusing noises (Apps done to death), or
  • it uses the FBI facial-recognition database to spot disguised celebrities and/or escaped convicts in your local Lidl (App requires discreetly accessing the FBI facial-recognition database), or
  • it’s like Minecraft/Fortnite/GTA X but with way better graphics/gameplay.

And then they suggest I code that for them. “We can be partners!”

Well, “app ideas” was never the problem. I already have a list as long as my arm for app ideas. The problem is always Time. And lack thereof. Yesterday, I read through Apple’s app review guidelines, which is enough to make anyone’s eyes bleed. And that’s just reading it.

I need to introduce you to one of my laws. I call it “Philip’s First Law of Coding” because I’m Mr Vain. Here it is:

Coding will always take at least three times as long to do as you say it will, even (or especially) when you try to take into account Philip’s First Law of Coding.

Philip’s First Law of Coding, (c) PBG circa 2015

Star Trek’s Scotty knew just how long it would take to repair something, multiplied that time by a factor of four in his estimations and then everyone was mightily impressed when he managed it in a quarter of the time he said it would. Scotty’s a git! If I think something will take a month, I might decide to say that it’ll take three, and then it’ll actually take nine. Yes, it can be extraordinarily tricky to guesstimate how long even a simple project can take, especially when I am confined to two-to-three hours a day to work. There are all sorts of things which crop up:

  • unexpected and mysterious memory bugs that the debugger can’t handle;
  • new OSX/iOS/XCode (old code suddenly stops working, or works differently);
  • new code A requires recoding old code B, and then B affects C, D & E, which need adapting and testing, and then D dominoes into the rest of the Roman alphabet and threatens the Cyrillic;
  • hardware problems (failing hard disks is #1);
  • problems due to stupid initial decisions (mostly from severely underestimating complexities);
  • real-life emergencies, illnesses of all flavours, mood-swings and depressions, weather too hot or too cold, rain-patter too loud against the ceiling window, and so on.

This isn’t just a problem for coders. Please do take a moment to read up on the history of the upcoming Game of Thrones book, The Winds of Winter. In case you didn‘t just do that, here’s that link again. I did say please! I am pretty sure that Mr Martin is not a slacker and that he was being entirely honest with all of his completion estimations. Finishing even a simple project is tricky and takes times to do right. I know, because I’ve been spending many, many years writing my own software library, in order to code an app that will change the world.

More about that in Part III. 🙂