I write here in bursts. It confounds me as to what marks the beginning and end of those spikes. I have a few hunches:
- ambitions grow larger than my free time: it’s easier to hit publish on a self-contained thought than a connected series or magnum-opus essay
- intervention of life: work, vacation, various chores adults are expected to perform
- self-distraction: acting as a novelty junky rather than pushing one thing through to completion
- tweeting less: putting little thoughts into tweets means I’m driven to put slighly-not-little thoughts into blog posts
- reading less: reading interesting things drives me to (attempt to) write interesting things
- skipping record: I worry I’ve already had this thought and published it somewhere
Also sometimes I’m not quite sure how to end a thought like this and I wonder if I should worry about that and then I decide to let it slide.
When it comes to caching and primary storage of an application’s data, developers are faced with a plethora of shiny tools. It’s easy to get caught up in how novel these tools are and get over enthusiastic about adopting them; I certainly have in the past! Sadly, this route often leads to pain. Databases, like programming languages, are best chosen carefully, rationally, and somewhat conservatively.
The thought process you want to go through is a lot like what former Gowalla colleague Brad Fults did at his new gig with OtherInbox. He needed to come up with a new way for them to store a mapping of emails. He didn’t jump on the database of the day, the system with the niftiest features, the one with the greatest scalability, or the one that would look best on his resume. Instead, he proceeded as follows:
- Describe the problem domain and narrow it down to two specific, actionable challenges
- Elaborate on the existing solution and its shortcomings
- Identify the possible databases to use and summarize their advantages and shortcomings
- Describe the new system and how it solves the specific challenges
Of course, what Brad wrote is post-hoc. He most likely did the first two steps in a matter of hours, took some days to evaluate each possible solution, decided which path to take, and then hacked out the system he later wrote about.
But more importantly, he cheated aggressively. He didn’t choose one database, he chose two! He identified a key unique attribute to his problem; he only needed a subset of his data to be relatively fresh. This gave him the luxury of choosing a cheaper, easier data store for the complete dataset.
In short: solve your problem, not the problem that fits the database, and cheat aggressively when you can.