首先抱歉，题目可能很难懂。不过不要担心，内容会比较轻松。既然大家都喜欢讲故事，听故事，那我也来编一个故事来开始吧。
说是在很久很久以前，数学还没有被发明的时候，神把发明数学的难题交给了一对兄弟。兄弟二人齐心协力终于发明了0，1到9的数字，却为谁比谁大而争了起来。弟弟坚持认为2比1大，哥哥坚持认为1比2大。二人争执不休，最后到神那里去，要神给吓定论。
神想了想说：嗯，1可以比2大。哥哥听了很高兴；可是神又说：不过，2也可以比1大。
两个人都很不高兴，说，你是神，你怎么还没有主见呢？我们两个人的观点是完全对立的，如果我的观点对了，他的观点正好相反，当然就是错，怎么可能既这样，又那样呢！
神笑了笑说，其实你们的观点是可以共存的啊！当1和2被当作基数的角度来看，2就比1大，当1和2被当作序数的角度看，1就比2大啊。
这个故事说明一个问题：很多看起来完全对立的问题，实际上可能是各种看法都是正确的。
回到正题，这几天园子里的高手们讨论起技术是否重要的问题，捎带着牵连上了创业团队里什么重要、用户需求是否重要、等等很多问题。如果要我来回答，我会大声说：
技术非常重要！
用户需求非常重要！
创业团队里技术以外的东西非常重要！
似乎什么都很重要，没重没轻了是不是？
那换一个思维，如果我现在告诉你我的身高是1米80，请你告诉我，我高不高？
没错，我比1米75的高，比1米85的矮。高矮胖瘦，重要与否都是和其他参照物比较的结论。所以我们无法单纯地说，技术重要，技术不重要。
就拿一个创业团队来说吧，如果这个团队不大重视技术，技术方面瘸腿，那么在开拓市场开拓业务思考盈利模式的时候恐怕就是纸上谈兵，那么对于这样的一个团队来说，技术就很重要，不能因为技术带来木桶短板效应。
但是反过来，如果这个团队本身就是一群技术精英组建的，他们创建的初衷可能是看到了一种未来很好，“看上去很美”的技术前景，而相反没怎么考虑过这项技术的市场适应性、人们的接受能力、以及能否盈利以保证企业运作的方面，那对于他们来说先把技术放一放，好好考虑一下现实也许更好。
OK，我们现在解决了“是否”这个问题；下一个问题就是，软件开发，到底该追求什么？
首先我们站在个人的角度，假设我们自己开发一个软件，而且假设我们不愁吃穿，不需要这个软件来赚钱，你只是凭兴趣来开发它——这样的话，你希望这个软件被开发成什么样呢？我想，大多数程序员可能会想，把这个程序开发得尽善尽美：功能强大完善；体系结构清晰明快；技术精巧细致；界面美观大方；……你注意到了，这里你没有考虑很多东西：成本，工期，客户要求。
因为你是一个人，你在做自由开发；但是，假如你是一个企业呢？
你必须考虑到成本——在当前这个信息社会，一个软件没有做好而亏损几千万的例子并不少见。其次，你要考虑到工期和产品质量的平衡——我们理解你把这个软件做好的心情，但是在客户要求的短短2个月内，你能把客户所需要的功能做好就已经很不错了，哪里还有时间给它增加一些诸如换肤，使用Windows主题之类的花哨功能？此外，很多时候，你可能和客户有不同的意见——你认为这里应该用一个RadioButton，客户却坚持要一个DropDownList——没错，你用你从穿开裆裤小屁孩的时候就开始拥有的计算机经验打赌，客户代表绝对是头不懂计算机的猪——可是，就算他真的是头猪，这个软件最终也不是你用，而是这头猪用，所以没办法，你必须满足一头猪的需要，因为你不满足他，他就会去找别的公司——这世界的竞争太激烈了，伙计。所以我坚信，能满足一头猪的需求的软件公司，才是一个真正能让客户满意的公司。
那么，是不是又出现矛盾了呢？程序开发企业是由程序员组成的，而企业和程序员的追求又不同——
没错，企业和员工的目标不尽相同，不仅是软件行业，所有行业都是这样。但是，我们何尝不去追求一种存异求同呢？举个例子来说，你正在思考你刚刚写的代码是不是可以换一种Pattern——比如，Visitor Pattern※参看下文讨论；因为这样似乎将来扩展起来比较容易。这时你的头可能会过来拍拍你的肩膀，Hi，Jerry，这一段代码已经很不错了！你赶快去把下一个模块写好吧！
这时你也许会抱怨——这一段代码只是刚刚能用而已！我还想继续整理它，让他结构更鲜明一些，将来无论是做二次开发还是插件，都会变得容易的！但是，你必须替你的Boss考虑——他的Boss可能刚刚对他说：嘿，Tom，下周五客户就要来验收了，你这个Team的进度却只有40%！
那我们该怎么做？我们不成沉浸在我们艺术家的思维里，我们必须意识到我们不是在玩，我们是在一家企业，做一项实际的工作；我们的确要把工作完成得更漂亮，但是是在有限的时间内！程序有Bug？不够完美？没错！世界上没有完美的东西，程序也是一样！缺一样功能的程序和断臂的维纳斯是一样的不朽之作！
如果你学会了这样想，你可以更进一步——不要等到你的Boss来拍你的肩膀时才意识到这一点，而是在项目的最开始，就能站到和一个项目经理相同的高度——甚至高于他的高度思考问题；在最初设计软件的体系时，就高度意识到工期，用户的环境、要求和条件等等；这样你会发现，你掌握的不仅仅是写程序。
注：由于各位争得面红耳赤，本文是专门博大家一笑的，纯属戏谑，若有不同意见请勿深究，请勿见怪:)
