聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的 bug… 所以， 越差的团队一般会越忙，而且还忙不完。
在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就像流口水那样兴奋。他们使用 TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。
软件开发真是这样的吗？难道不需要花时间去思考吗？对此，有些观点在 Todd 的《“品质在于构建过程”吗？》以及《Bob 大叔和 Jim Coplien 对 TDD 的论战》中谈到过了。我只想想表达下面的观点：
软件的精髓在于设计，设计是一件很费大脑的事件。对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时间换空间，空间换时间，TCP 或 UDP，同步还是异步，数据冗余还不冗余等等。那怕是一个小小的 observers 模式是 pull 方式还是 push 方式都需要仔细讨论。这些的东西需要时间和做前期尝试。
TDD、快速原型和迭代可能会对软件和团队产生负面影响。在一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。当然，那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你，这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。
重构是恶梦，重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情。如果一开始没有想好，你要面临的不单单是 re-design, re-architect，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的 rework 而逐渐低落并产生厌倦和懈怠情绪。
所以，如果你能有多一些时间去和客户讨论一下需求和未来可能的变化，去调查一下实现的技术难点和细节，去和其他有经验的人讨论并推敲一下架构和设计，去思考设计上的缺陷，那么，你的 coding 会变得非常地直，直到你一眼就看到尽头，你的测试案例也会写得非常地好，你会几乎不需要重构，于是，你会在未来少写很多代码，从而你的软件开发会越来越轻松，直到技术开始换代。
我现在在做的项目，花了几乎4个月的时间来做设计，在这个过程中，我们反复思考、讨论和权衡若干种实现方法，并尽可能地穷举所有的场景和细节以及未来可能的变化（那怕是那些简单的模块），有个模块被重写了至少三次，每次都是写到一半就被推翻重写，我们整个团队不断地在和其它团队讨论，并在对系统不断地认识中对系统进行简化和优化，并力求达到完美。现在看来，没有贸然使用 Scrum 是明智的。
这就好像我们修路造桥一样，我们需要花大量的时间勘测地形地质，分析数据，思考可能出现的各种问题（各种自然灾害），评估不同的设计方案，而不是先尽快建好再说。所以，多一些时间，不是让你多做几次迭代，多完成几个模块，而是可以让你少写一些代码，更快的交付一个更好的产品。
我相信你会有很多疑问，下面是我觉得你可能会有下面的一些观点，让我一条一条来回复：
首当其冲的一定会是项目的 deadline，或是那种你没有活语权的项目。比如做那种“甲乙方合同式的项目”，我把这种项目统一认为是“外包项目”，在这种项目性质下，你很难有话语权。对此，我觉得，1）作为乙方的你还是应该和甲方在项目计划上争取一下，晓之以情，动之以理。2）如果不行，只能在时间、需求范围和质量上做一个权衡。另外，在这种情况下你要找一个方法，把你的压力和痛苦分担给用户和领导。（找到这个方法的前提需要你找到用户和领导他们害怕什么，嘿嘿）
过度设计和纸上谈兵。有人说会不会设计太多，造成过度设计，或是在设计上花太多的时间。这有可能。我上一家公司的一个项目团队就花了1年多的时间来不停不停的开会和做设计，结果 release 的时候还有1000多个 bug。这个问题的原因是，这个团队的设计是在纸上谈兵，开会是开神仙会，讨论的设计都是浮云。所以，设计并不是讨论和思考，还需要去尝试，我认为当你的设计完成的时候，你的骨干核心代码都基本完成了。
我的团队成员水平太差，不会思考。首先，先恭喜你找到一堆码农，当然，这不怪你，这是中国教育和大环境的问题，让人不会思考。对于这样的情况，我有两个建议，1）量力而行，使多大的碗就吃多少饭。2）鼓励思考，那怕那些想法很不靠谱，因为如果不开始，那么将永远不会思考。
必需使用快速迭代。很多公司都在强行上敏捷，他们希望产品越快 release 越好，而没有充分的时间思考和讨论。对于这种项目，我的建议是，1）找有丰富经验的人来做。2）迭代过程中力求架构和程序逻辑的简单，简单，再简单，力求代码间的高内聚，低耦合。不然，重构的时候你就好玩了。
创业团队必需要快。做得快就是做得好吗？很多时候，不是谁快谁就能笑到最后的。这样的例子太多了。第一个做出来的人并不一定就会占领市场，其很有可能会成为先驱。
有钱的公司才会让团队用更多的时间去思考。错了，你们没有见过有钱的公司，有钱的公司可以招一堆干不成活的人，可以把事搞乱了重新来过，甚至可以把做失败的项目换个名字再重新立项。这些真正的有钱的公司只求快，只求人多，不怕做错决定。像我们这些没钱的人，干什么事都是小心翼翼地，生怕做错决定。
所以，构建一个优秀的系统，我觉得需要以下几点：
构建一个好系统的愿景。如果相关人员（经理，小组负责人，程序员）只是想混饭吃，就注定无法构建优秀的系统。
理解业务需求。虽然不可能像业务人员一样熟悉所有细节，但整体上应该超过业务人员。如果可能，要让所有程序员都真正地理解业务。正如乔布斯，他基本上不会去询问客户的需求，因为他对“需求”的理解远远超过了普通大众。唯有如此，才能建造出杰出的系统。只有真正理解了需求以后，才能在系统设计中加入未来可能需要的接口和模块（而不是过度设计），才能在开发过程中“抵制”客户的不合理需求改动要求，才能避免种种业务陷阱，开发出客户喜爱的功能。
尽量利用已有的主流软件平台，减少开发。在软件开发过程中没有“银弹”。即使对优秀的程序员来说，要减少BUG，也必须做大量的测试和BUG修订。这意味着惊人的时间和成本。成熟的商业软件系统虽然价格高昂，但其质量也远远高于一般公司里IT部门开发出来的东西。自己开发的系统，复杂性一旦到达某个级别，往往会事实上不可维护。这不仅仅意味着直接的维护成本，更会对公司的业务造成严重破坏和阻碍。应该在成熟的系统里，通过少量二次开发来实现需要的功能。
分阶段实施。不要试图实现所有的功能，不要试图构造完美系统。业务需求中，总有一部分至关重要。实现了这一部分，就能为业务人员节省超过80%的时间。一般都应该迅速构造这样一个1.0版本，并让业务人员尽早在上面工作。等系统稳定以后，再去构造2.0版本。在系统的构造过程中出现的绝大部分新需求或者需求改动，都应该放入下一个版本。
代码: "轻耦合", "模块化", "易读"。代码模块相互要独立，每个模块功能必须单一，而且同样的功能不应该在不同的模块中重复实现。除了上面列出的这几条，易读性就是最重要的。在99%的场合下，性能一类的要素都不需要考虑。合理的系统架构本身就已经解决了性能问题。合理的程序代码（包括SQL语句）都足够快。代码中嵌入的注释应该很少----优秀的代码本身就能解释逻辑。注释一般应该集中在模块的开头部分，阐述业务逻辑，帮助程序员理解业务需求。在一个应用系统中，为了把局部性能提高10000倍而牺牲代码可读性，一般是不可接受的。（除了一些极其罕见的特例）
代码: 垃圾进，垃圾出。一般来说，对任何一个模块，都不应该去检测传入参数是否合法，更不应该试图去处理非法数据。唯一需要保证的是，合法的传入数据将产生合法的传出数据。这也是为了防止"过度设计"，为了避免垃圾数据，必须在源头上卡住。避免垃圾数据进入系统。
代码: 只有异常，才抛出异常。可以预见的错误，都不应该导致异常（exception）