Good article. I disagree with making "Corner case identification" a major element of your sample coding session. While its great for developers to consider "what happens when X goes wrong", I've definitely spent time with programmers who spend more time thinking and writing about the 'what ifs' instead of writing useful code.

Overly defensive programming leads to code that is _never_ executed. That is wasted code, time and money.

So, in his example, considering that the twitter api may go down and how to handle that is probably a good thing. Trying to self-heal if Twitter suddenly changes their API is probably a waste of time.