我认同这篇文章里的不少观点，像是”聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。“很多时候看你活做得好不好不是看你花了多少时间Coding，或是Code有多少行。要做到Clean Code或Beautiful Code里提到的那种程度必须编码前的思考和规划。
不过对于文章里很多观点我个人觉得都有值得推敲的地方。首先我感觉作者对Agile有些误解。下面把我的观点一一道来。
软件开发真是这样的吗？难道不需要花时间去思考吗？
Agile里定义的开发应该不止是Coding吧？研究，计划，设计都是开发活动。用Agile不是说把所有开发活动都变为Coding了。
TDD、快速原型和迭代可能会对软件和团队产生负面影响。一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。。。TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。
同理，如果你把研究计划设计定义都算为Agile里的开发，这个论点的依据就不成立了。此外还有一个我觉得普遍的观点就是传统开发由于计划周全，所以后期出现的意外质量问题少。其实很多问题早期设想根本不可能看到，只有实际deploy后才会发现。而如果从0到开始部署周期太长的话问题会出现的很晚，解决起来更痛苦。
重构是恶梦，重构应该越少越好。
我个人反而喜欢重构。比如以前写了10个method现在重新设计为3个，或者基本没什么变化但是变量，缩进设计和method安排使得代码可读性更高了，其实都是增加了价值。我觉得代码就要经常重构，大的或者小的。这样才能改进产品和个人能力。当然一般的老板意识不到重构也是做产品。本人是Clean Code和Beatiful Code这两本书的忠实执行者。
所以可能对重构的抵触也是和Agile不兼容的原因之一？但是很多传统的开发方式不是避免了重构，而是把重构的成本变的很高所以公司会选择能拖则拖，最后technical debt越滚越大。
我现在在做的项目，花了几乎4个月的时间来做设计，在这个过程中，我们反复思考、讨论和权衡若干种实现方法，并尽可能地穷举所有的场景和细节以及未来可能的变化（那怕是那些简单的模块），有个模块被重写了至少三次，每次都是写到一半就被推翻重写，我们整个团队不断地在和其它团队讨论，并在对系统不断地认识中对系统进行简化和优化，并力求达到完美。现在看来，没有贸然使用Scrum是明智的。
我们公司用的是scrum。在写新系统的时候，大部分任务都是investigate，或是benchmark不同的solution，或是按照想法做demo。可见我们花在计划上的时间也不少。所以这个和你用不用敏捷是无关的，而是思考和计划在公司里的位置。
最后声明一下，我对Agile的知识都是在公司里工作学来的，没怎么看过理论。而公司里用的是Scrum。我个人对开发方法没什么喜好，什么管用用什么。但是我们公司开发情况比2年前用Waterfall时好太多了。