Damn You, WHICH Auto-Correct?

If you've had a smartphone for any length of time, you're no doubt intimately familiar with the concept behind the site Damn You, Auto Correct! even if you've not yet visited it. (But you should.) :-)

Perhaps more subtle than the humorous mismatches between intent and attempted repair is the philosophy behind various implementations of auto-correct. I've recently been using a Samsung Galaxy Note exclusively after having had various iPhones for several years, and for all the similarities between the two, one thing is glaringly different: the way auto-correct works.

At first I was just drying out from the familiarity Flavr-Aid, thinking that the iOS spell-checker was simply better. And then I started to notice that the Android spell-checker followed a predictable pattern. The iOS spell-checker, as on iPhones and my current iPad 2, follows another. If you aren't aware of that, you'll be very frustrated when moving from one to another.

The iOS spell-checker, when it can't match your registered key-taps to a complete word in its dictionary, assumes that you've fat-fingered a misspelling, and so the (one and only by default) suggestion it offers is based on that assumption. There are linguistic principles that determine how it makes that decision. While those have been understood for some time, it's been only relatively recently that a real-time-capable implementation has been both (relatively) affordable and easily portable. Auto-correct on the iPhone has been steadily improving, likely due both to improved algorithms and more powerful processing capabilities. OK, fine; that's what people who've only used iOS lately expect; it works reasonably well as expected, what could possibly be different?

Android hasn't always had the top-tier processing capability or memory of an iPhone 4 or 5 to throw at anything, let alone spell-checking. (Recent high-end phones are extremely competitive, but that's a whole other post.) If they can't or shouldn't throw enough resources at spell-check to actually correct in real time, then what can be done?

Take the other fork in the road, of course. Don't assume auto-correct to be spell-checking; instead, use it to reduce the number of key-taps needed to type longer words, à la TextExpander. Of necessity, this will involve a fair amount of "real" spell-checking. Android's spell-checker seems to assume that any typos are typos in the first few letters of a longer word. Further, it seems to assume that the first letter typed in a new word is always correct, and rarely if ever shows alternate words with a different first letter. (Android, unlike iOS, shows a list of candidate words, allowing the user to select among them with a single tap — further speeding rapid [if initially correct] typing.)

Which is "better" depends on your preferences and the accuracy of your typing on the device you are using. With my Lincoln Log-like fingers, I could maintain an effective 2-3 wpm rate on an iPhone 4; nearly double that on an iPad. After my iPhone 4 was stolen (apparently for parts as it was never again turned on), I bought the cheapest 3G hotspot-capable phone I could find at Lucky Plaza, which turned out to be a grey-market HTC Explorer. That was easily one of the two most painful experiences I have ever had in over 15 years of using mobile phones. A very, very kind and loving soul loaned me a Samsung Galaxy Note running Android 4.0 ("Ice Cream Sandwich"). Comparing the Explorer to the Note was slightly more comical (and less fair) than putting a 1976 Chevy Chevette onto a track next to a Bugatti Veyron and seeing who can finish 20 laps before the other. (If the Bugatti gives the Chevette a 15-lap head start, my money's still on the Bugatti. I've owned a Chevette.)

I now find that I type comparably fast on the (~5.3-inch) Galaxy Note as on the 10-inch iPad. I'll be returning the borrowed Note soon (geologically speaking, at least); I'm just waiting to be able to have a good demo of an iPhone 5 to compare, and see which I really prefer. The new iPhone is going to have to be at least as good as the fans and reviews say it is; this Galaxy Note is sweet…

Stubs Aren't Mocks; BDD Isn't TDD; Which Side(s) Are You On?

I just finished re-reading Martin Fowler's Mocks Aren't Stubs from 2007. I wasn't as experienced then in the various forms of agile development as I am now, so couldn't quite appreciate his perspective until somebody (and I'm sorry I can't find whom) brought up the paper again in a tweet a month or two ago. (Yes, that's how far behind I am; how do you do when you're working 15- to 18-hour days, 6 or 7 days a week for 6 months?)

In particular, the distinctions he draws between "classical" and "mockist" test-driven development (TDD), and then between mockist TDD and behaviour-driven development (BDD) are particularly useful given the successes and challenges of the last dozen or so projects I've been involved with. I wouldn't quite say that many teams are doing it wrong. They/we have been, however, operating on intuition, local folklore and nebulously-understood principles gained through trial-and-error experience. Having a systematic, non-evangelistic, nuts-and-bolts differentiation and exploration of various techniques and processes is (and should be) a basic building block in any practitioner's understanding of his craft.

Put (perhaps too simply), the major distinction between classic and mockist TDD is that one focuses on state while the other focuses on specific, per-entity function; projects that mix the two too freely often come to grief. I believe that projects, especially midsize, greenfield development projects by small or inexperienced teams should pick one approach (classic or mockist TDD, or BDD) and stick with it throughout a single major-release cycle. You may credibly say "we made the wrong choice for this product" after getting an initial, complete version out the door, and you should be able to switch the next full release cycle to a different approach. But if you don't know why you're doing what you're doing, and what the coarse- and fine-grained alternatives are to your current approach, you can't benefit from having made a conscious, rational decision and your project thus can't benefit from that choice.

Anything that gives your team better understanding of what you're doing, why and how will enhance the likelihood of successfully delivering your project and delighting, or at least satisfying, your customers. Even on a hobby project where your customer is…you yourself. Because, after all, your time is worth something to you, isn't it?