Answers:
2014年的开发人员生产软件的速度是否比1986年的开发人员快10倍？
我可以想象，自那时以来，生产率至少提高了一个数量级。但是，不能通过单一技术或管理技术来开发。
多种因素共同导致了生产率的提高。注意：这不是完整的列表：
等等。所有这些技术结合起来可以提高生产率。没有一个银子弹可以产生一个数量级的加速。
请注意，其中一些技术自60年代就已经存在，但是直到最近才得到广泛的认可和采用。
罗伯特·哈维（Robert Harvey）的回答很好，但是我认为他没有提到程序员比以往更高效的最大原因：软件库的广泛可用性。
当我开始我的职业生涯时，没有STL，.NET，QT等。您拥有原始的C或C ++，仅此而已。
现在可以用几行C＃代码完成过去需要数天或数周才能完成的工作（XML解析，TCP / IP连接，HTTP通讯）。在这方面，我们在整体开发人员的生产率方面提高了几个数量级。
我们当前的产品使用从供应商处购买的对接窗口框架。这让我在几分钟内就拥有了功能齐全的停靠窗口UI。我不禁思索在使用win32 API的日子里需要做什么。
people just found other (generally better) solutions[需要引用]。使用库快速解析XML的“山脉”比手工编码独特的解决方案要好得多。XML当然可以过于简洁和重复，但是在大多数情况下，库使使用它变得轻而易举。
为了争辩，我不同意弗雷德·布鲁克斯的主张。
技术的进步使互联网的生产力仅得到了一个数量级的提高，更确切地说是最近二十年来每个家庭中互联网连接的逐步可用性。
能够立即找到开发人员遇到的几乎所有问题的答案，从而极大地提高了生产率。不知道如何在JQuery中选择第n个元素？Google搜索会导致有关Stack Overflow的确切问题的答案。不知道如何overflow在CSS中使用？Mozilla的MDN在这里。忘记了virtualC＃中的关键字含义？Google再次提供帮助。
开始编程时，我没有互联网。我有书籍，以及一些本地存储的数字格式文档，但是搜索书籍和文档是一个缓慢的过程，无论我有多少本书，这里都没有提到很多问题。
更重要的是，您遇到的几乎所有问题以前都已经被别人遇到过。Internet可以帮助找到出现此错误并成功解决此错误的人。这不是您在书籍或MSDN等官方文档中找到的信息。相反，通常会找到以下信息：
显然，在堆栈溢出时。例如，我还没有看过任何提到此问题的书。
在博客中。当我遇到特殊问题时，我在博客上找到了很多帮助，例如WCF配置或无法启动的代理服务器，或者在具有不同于en-US的文化的机器上使用特定API时出现的神秘错误。
在有关开源软件的错误报告中。例如，最近当我尝试使用Ubuntu的MAAS和使用PXE时，这非常有用。您也不会在书中找到这种信息。
如果我们考虑到团队在项目上花费的大部分时间都花在了维护项目上，那么立即获得人们可能遇到的大多数问题的答案的重要性就特别明显。
在架构和设计阶段，Internet并没有太大帮助（Programmers.SE可能会有所帮助，但对于建筑师而言，阅读有关架构和设计的书籍，学习设计模式等将具有更大的价值）。
当出现实际问题时，它在测试和实施步骤期间开始很有帮助。
但是大多数问题是在维护过程中出现的，当其他人通过互联网寻求帮助时就显得至关重要。基本示例：WCF服务在我的计算机上运行良好，但在过去两个星期中都正常工作时，无论在生产环境中部署时都无一例外地失败。这发生在我身上，我感谢博客作者和Stack Overflow社区帮助我在几小时而不是几周内解决了这个问题。
是否有理由将生产率提高10倍？很难说。
一方面，在某些情况下，您可能会花几天时间独自寻找答案（或者被迫重写应用程序的很大一部分），但立即找到答案。
另一方面，基于多个因素提高了整体生产力，例如更好的项目管理（想到敏捷，TDD等），更好的团队管理（想到了Stephen Denning的Radical Management），更好的工具（调试器，分析器） ，IDE等），更好的硬件（不，如果为了慢速的CPU和非常有限的RAM而被迫在Assembler中编写，我的效率将不高），等等。
我会说互联网是一个很好的候选人。StackOverflow和Google是当今开发人员最强大的工具。在全球范围内即时共享知识！如今，您不需要知道答案，只需要知道如何了解答案即可，这是一个非常合适的替代品，可让开发人员花费更少的时间阅读和更多的代码，从而提高工作效率。这意味着世界上每个程序员都可以使用所有答案，而他们所要做的就是知道如何提出正确的问题。
我建议将趋势拉向另一个方向（即降低生产率）的趋势至少与您所询问的趋势一样强大。使用客户端/服务器开发工具（如VB6或PowerBuilder）的经验非常接近“快速应用程序开发”（RAD）的理想。您必须绘制表格，并且过程或SQL代码有明显的钩子。
至少在最初，Web开发破坏了使这些事情成为可能的许多技术和基础架构，许多客户/服务器开发人员只是停止了他们的开发工作，或者拼命拥护VB6。
向大量客户端驱动的Web开发的过渡是又一次刀耕火种的经历。微软通过WebForms回到RAD的理想状态，然后很快就失宠了。取而代之的是，期望开发人员滥用基础结构（例如，很少用于XML的XMLHttpRequest），否则会以较低的抽象级别来回避，以使他们的网站更具交互性
所有这些转换背后都有充分的理由，将产生本机.EXE的过程（需要在单个客户端上进行安装和管理）与Web开发进行比较是不公平的，而将高度依赖的过程进行比较也很不公平。在回发上产生更无缝的体验。但是，我要说的是，当前正在流行的实践导致错过了客户端/服务器，RAD等功能的人们中某些出乎意料的低级思考过程。客户端/服务器按钮仅起作用，当然不必担心底层数据通道会将数据发送到使事件发生的事件处理程序。
相反，更多的当代开发人员倾向于认为我们中那些进行客户端/服务器开发（甚至基于回发的Web开发）的人倾向于诉诸捷径（并且以一种不好的方式表示）。这是可以理解的，但我仍然认为当代发展的方式出奇的低水平，寻找“银弹”的时代似乎已被嘲笑那些质疑采矿和采矿业智慧的我们时代所取代。冶炼自己的铅。
技术已经非常进步，现在我们有了Robert Harvey在他的回答中列举的所有内容，但是：
问题似乎正在改变需求。客户知道，在更改软件项目的需求时不会浪费材料，而是这样做。一旦像建筑物这样的物理世界项目完成了一半，这种需求变化几乎就不会发生。
另一个重要方面是编程仍然是高度手工的工作。很少（如果有的话），RAD生成的代码无需首先手动修改即可投入生产。
代码仍然非常复杂，并且新技术似乎并没有减少这种复杂性。
截止日期未达到或超出预算的比率继续高于其他学科，并且经常发生技术债务以偿还它们，从而产生了隐性成本。
毫无疑问，发生了部分隔离。人们必须知道的大量技术使得程序员不得不专门化少量技术才能真正熟练使用它们，这需要不同种类的专家来完成一个大型项目。
关于软件复杂性的一件事是，尽管世界上实际上有数百家汽车制造商，但是可以用手指来计算能够创建和维护操作系统（台式机，移动，嵌入式或其他）的公司列表。你的手。
以上所有情况造成了这样一种情况，即没有足够的人学习成为程序员，因此政府发起了竞选活动，以激励更多的学生走上这一职业道路。
软件行业的成熟度之一是，软件许可继续声明“ <companyX>不表示该软件对于任何特定目的的适用性。它按“原样”提供，没有明示或暗示的担保。” 想象一下，一家硬件制造商指出他们的产品不适合任何特定目的。这就是目前的最新水平。
尽管有人可能会用特定的指标争论（即，事情是否改善了9.98倍？），但我（作为老朋友讲）必须同意布鲁克斯评论的总体观点。
首先，自1970年以来，几乎没有发明任何真正的新技术。是的，集成电路的长度，高度，宽度越来越小，玻璃纤维提高了通信速度，但向前迈出的每一步都有。
与1970年相比，编译器技术使程序员的“生产率”提高了大约十倍，而1970年的数字函数除以实际的编码时间，但是新的或“修订的”编程语言和环境的泛滥意味着普通程序员的支出越来越多时间处于“追赶”模式，而生产活动减少。苹果，谷歌和微软都对其环境进行了新的，实质上不兼容的“升级”，其速度恰好会激起其农奴，编程客户的反抗。同样，HTML / CSS / Javascript /任何事物都会变得越来越复杂。
一次，文档的产生和传播速度会限制和破坏所有这些“创新”，但是，由于有了Internet，实际上不再需要严格的文档了-只需散发出功能并依靠博客来找出细节并提供它们。
补充： 我从昨天开始一直在考虑这个问题，尤其是考虑我从1978年到2008年从事的项目。该项目（IBM System / 38及其后续产品）从一开始就是以控制软件的复杂性（一种是将软件分为两个大致相等的部分，它们之间具有“机器”接口）。在我工作的特定领域，我的几个同事同样致力于控制复杂性（尽管当时我们并没有太多使用该术语）。结果是（最初）产品非常健壮，并且从git-go中获得客户的好评。继续工作是一种乐趣，就像在训练有素的乐队中演奏一样。
当然，这些年来，复杂性逐渐兴起，通常是由于市场规划者和经理不愿控制复杂性（这在某种程度上不同于保持简单性）而引起的。我不认为这是不可避免的，但是在这种情况下，如果没有经理（像格伦·亨利本来那样）阻止混乱局面，就无法避免。
在过去30多年的时间里，我们在软件工程实践中学到的很多东西都具有以下形式：“技术X可以加快新软件的初始开发速度，但是如果您不花太多或更多的时间思考如何以及如何从长远来看，什么时候使用它可以节省您的应用程序，从长远来看，它将使您的应用程序陷入技术债务的泥潭，从而使您花费大量的时间和精力进行维护。”
属于这种剃须刀的技术包括：手工编码的汇编语言，编译器，解释器，过程库，命令式编程，函数式编程，面向对象的编程，手动内存分配，垃圾回收，静态类型，动态类型，词法范围，动态范围，“安全”指针，“不安全”指针，缺少作为语言概念的指针，二进制文件格式，结构化标记文件格式，宏，模板，避免使用宏和模板，共享内存，消息传递，线程，协程，异步事件循环，集中式远程服务，分布式服务，本地安装的软件，阵列，链表，哈希表和树。
上面列表中的许多项目分组在一起消耗了已知的解决方案空间这一事实是非常有意的，它本身应该告诉您一些信息。有人可能会说，自从他们第一次打开Z3以来，我们在实践上唯一明确的，全面的改进就是块结构化编程（与意大利面条式代码相对）和内存保护（男孩，我可不会错过）打字错误可能会使我的整个计算机瘫痪的日子）。