The (Library) Upgrade Dilemma
The idea of staying up to date with your platform is one which seems to gather its controvery for so many reasons.
It sounds reasonable – lock your application against stable versions of your platform & support libraries to ensure nothing breaks over time. Whilst it’s perfectly valid to support this during production, I’m not sure it’s a good idea when you’re in the middle of doing maintenence work on a project.
I’m not saying that you should rush a deployment just because the foobar library went up from 1.0.1 to 1.0.2. Certainly not – that’s a dangerous situation. But if you’re in the middle of working on a release which is going to include some new functionality, I think it’s another story.
I’ve actually ran into the consequences of not doing this myself rather recently. With Eventbook, I’d not bothered to upgrade the version of the Facebook Connect library until rather recently. Part of this was due to the difficulty in determining when an upgrade was out, simply due to how releases were managed (a binary zip file sitting on one of their servers).
I also (foolishly) didn’t bother grabbing it when it was released, as simply it was a case of if-it’s-no-broke-then-don’t-fix-it. In fact, that’s a fairly conservative idea to follow with, but it’s reasonably easy to track source changes and rollback in required.
But I learned my lesson. As I was going through the notions for preparing for release, I discovered that I needed to upgrade the library in order to fix one big bug with user accounts having very high UIDs. Oops.
I’ve also seen that static behaviour in larger projects – projects which had a significantly extended genesis. They’d grab the current versions of their libraries as they were required, and kept them frozen as long as possible.
I personally don’t believe it’s the best option anymore. In some areas (particularly in my experience with doing Ruby on Rails development), keeping to a particular version too long has the potential to leave you trailing in the dust, due to the rapid progression of Rails as a platform.
Unlike other forms of engineering (if we are to get all serious for a moment), software development is significantly more fluid. A good software developer will always have a good Version Control tool by their side. A good platform will include ways to manage library dependencies (which does frustrate me doing iPhone development). Both of those are powerful tools to ensure that you can upgrade and rollback if things don’t quite work properly.
But most importantly: This isn’t an absolute. It’s just my opinion based on my recent experiences. In fact, if you need a significant amount of code auditing – it’s probably not that wise to rapidly upgrade unless necessary. But it’s always discretionary, and you need to weigh it up on your own projects.
Announcing Eventbook!
After a fortnight in the black box of review, I’d like to announce that my first self-published application, Eventbook has gone live on the iTunes App Store.
I won’t go into the details again (as you can always check the Eventbook site for the specifics), but for a project which came together in about a month, I’m really proud to see it available for download.
It feels weird that after developing software for so long (in a serious sense – a good 6 years since I finished my CS degree), that I’ve finally pushed a project out the door.
My time at various employers has been doing maintenance on existing applications, working on projects that never got released for various political reasons, and other cases like that.
Having decided to leave corporate employment some time ago (for a lot of personal reasons), the fact that I’ve been able to accomplish this is quite a big thing for me.
I plan to go into a bit of behind the scenes stuff on the design (not necessarily code) behind Eventbook now it’s out, over the next few weeks, as a form of a retrospective for myself.