Realigning the Azimuth

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.

Whilst I’ve been waiting for Eventbook to go through the motions of review, I’ve been doing a bit of planning and prepatory work on the next iPhone application I want to work on.

Sounds simple right? Sit down and start prototyping your user-interface (with the aid of something like this to speed the process up), whilst you think about the basic user interactions to make your application as slick as possible.

But then… you’re ready to start coding, and before you can create a new Project, there’s one small matter to solve… the matter of the name.

Why so much importance on a name at the start of a project?

For me it comes down to seeing something more interesting than SomeApplication when you run your application, inside your IDE, and even as the name of your source control repository. The latter of course, becomes even more important if you plan to release your application as Open Source, as changing the name later will then impact anyone else working on your application (and forcing developers to checkout your project again is not a good thing).

Sounds simple right? One name, then you can create a project, it’s repository and start banging away on the keyboard.

Except, it’s not so simple. You get a few ideas, fire off a quick web search, and then you realise your fancy name is not so fancy now. Then you repeat it again, and again, until you think you’ve found something which fits.

Even if you don’t use it as your application’s final name, at least it’s something more interesting than a generic SomeApplication.

I’ve at least found one myself that I can use for now… even if I need to return to the drawing board in a few weeks time…