实践状况-2010
更好的软件和敏捷西部是由软件质量工程协会（SQE.com）组织的会议，它们每年会同时举行。 这两个会议我们提供了机会，让我们可以探究和分享软件开发领域当前的最佳实践，并找到传统方法和敏捷方法之间的共通之处。 在敏捷会议中有CMM主题，而更好的软件会议中有极限编程（XP）的主题——这表明它们之间有很多共同点。 本年的会议是在拉斯维加斯的凯撒宫举办的，这是一个很好的机会，让你可以与领先的设计师、作者以及演讲人齐聚一堂，了解他们对2010年实践状况的看法。 InfoQ采访了以下各位（按字母顺序）：
* DevJam的David Hussman
* Atlantic Systems Guild的Tim Lister，他也是《Adrenaline Junkies and Template Zombies》、《Waltzing with Bears》和《Peopleware》的共同作者
* QSM Associates公司的Michael Mah，他也是位于Cutter Consortium的Benchmarking Practice的主管
* James Martin (Uncle Bob)，它是Object Mentor的创始人和总裁，并且编写了很多书籍，包括《Agile Software Development: Principles, Patterns, and Practices》
* Accelinnova 的Pollyanna Pixton，他也是《Stand Back and Deliver: Accelerating Business Agility》一书的共同作者。
* Rothman Consulting Group, Inc的Johanna Rothman，他也是《Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects》一书的作者
* Industrial Logic, Inc的高级教练Bill Wake，他也是《Refactoring in Ruby》一书的共同作者
* Wirfs-Brock Associates的Rebecca Wirfs-Brock，他也是面向对象设计方面的两本书籍的主要作者（《Designing Object-Oriented Software,》和《Object Design: Roles, Responsibilities, and Collaborations》）
我们向每个人都提出了相同的一系列问题，并将他们的回答整理总结如下。
可否请您指出当前的三种既“新”又“重要”的软件开发实践呢？ （新可能只是意味着对旧的实践进行了新的改进）
每个人都提到了测试驱动开发和自动化测试，Michael Mah指出，一个人只有明确了测试的重要性，才能够声称自己已经成为“软件工程师”了。 紧接下来的实践是重构，但是大多数被采访者都表示重构和重构浏览器提供了很大的潜力，但是他们担心团队不是总会给重构提供真正需要的、而且是必要的时间。 其他时间，按照被提到的次数列举如下： 持续集成（即便是针对瀑布式的项目），用户故事（作为工作单元和时间盒）和故事映射，多语言编程（很大程度上由Web开发所驱动），意图开发（programming by intent）、开放的环境，回顾（retrospectives），以及在任何类型的项目中适度地接受敏捷。
有几位被采访者提出，有种值得注意的新实践——业务分析和项目之间的分离，（在项目开始之前，将一组合理的用户故事/产品backlog放在一起），这可能是由不同团队完成的。
从总体上和行业范围内看，当今的软件开发与我们在二十世纪八十年代所做的调查中看到的相比，真的有什么不同吗？
这个问题得到了各种不同而有趣的回答，几乎所有人开始时都说没有改变。 正如Bob Martin所说：“区别仅限于形式上，实质上是相同的，我们还是在写IF、赋值和循环，耦合和内聚问题还是很重要，并且从中得到的教训在今天还是很重要。”
在做出最初的回答之后，他们几乎马上就会说“但是……”，然后会指出一些重要的不同之处。 例如：
* 当前的软件产业真的可以将已经下架的产品粘合起来，以生成自定义的和可用的软件。 这取决于两种完全不同类型的软件厂商，集成商（拥有大量集成解决方案的厂商）和一次性的生产商。
* 大多数人都认为，敏捷只是集合了诸多旧观点，但是使用了一种新方式来集成，以创造出一种崭新的哲学，来进行关于软件的思考，它强调创新、质量和提升对在“业务时间”中的业务需求所作出的响应。多位应答者都注意到一种重要的、态度上的转变： 开发者会掌握整个开发过程，并且对于工作越来越更负责任。 所有权会让他们更赞同“为生产创建原型”的想法，而这在八十年代被认为是不可能的。
* 每个人都提出了这样的问题，我们可能正在做同样的事情，但是遇到了更严重的问题，并且试图创建更加复杂的系统。 然而，有人指出这种复杂性上的改变以及我们发布它的速度已经导致了更大、并且可能会扩散的“一团团烂泥（Balls of Mud）”。 事实上我们拥有多种不同的平台，最重要的是网络、并行硬件以及云资源已经与二十世纪八十年代相比有了很大的改变。
* Michael Mah指出我们正在创建“令人惊奇的新产品，交互网络，分布式协作，社交网络，并且我们做的越来越快。” 不幸的是，与此同时缺陷也增加了75%，我们更快地创建了垃圾代码，并且累积了越来越多的技术债务，它们应该被尽早解决。
二十世纪八十年代是大型机的时代；而当今是云的时代。 二者之间有什么不同吗？
从架构上来说，云只是大型的集中式平台，它与大量智能终端相连接，因此可以认为也是大型机。 但是它与大型机也有一些重要的区别。 作为资源，云环境是高度可配置的，并且比试图使用“自己的”类似资源要便宜得多。 云也是无限可配置的、灵活的和可自定义的——旧的大型机不具备这些特点。
云架构有很大的安全隐患，因此你要仔细考虑是否要将最敏感的数据放在上面。 很少有人知道在云中会发生何种“灾难性的故障”，也没有人知道这样的问题会对公司、经济甚至是国家安全造成多大的影响。
云也正在改变信息关系——你不再能够使用这样的借口，“它在我家里的另一台计算机上。” 把这么多信息放在那里也会影响创造可能性的决定，甚至会影响新的协作和分布式决策领域的领导者。对于云来说，它有可能会加速当前的超级集成（hyper- integration）的趋势，还有非常实际的死锁的问题，以及“将你的灵魂出售给”拥有大量集成应用程序的厂商。
大多数围绕云的真正问题都不是技术上的——这并不是因为它是“天空中的大型机”——而是实际生活中的业务和社会，这并非是技术人员所能够解决的问题。
敏捷已经成为主流！ 这意味着它成功还是失败了？
既是成功，也是失败。 它几乎已经失败了，因为“每个人都在做，但每个人做的都不一样，没有人知道他们在做什么。” 它已经成功地为一些人和一些工资赚了很多钱，因为“那些疯狂的主意”当前被严肃地采用了，使人们知道真的有一种不同的软件开发方式。 敏捷还让我们能够试着应付不同的问题，因为敏捷让我们可以“寻找通向解决方案之路，而不是在开始之前就预先构想解决方案。”
敏捷的观点无法包含这样的事实，它已经被真的销售一空，也没有标准能够说明“这是敏捷或者这不是敏捷”，所以所有的一切都可能是敏捷。 Michael Mah提到了他们公司以及Cutter的数据，指出只有三分之一所谓的敏捷项目名副其实。更麻烦的是，其他三分之二所谓的敏捷项目比传统的项目拥有很高的缺陷率，很显然这没能达到敏捷的承诺。 Bob Maring指出“主流只意味着不具有新闻价值了”，尽管大多数敏捷实践仍然处于争论之中，“但已经有了组织并且落在了实际的项目中”。
还有一些更有趣的关于敏捷“迷失了方向”的评论，它关注的是这样的事实，太多的支持者没有意识到什么是真正重要的，而什么并不重要： “关于看板和Scrum的争论很不恰当，敏捷是一个概念，而不是特定的实践或者一组实践；”并且，“敏捷是关于学习的，而不是要牢记那些仪式和实践。”
几乎所有人都觉得将来敏捷会遭到强烈的反对。
软件开发具有专业性吗？ 并且，软件开发者是专家吗？
两个问题的答案都是：不！ 可能在初期有这样的职业，但现在已经不再有了。 当然，有一些开发者是不同的，他们是标准的例证，拥有真正专业的技巧，并赢得了大家的尊敬，我们一致认为他们是专家的典范，但不幸的是，大多数开发者都与他们不同。
很有趣的是，有人指出大多数针对“专业化”的观点都会伴随着关于管理是否具有专业性的争论（请参见最新的一期Harvard Business Review）。 正如David Hussman所指出的，“软件开发者没有什么专业性可言；”没有像医师的“不伤害”一样的基本教义，也没有系列的专业标准和伦理，更没有作为专业把关人的权威。 软件开发还缺少“关于知识的一致认知”——像医学或者法学——并且真正的“专业”都是通过随着时间而增长的经验和教训达到的，而不是通过书本或者大学教育达到的。
一些被采访者分享了最引人注意的发现，通向专业化唯一最大的障碍就是我们无法对从业者说不！ 没有你不能做的，没有不可能的，也没有不道德的。
拥有多个认证是成为专家的前提吗？
“老天，不！” “当然不！”在现存的认证和实际情况之间没有必然联系，Scrum Master是可笑的（它只意味着你交了钱），其他大多数认证也都是无用的。” 这种坦率而带有情绪的响应让我们很清楚地了解到，被采访者中没有人认为认证和专业精神之间有什么关联。 大多数人都指出了某些真正专业的认证，它们和博士类似，具有多年经验（例如实习期）可能对于定义专业的组织会很有用，但是即使是这样也是有问题的，因为大学课程远远无法提供作为软件开发者所要知道的知识。
软件匠艺运动会对专业化的问题产生显著影响吗？
“我希望那样，”Bob Martin说，他可能是软件匠艺运动中最值得注意和尊敬的一位，“那肯定会引起注意，并且是正确的路上的一步；它承认艺术和科学对于我们所做的工作都是非常重要的。”大多数其他被采访者都对其充满希望，但更加趋于保守。 这需要更大的挑战，而软件匠艺运动会将其推向正确的方向。” “认识到我们需要学徒阶段将是对此项努力最重要的贡献。” “我对软件匠艺运动不太确定，它类似于对极限实践的重新包装，其中增加了一些羞耻心的内容。” “软件匠艺只是对相同的旧话题‘更好地准备’的又一次重复——那是新一代程序员的产品，他们没有老家伙的技能和经验，所以他们正在寻找迎头赶上的方法。” 可能关于软件匠艺最大的保留意见是，它几乎完全是以程序员为中心，而忽略了更广泛的合作、管理、分析和设计的问题。
请推荐三本每个软件开发者必看的书籍！
* 《Freakonomics》, Steven Levitt和Stephen J. Dubner著
* 《The Checklist Manifesto》，Atul Gawanda著
* 《The Black Swan》，Nassim Nicholas Taleb著
* 《整洁代码之道》，Dean Wampler著
* 《Sketching the User Experience》，Bill Buxton著
* 《A Pattern Language》，Christopher Alexander著
* 《Peopleware》，Tom DeMarco和Timothy Lister著
* 《设计模式》，Gamma、Helm、Johnson、Vlissides著
* 《重构》，Fowler、Beck、Brant、Opdyke著
* 《Structure and Interpretation of Computer Programs》，Abelson、Sussman著
* 《Design of Everyday Things》，Donald A. Norman著
* 《Agile Project Management》，James A. Highsmith著
* 《Stand Back and Deliver》，Pollyanna Pixton著
* 《Orbiting the Giant Hairball》，Gordon MacKenzie著
* 《Pattern Hatching》，John Vlissides著
* 《Notes on the Synthesis of Form》，Christopher Alexander著
* 《Object Design and Designing Object-Oriented Software》，Rebecca Wirfs-Brock著
* 《解析极限编程》，Kent Beck著
* 《Manage your Project Portfolio》，Johanna Rothman著
* 《Flight of the Creative Class》，Richard Florida著
* 《The Global Brain Awakens》，Peter Russell著
* 《Difficult Conversations》，Stone、Patton、Heen、Fisher著
* Robert Heinlein的所有作品
* Jerry Weinberg的所有作品
* 《Classical Analysis texts》，Yourdon、Constantine、De Marco、Jackson著
请推荐两种软件开发者必须熟练使用的工具。
白板和Post-it笔记/索引卡片是大家最为推崇的两种工具。 大多数人认为重构浏览器，X-Unit测试工具以及持续集成工具非常有用；而针对程序员他们提到了版本控制工具和代码覆盖率工具。 大家都认为流程或者管理工具没有什么价值，除非是针对地域上分散的团队。
我们能够雇佣计算机科学、计算机工程或者MIS专业的BS、MS、MIS、Ph.D毕业生吗？
“还可以吧。” ，“从学校毕业的孩子们拥有最大的潜力，就像年轻的数学家一样，但是他们更需要知道如何为了生活而工作。” 一致的回答是： 学校中所讲授的内容很有限，并且经常会着重于错误的技能。 毕业生们需要实际的经验和知识，那只能来自于学徒生涯或者有时会来自于大型的实习项目。 显然，在大多数课程中都没有讲授团队和项目的经验、如何与用户沟通、分析和设计技能、协商技巧以及最佳实践。
软件开发中有无法外包的工作吗？
是的，任何需要理解具体环境、产品构思、使用分析、可用性、文化以及业务价值的内容都无法外包。 只有廉价的工作才能够外包。 而任何需要高密度的沟通以及依赖于创造力和创新能力的工作都无法外包。
除了QCON之外，您认为两个必须参加的会议是什么？
大型会议的价值已经在急剧地缩水，没有那个特别突出，大多数都会引来错误社区的人们。 有很多小型的区域性会议，它会在你确实涉及到的社区中聚集，并对该社区做出贡献。 你需要“找到自己的部队”，并与他们坐下来畅谈。 Qcon是很少的几个能够说清楚它是什么、并针对什么样的人所召开的会议之一。 对于新生代有大量其他机会来联系、分享和协作——会议的时代已经快要结束了，除非是那些专业的并且限制参加者的会议，像Jerry Weinber创办的AYE会议。
欧洲、亚洲和美国的软件开发时间在某些重要的方面有所不同吗？ 并且他们之间有可以互相学习的地方吗？
大多数被采访者都回避了这个问题，大多是因为缺少与其他国家的开发人员一起工作的经验。 每个人都认为，我们都需要更好地理解文化，以及文化是如何影响我们所做的、我们如何做以及当我们部署之后会造成什么样的影响。
在上个世纪八十年代，有过一次Smalltalk和C++之间关于所有语言之母的论战。 现在我们再次看到了面向对象语言（此次是Java）和函数式语言之间的冲突。 那么编程语言真的那么重要吗？
“不，就像是你讲西班牙语，但并不意味着你能写出一本书来。” 大家一致的共识是，因为编程语言都是图灵机，因此本质上是相同的，不会有重大的问题。 然而，不同的语言让你可以更轻松、更清晰地表达自己的意图，“如果你想要写本书”，你可能会发现，使用一种语言比使用其他语言更简单。 当前还有一种非充分版本的萨丕尔·沃尔夫假说，使用不同的语言，你可以思考不同的东西，并且支持你以不同的方式思考。 最终的问题在于你对“要说的东西”进行思考和概念化的能力，一旦你拥有了这种能力，那么就要找到一种语言，让你可以更直接且优美地表达出来。
* DevJam的David Hussman
* Atlantic Systems Guild的Tim Lister，他也是《Adrenaline Junkies and Template Zombies》、《Waltzing with Bears》和《Peopleware》的共同作者
* QSM Associates公司的Michael Mah，他也是位于Cutter Consortium的Benchmarking Practice的主管
* James Martin (Uncle Bob)，它是Object Mentor的创始人和总裁，并且编写了很多书籍，包括《Agile Software Development: Principles, Patterns, and Practices》
* Accelinnova 的Pollyanna Pixton，他也是《Stand Back and Deliver: Accelerating Business Agility》一书的共同作者。
* Rothman Consulting Group, Inc的Johanna Rothman，他也是《Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects》一书的作者
* Industrial Logic, Inc的高级教练Bill Wake，他也是《Refactoring in Ruby》一书的共同作者
* Wirfs-Brock Associates的Rebecca Wirfs-Brock，他也是面向对象设计方面的两本书籍的主要作者（《Designing Object-Oriented Software,》和《Object Design: Roles, Responsibilities, and Collaborations》）
我们向每个人都提出了相同的一系列问题，并将他们的回答整理总结如下。
可否请您指出当前的三种既“新”又“重要”的软件开发实践呢？ （新可能只是意味着对旧的实践进行了新的改进）
每个人都提到了测试驱动开发和自动化测试，Michael Mah指出，一个人只有明确了测试的重要性，才能够声称自己已经成为“软件工程师”了。 紧接下来的实践是重构，但是大多数被采访者都表示重构和重构浏览器提供了很大的潜力，但是他们担心团队不是总会给重构提供真正需要的、而且是必要的时间。 其他时间，按照被提到的次数列举如下： 持续集成（即便是针对瀑布式的项目），用户故事（作为工作单元和时间盒）和故事映射，多语言编程（很大程度上由Web开发所驱动），意图开发（programming by intent）、开放的环境，回顾（retrospectives），以及在任何类型的项目中适度地接受敏捷。
有几位被采访者提出，有种值得注意的新实践——业务分析和项目之间的分离，（在项目开始之前，将一组合理的用户故事/产品backlog放在一起），这可能是由不同团队完成的。
从总体上和行业范围内看，当今的软件开发与我们在二十世纪八十年代所做的调查中看到的相比，真的有什么不同吗？
这个问题得到了各种不同而有趣的回答，几乎所有人开始时都说没有改变。 正如Bob Martin所说：“区别仅限于形式上，实质上是相同的，我们还是在写IF、赋值和循环，耦合和内聚问题还是很重要，并且从中得到的教训在今天还是很重要。”
在做出最初的回答之后，他们几乎马上就会说“但是……”，然后会指出一些重要的不同之处。 例如：
* 当前的软件产业真的可以将已经下架的产品粘合起来，以生成自定义的和可用的软件。 这取决于两种完全不同类型的软件厂商，集成商（拥有大量集成解决方案的厂商）和一次性的生产商。
* 大多数人都认为，敏捷只是集合了诸多旧观点，但是使用了一种新方式来集成，以创造出一种崭新的哲学，来进行关于软件的思考，它强调创新、质量和提升对在“业务时间”中的业务需求所作出的响应。多位应答者都注意到一种重要的、态度上的转变： 开发者会掌握整个开发过程，并且对于工作越来越更负责任。 所有权会让他们更赞同“为生产创建原型”的想法，而这在八十年代被认为是不可能的。
* 每个人都提出了这样的问题，我们可能正在做同样的事情，但是遇到了更严重的问题，并且试图创建更加复杂的系统。 然而，有人指出这种复杂性上的改变以及我们发布它的速度已经导致了更大、并且可能会扩散的“一团团烂泥（Balls of Mud）”。 事实上我们拥有多种不同的平台，最重要的是网络、并行硬件以及云资源已经与二十世纪八十年代相比有了很大的改变。
* Michael Mah指出我们正在创建“令人惊奇的新产品，交互网络，分布式协作，社交网络，并且我们做的越来越快。” 不幸的是，与此同时缺陷也增加了75%，我们更快地创建了垃圾代码，并且累积了越来越多的技术债务，它们应该被尽早解决。
二十世纪八十年代是大型机的时代；而当今是云的时代。 二者之间有什么不同吗？
从架构上来说，云只是大型的集中式平台，它与大量智能终端相连接，因此可以认为也是大型机。 但是它与大型机也有一些重要的区别。 作为资源，云环境是高度可配置的，并且比试图使用“自己的”类似资源要便宜得多。 云也是无限可配置的、灵活的和可自定义的——旧的大型机不具备这些特点。
云架构有很大的安全隐患，因此你要仔细考虑是否要将最敏感的数据放在上面。 很少有人知道在云中会发生何种“灾难性的故障”，也没有人知道这样的问题会对公司、经济甚至是国家安全造成多大的影响。
云也正在改变信息关系——你不再能够使用这样的借口，“它在我家里的另一台计算机上。” 把这么多信息放在那里也会影响创造可能性的决定，甚至会影响新的协作和分布式决策领域的领导者。对于云来说，它有可能会加速当前的超级集成（hyper- integration）的趋势，还有非常实际的死锁的问题，以及“将你的灵魂出售给”拥有大量集成应用程序的厂商。
大多数围绕云的真正问题都不是技术上的——这并不是因为它是“天空中的大型机”——而是实际生活中的业务和社会，这并非是技术人员所能够解决的问题。
敏捷已经成为主流！ 这意味着它成功还是失败了？
既是成功，也是失败。 它几乎已经失败了，因为“每个人都在做，但每个人做的都不一样，没有人知道他们在做什么。” 它已经成功地为一些人和一些工资赚了很多钱，因为“那些疯狂的主意”当前被严肃地采用了，使人们知道真的有一种不同的软件开发方式。 敏捷还让我们能够试着应付不同的问题，因为敏捷让我们可以“寻找通向解决方案之路，而不是在开始之前就预先构想解决方案。”
敏捷的观点无法包含这样的事实，它已经被真的销售一空，也没有标准能够说明“这是敏捷或者这不是敏捷”，所以所有的一切都可能是敏捷。 Michael Mah提到了他们公司以及Cutter的数据，指出只有三分之一所谓的敏捷项目名副其实。更麻烦的是，其他三分之二所谓的敏捷项目比传统的项目拥有很高的缺陷率，很显然这没能达到敏捷的承诺。 Bob Maring指出“主流只意味着不具有新闻价值了”，尽管大多数敏捷实践仍然处于争论之中，“但已经有了组织并且落在了实际的项目中”。
还有一些更有趣的关于敏捷“迷失了方向”的评论，它关注的是这样的事实，太多的支持者没有意识到什么是真正重要的，而什么并不重要： “关于看板和Scrum的争论很不恰当，敏捷是一个概念，而不是特定的实践或者一组实践；”并且，“敏捷是关于学习的，而不是要牢记那些仪式和实践。”
几乎所有人都觉得将来敏捷会遭到强烈的反对。
软件开发具有专业性吗？ 并且，软件开发者是专家吗？
两个问题的答案都是：不！ 可能在初期有这样的职业，但现在已经不再有了。 当然，有一些开发者是不同的，他们是标准的例证，拥有真正专业的技巧，并赢得了大家的尊敬，我们一致认为他们是专家的典范，但不幸的是，大多数开发者都与他们不同。
很有趣的是，有人指出大多数针对“专业化”的观点都会伴随着关于管理是否具有专业性的争论（请参见最新的一期Harvard Business Review）。 正如David Hussman所指出的，“软件开发者没有什么专业性可言；”没有像医师的“不伤害”一样的基本教义，也没有系列的专业标准和伦理，更没有作为专业把关人的权威。 软件开发还缺少“关于知识的一致认知”——像医学或者法学——并且真正的“专业”都是通过随着时间而增长的经验和教训达到的，而不是通过书本或者大学教育达到的。
一些被采访者分享了最引人注意的发现，通向专业化唯一最大的障碍就是我们无法对从业者说不！ 没有你不能做的，没有不可能的，也没有不道德的。
拥有多个认证是成为专家的前提吗？
“老天，不！” “当然不！”在现存的认证和实际情况之间没有必然联系，Scrum Master是可笑的（它只意味着你交了钱），其他大多数认证也都是无用的。” 这种坦率而带有情绪的响应让我们很清楚地了解到，被采访者中没有人认为认证和专业精神之间有什么关联。 大多数人都指出了某些真正专业的认证，它们和博士类似，具有多年经验（例如实习期）可能对于定义专业的组织会很有用，但是即使是这样也是有问题的，因为大学课程远远无法提供作为软件开发者所要知道的知识。
软件匠艺运动会对专业化的问题产生显著影响吗？
“我希望那样，”Bob Martin说，他可能是软件匠艺运动中最值得注意和尊敬的一位，“那肯定会引起注意，并且是正确的路上的一步；它承认艺术和科学对于我们所做的工作都是非常重要的。”大多数其他被采访者都对其充满希望，但更加趋于保守。 这需要更大的挑战，而软件匠艺运动会将其推向正确的方向。” “认识到我们需要学徒阶段将是对此项努力最重要的贡献。” “我对软件匠艺运动不太确定，它类似于对极限实践的重新包装，其中增加了一些羞耻心的内容。” “软件匠艺只是对相同的旧话题‘更好地准备’的又一次重复——那是新一代程序员的产品，他们没有老家伙的技能和经验，所以他们正在寻找迎头赶上的方法。” 可能关于软件匠艺最大的保留意见是，它几乎完全是以程序员为中心，而忽略了更广泛的合作、管理、分析和设计的问题。
请推荐三本每个软件开发者必看的书籍！
* 《Freakonomics》, Steven Levitt和Stephen J. Dubner著
* 《The Checklist Manifesto》，Atul Gawanda著
* 《The Black Swan》，Nassim Nicholas Taleb著
* 《整洁代码之道》，Dean Wampler著
* 《Sketching the User Experience》，Bill Buxton著
* 《A Pattern Language》，Christopher Alexander著
* 《Peopleware》，Tom DeMarco和Timothy Lister著
* 《设计模式》，Gamma、Helm、Johnson、Vlissides著
* 《重构》，Fowler、Beck、Brant、Opdyke著
* 《Structure and Interpretation of Computer Programs》，Abelson、Sussman著
* 《Design of Everyday Things》，Donald A. Norman著
* 《Agile Project Management》，James A. Highsmith著
* 《Stand Back and Deliver》，Pollyanna Pixton著
* 《Orbiting the Giant Hairball》，Gordon MacKenzie著
* 《Pattern Hatching》，John Vlissides著
* 《Notes on the Synthesis of Form》，Christopher Alexander著
* 《Object Design and Designing Object-Oriented Software》，Rebecca Wirfs-Brock著
* 《解析极限编程》，Kent Beck著
* 《Manage your Project Portfolio》，Johanna Rothman著
* 《Flight of the Creative Class》，Richard Florida著
* 《The Global Brain Awakens》，Peter Russell著
* 《Difficult Conversations》，Stone、Patton、Heen、Fisher著
* Robert Heinlein的所有作品
* Jerry Weinberg的所有作品
* 《Classical Analysis texts》，Yourdon、Constantine、De Marco、Jackson著
请推荐两种软件开发者必须熟练使用的工具。
白板和Post-it笔记/索引卡片是大家最为推崇的两种工具。 大多数人认为重构浏览器，X-Unit测试工具以及持续集成工具非常有用；而针对程序员他们提到了版本控制工具和代码覆盖率工具。 大家都认为流程或者管理工具没有什么价值，除非是针对地域上分散的团队。
我们能够雇佣计算机科学、计算机工程或者MIS专业的BS、MS、MIS、Ph.D毕业生吗？
“还可以吧。” ，“从学校毕业的孩子们拥有最大的潜力，就像年轻的数学家一样，但是他们更需要知道如何为了生活而工作。” 一致的回答是： 学校中所讲授的内容很有限，并且经常会着重于错误的技能。 毕业生们需要实际的经验和知识，那只能来自于学徒生涯或者有时会来自于大型的实习项目。 显然，在大多数课程中都没有讲授团队和项目的经验、如何与用户沟通、分析和设计技能、协商技巧以及最佳实践。
软件开发中有无法外包的工作吗？
是的，任何需要理解具体环境、产品构思、使用分析、可用性、文化以及业务价值的内容都无法外包。 只有廉价的工作才能够外包。 而任何需要高密度的沟通以及依赖于创造力和创新能力的工作都无法外包。
除了QCON之外，您认为两个必须参加的会议是什么？
大型会议的价值已经在急剧地缩水，没有那个特别突出，大多数都会引来错误社区的人们。 有很多小型的区域性会议，它会在你确实涉及到的社区中聚集，并对该社区做出贡献。 你需要“找到自己的部队”，并与他们坐下来畅谈。 Qcon是很少的几个能够说清楚它是什么、并针对什么样的人所召开的会议之一。 对于新生代有大量其他机会来联系、分享和协作——会议的时代已经快要结束了，除非是那些专业的并且限制参加者的会议，像Jerry Weinber创办的AYE会议。
欧洲、亚洲和美国的软件开发时间在某些重要的方面有所不同吗？ 并且他们之间有可以互相学习的地方吗？
大多数被采访者都回避了这个问题，大多是因为缺少与其他国家的开发人员一起工作的经验。 每个人都认为，我们都需要更好地理解文化，以及文化是如何影响我们所做的、我们如何做以及当我们部署之后会造成什么样的影响。
在上个世纪八十年代，有过一次Smalltalk和C++之间关于所有语言之母的论战。 现在我们再次看到了面向对象语言（此次是Java）和函数式语言之间的冲突。 那么编程语言真的那么重要吗？
“不，就像是你讲西班牙语，但并不意味着你能写出一本书来。” 大家一致的共识是，因为编程语言都是图灵机，因此本质上是相同的，不会有重大的问题。 然而，不同的语言让你可以更轻松、更清晰地表达自己的意图，“如果你想要写本书”，你可能会发现，使用一种语言比使用其他语言更简单。 当前还有一种非充分版本的萨丕尔·沃尔夫假说，使用不同的语言，你可以思考不同的东西，并且支持你以不同的方式思考。 最终的问题在于你对“要说的东西”进行思考和概念化的能力，一旦你拥有了这种能力，那么就要找到一种语言，让你可以更直接且优美地表达出来。