{"id":929,"date":"2009-08-30T13:39:12","date_gmt":"2009-08-30T03:39:12","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=929"},"modified":"2009-08-30T13:39:12","modified_gmt":"2009-08-30T03:39:12","slug":"semi-aside-interesting-article-on-practical-heuristics","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/08\/30\/semi-aside-interesting-article-on-practical-heuristics\/","title":{"rendered":"(Semi) Aside \u2013 Interesting article on practical heuristics"},"content":{"rendered":"

Over at Daring Fireball<\/a>, there’s a link at the moment to Wil Shipley’s article on implementing heuristics<\/a> within various applications he works on (Mac OS X), particularly focusing in this article on the human factors of heuristics.<\/p>\n

As a programmer and an author, I find the article interesting, because the lessons don’t just apply to the software Wil directly works on. Indeed, they don’t just apply to programming at all. Here’s an example – when I was writing my book<\/a>, I was constantly<\/em> wanting to come up with a method to reverse the core components. That is, the book title is “Enterprise Systems Backup and Recovery: A Corporate Insurance Policy”, but when you think about it, the more important<\/em> activity, the activity that people will (or should) think of first, is recovery<\/em>. That is, from a logical perspective, it would have been more appropriate to layout the book so that all the recovery concepts were covered first, being more important, before the backup concepts.<\/p>\n

From a “what the average reader will expect” perspective though, that doesn’t make sense, due to the chicken-and-egg nature of backup and recovery \u2013 you can’t recover without a backup, so you still need to introduce backup before recovery, even though backup is just the means towards the end.<\/p>\n

Similarly, programming I find is frequently a battle between:<\/p>\n