我觉得决策没有绝对的正确或错误，所有决策本质上都是权衡利弊，所以要两面思考。现今多数应用或网页上都只有“喜欢”的按钮，而没有“讨厌”，有时候这缺少的一面会变得非常讨厌，比如听歌，有些你真心不喜欢的歌你跳过了一遍又一遍，系统还是自动推荐给你，这用户体验就太糟糕了。为什么不能有个“我很烦这首歌”的按钮呢？其实没有就没有吧，“跳过”这种行为本来也是一种数据，靠谱的数据分析狮应该能嗅到它的价值，可惜好像这个数据并没有被虾米使用，让老夫不厌其烦地跳过《没那么简单》。
举几个码农例子。比如有人抱怨说knitr毁了他的文件，我当然可以提供一个选项，在写输出文件的时候提醒用户要不要覆盖已有文件，可这样做会让绝大多数用户觉得烦，我编译个文档，你为毛老是问我问题。我的导师Heike大人有时候就嘲笑Windows下一些对话框，总是问你，是否确定？是！真的吗？对！确定一定以及肯定？滚！若不问，就可能出现帖子里失误覆盖文件的问题。是去烦多数用户，还是让极少数人粗心犯错付出沉重代价？我选后者。
又比如早些时候jsonlite的作者总是打着“严谨”的口号，RJSONIO以不严谨著称，有些特殊的情况下，你压根儿无法预测R对象转成JSON对象会变成什么（比如只有1行1列的矩阵）。然而严谨带来了一个巨大的不便，比如长度为1的R对象到底转成JSON数组还是标量？他选择数组。在实际应用中，其实标量更常见一些，但作者原来只提供了标量的标记方式，是一个unbox()函数，而在RJSONIO包中提供了一个相反方向的标记方式，I()函数，告诉转换函数这个对象应该被视为长度为1的数组。于是在这个帖子中，我给出了两种方式的对比。如果只有作者原来提供的unbox()方式，代码会变得臃肿丑陋，尽管RJSONIO各种不靠谱，但这个I()标记还是很方便的。要打倒一个旧软件，不意味着它的一切都是糟糕的，自以为严谨了，其实也可能会带来不便。正反两面都需要想想。
这么一想，统计里面风险函数是拿损失函数求期望，如果不两面或多面思考，实际上也就是只考虑了损失函数的一种取值，决策者对风险值并没有整体把握。