Why you should avoid foresight in code
A large part of software maintenance is simply handling unexpected changes… Whether that’s due to client requirements, or even just compensating for incorrect assumptions made during development. The worse case is trying to deal with the case of being a little too prepared for a feature.
A case where this happened to hit home for me recently, was whilst I was working on some features for the 2.0 release of Eventbook.
The biggest feature I’ve been working on is the ability to cache a user’s events as they’re retrieved from Facebook. This was a feature I had planned to put into 2.0 for some time, having decided that learning Core Data on top of the rest of the UIKit basics for my 1.0 was probably a bit too much.
That sounds simple enough, right? However, I made one mistake. Knowing that I had planned to do this, I had done some investigative work into ensuring I was able to track when the last request to Facebook was, in order to determine when the next fetch request should be performed.
You should be able to see where this is heading. With the current cache time check, when a user upgrades to 2.0, Eventbook will perform the check as normal, but with the cache database empty, there won’t be any events to register.
Of course… solving that raises a number of questions. If I were to ignore anything, it would look poorly upon the application, as it would result in a false display.
An easier solution might be to replicate the functionality using a different value. The upside is that it will result in the correct experience for the user, and it is likely the easiest fix to implement. The downside is that I now need to handle tidying up the original value. This is likely a single call to NSUserDefault’s removeObjectForKey: method.
The third option (which is probably the cleanest), also requires the most stuffing about.
In this case, I’d put out a 1.1 release, the goal of which is to disable the code which sets the time. In addition, I’d also flush any current value from the user default’s object, which would then set the ground for 2.0 to be able to use it properly, without requiring additional sanity checks or clean-up code.
But, if I were to consider going down that route? I’d need to go through the list of tasks, and consider at least one feature to add into it so there would be something new. The major downside of that, is simply that it diverts time away from the 2.0 release.
I’m tempted at this stage to see about a simpler feature (just a single one), and see if I can add it to the 1.0 release (in addition to adding the revised application icon) to make a 1.1 release.