I’m pretty good at time estimation for programming tasks that I understand. But (like everyone else) I get killed by the parts that I never even thought would be an issue.
I thought I’d just be pulling a few fields out of my Apple iPhoto SQLite database — pretty easy stuff…
To work with a third-party Obj-C library, I needed to upgrade my dev machine to Lion and XCode 4.1. OK, fine. I was probably going to upgrade anyway eventually. 10 GB of downloads later, I’m pointlessly trying to think of efficient ways to do queries across two SQLite databases without holding both of them open for long periods of time (why did Apple put the face data in a separate database instead of just in a different table?). Oh, and my forked copy of the fmdb SQLite helper database conflicts with the same library bundled with another third-party library. Why doesn’t Apple have a middle-level API that’s simpler than CoreData but not just raw sqlite C calls?
Then I scratched my head for a while trying to understand why my photos came out saying they were all taken in the 70s… An hour of trial-and-error and some lucky web searches, I found my answer. iPhoto records timestamps as seconds since Jan 1, /2001/ instead of Jan 1, /1970/ like everyone else. Why, why, why?
The problem with shaving yaks is that there are so many of them that by the time you think you’re done, the first ones have grown all their hair back again…
Shaving yaks. Choice!
Chris, thanks for reminding me of the bizzarro stuff you’ve got to deal with to get simple things done in coding.
Stephen Scaffidi Amen! I just recalled that this iPhoto project of mine was also the reason I upgraded from XCode 3 to 4, which necessitated an upgraded from Leopard to Snow Leopard… And it all started because iPhoto doesn’t let you unreject a face match (http://use.perl.org/~ChrisDolan/journal/39457). So, yes, this yak has been shaved multiple times!