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:
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. 🙂