软件公司热衷于雇佣喜欢挑战技术难题的人。表面上看这种做法没什么问题，不幸的是，这会导致公司处于一种情形，你让他们开发一款产品，他们开发的产品更多的是来满足他们对各种技术挑战的好奇心，而不是用来解决客户的问题。

　　自从看了在Quora上一个关于在Google工作和在Facebook工作有什么不同的问题的回答后，我就一直把这个事情记在心里。在其中，David Braginsky写道：

文化：

Google像个研究院。人们喜欢挑战难题，把问题解决。事情总是做的很完美，程序编的很坚固，每个系统从始至终量身定做。每种设计都有无数的专家，通过反复的研究审查确立。

Facebook更像一群未毕业的大学生。有些事情需要去完成，于是有人来解决。大多数时间他们并不去参考关于这个问题的各种文献，也不去像专家咨询如何才是“正确的”做这个事情的方法，他们只是坐下来，写着自己的代码，让要做的东西可用。有些时候他们做的方式显得很幼稚，很多时候存在bug,做成的产品不能用。当这种情况发生时，他们就去修复问题，把其中的瓶颈部分换成可伸缩性的组件，（大多数情况下）就这样一件事情、下一个事情的做下去。

Google崇尚技术价值。事情被提出来做通常是因为有技术上的难度和能给人深刻的印象。很多的项目都是由工程师做决策。

Facebook崇尚产品和用户体验，设计师在开发中具有更大的影响力。Zuck会花费大量的时间注视产品原型，他对网站的外观和给人的感受有更深入的关切。

　　Google因为成功的开发出了很多其他公司投入了大量的博士、计算机科学家都不能很好解决的软件产品，给上千万人留下来深刻的影响，受到了人们的赞誉。他们的产品并没有按照上百人研究出的报告里推荐的那样。我们很容易从它最近一些产品，例如Google Wave里，看到他们追求功能复杂的痕迹。

　　如果你回头再去读读Google Wave 发布声明，你会有趣的发现他们热心于把各种不相干的功能组合到一起，喜欢把各种各样的技术挑战全囊括进来作为目标

• “Google Wave不仅仅适合即时通讯，同样适合那些持久性的内容——它可以用来进行协调创造和交流”
• “它是一个HTML5应用，基于Google Web Toolkit，它包含了一个富文本编辑器和其他类似桌面拖拽用法的功能”
• “Google Wave 协议规定了底层的存储格式和Wave共享的方法，它还包含一个‘即时’的并行控制模式，能够使你的编辑的动作即时的反映给其他用户或其他服务”
• “这种协议专为开放联盟而设计，任何人的Wave服务都可以和其他人的进行交互，包括Google Wave服务”
• “Google Wave也可以被当作一个平台，它有丰富的开放API，允许开发者们在他们的服务里嵌入wave”

　　这种产品声明读起来更像技术展示，而不是向人们宣告一个能帮助进行交流通信，合作，使他们的生活更方便的新产品。这是个极好的例子，一群聪明的人花了大量的时间解决复杂的问题但最终因为得不到用户的反馈和支持而宣布终止开发。这是因为他们把大量的时间花在了技术挑战上，而不是用在确保他们正在开发的是正确的产品。

　　所有的这些关于Wave的内部讨论想起来很有趣，像他们把时间花在实现”字符输入动作即使反映“功能时竟没有人会起来提醒他们，在宣布Wave将会成为Email的替代品时，这种功能对于这个产品有任何的意义吗？我经常写email，用邮件发表一些评论，当我想把我的思想展示给广大的读者时，我编辑它，修改它，然后发送它。但我想没人会像把这种创造过程也向人公布，没人希望这种软件功能。

　　XML又是一个例子

　　有些人可能会记得有一阵子我在微软的XML研发中心的首页上写博客 。那些天里我大量的时间使用XML<->对象转换不匹配这个词来描述当时主要的Web service协议(例如SOAP)所使用的主要类型系统上有很多的概念不能和传统的面向对象的编程语言（C#，Java等）很好匹配的事实。这是由于XML已经发展成为冲突的根源。有人把它当作的基本的文档格式，例如 DocBook 和 XHTML。

　　有人把它视为一些用于交互式远程过程调用技术使用的二进制协议的替代品，例如CORBA 和 Java RMI。W3C组织把一群聪明的人召集到一个房子里，希望他们创造出一种具有混合类型的系统来同时解决双方复杂的需求。这次行动的成果就是XML Schema，它成为了SOAP、WSDL和WS-*族系技术的类型系统。这也就是说，如果一个人只想找一个简单的方式来定义如何序列化C#对象，使之能被一个Java方法调用，那么他最终将使用的这种类型描述系统是一种同时也能描述这篇博客所使用的HTML的数据结构规则的类型系统。

　　像Sun微系统公司，Oracle，微软，IBM和BEA等公司投入数千人数年时间在这些协议上开发各种工具来驾驭这种基本的技术。当然，除了这套协议之外，每个人都有自己的方式去解决XML<->对象无法匹配所导致的交互性问题。最终有些用户开始爆出一些恐怖的使用这些协议实现交互的内幕，例如Nelson Minar的ETech 2005 Talk –在Google开发一个新的Web Service，并且，围绕着提倡使用 Representational State Transfer (REST)来开发Web service 的运动自然而然诞生。一前一后的变化使开发人员们明白，如果你的问题是要传送编程语言对象，那么一种专门为这种事情而设计的数据格式将会是一种更好的选择。今天，你已经很难再看到广泛的不使用Javascript Object Notation (JSON)、而使用SOAP的Web Service部署了。

　　这两个故事的寓意都是要告诉我们，很多时候我们很容易迷失在追逐解决复杂技术挑战的诱惑之中，因为我们强迫自己接受一种看起来是更有意义的设计路线，从而导致软件复杂化，却忽略了我们的软件是要解决用户问题的。避免让自己处于这样的境地，你应该评估一下如果改变你最初的设计会不会使的问题简化下来，你应该尽量的花时间解决用户的实际问题，取悦用户。应该有更多的人扪心自问，我们真的需要使用一个相同的类型系统和数据格式来同时处理商业文档和序列化编程语言对象吗？

　　【英文出处】：

　　Lessons from Google Wave and REST vs. SOAP: Fighting Complexity of our own Choosing