为什么这么久？！
前言
翻译定律
质量三角
布鲁克斯定律
不要低估基础的作用。
您可以如何提供帮助
前言
如果你运营一个软件项目，尤其是一个开源软件项目，你几乎肯定会听到类似这样的话……
我们需要更加努力地推动进步。
一周都没人表态？搞什么鬼？
软件什么时候能完成？
为什么还没有发布 Beta 版本？
你们到底在干什么？？
如果你听到这些话，可能会感到沮丧。但请放心，大多数情况下，即使是最不耐烦的抱怨，也并非出于恶意。没错，有些用户……好吧，其实是很多用户……对开发进度抱有极不合理的期望，但这主要是因为他们缺乏软件开发方面的知识。所以，深呼吸，记住，他们只是信息有误，而非恶意。
然后冷静地将它们链接到这篇文章。
如果你是从某个你关注的项目的开发者那里拿到这篇文章的，或者你曾经说过上面提到的任何话，那么你需要明白一点：软件开发的时间线从根本上来说就很奇怪。或者，正如业内一句古老的谚语所说……
无论安排多少女性参与分娩，生一个孩子都需要九个月的时间。
软件开发似乎有自己的想法。不，计算机没有意识，这与人们常说的“奇点”（即我们的设备将推翻人类）毫无关系。这一切都源于软件本身独特的特性。你完全可以花一辈子时间研究这个问题——弗雷德·布鲁克斯基本上就是这么做的——但你们大多数人都没有那么多时间。所以，让我来为你们讲解一些基础知识。你可以把它看作是软件项目管理入门课程的精简版。
注：如果您想了解完整版本，请阅读斯科特·罗森伯格的《代码之梦》 。该书以命运多舛的钱德勒项目这一真实警示故事为切入点，进行了更为生动的细节描述。
翻译定律
软件开发耗时有限，任何人为干预都无法突破这个固有的“速度限制”。没有人真正计算过如何确定这个“项目固有进度”。我们所能做的，只是尽量避免干扰，以免雪上加霜。
软件为何需要花费时间运行，以及我们为何完全无力推动其运行，至今仍是个谜（稍后会详细说明）。但我认为其根本原因可能在于我称之为“翻译定律”的法则……
翻译定律：当双方没有天然的共同理解基础时，就无法客观地检验知识传递的质量。
为了避免语无伦次，我们不妨想象一下两个人。一个以西班牙语为母语，另一个以因纽特语为母语。他们彼此都不懂对方的语言，也没有任何共同的文化经历。撇开非语言交流（为了便于类比，我们暂且忽略这一点），他们只有三种交流方式。
- 讲西班牙语的人必须学习因纽特语。
- 因纽特人必须学习西班牙语。
- 他们俩都必须学习一种共同语言，比如世界语。
然而，无论采用哪种方法，他们都无法了解对方的思维方式。如果因纽特语使用者指导西班牙语使用者如何建造冰屋，而西班牙语使用者从未见过任何形式的冰雪，那将是一项艰巨的任务！更棘手的是，因纽特语使用者必须能够发现对方的理解偏差，而只有两种方法可以做到这一点：
-
说西班牙语的人可能会意识到自己听不懂，并向说因纽特语的人表达出来。
-
说西班牙语的人可能认为自己理解了，并采取了错误的行动，而说因纽特语的人则注意到了这一点。
换句话说，因纽特语使用者根本无法得知西班牙语使用者是否理解这个概念；他要么必须被明确告知，要么必须从观察到的结果中推断出对方缺乏理解。然后，他必须想办法帮助西班牙语使用者理解，但这很困难，因为他实际上并不知道究竟哪里出了问题！
程序员用人类语言交流和思考，而计算机则用二进制数学和CPU指令“交流”和思考，两者之间的情况几乎完全相同。计算机本质上无法进行抽象思考、推理和得出结论，以及其他许多我们习以为常的人类大脑功能。与此同时，计算机会将每一个想法都分解成简单的加法运算；而我们人类却做不到。
因此，我们只有三种方式可以与计算机进行交流，从而可以教计算机（编程）。
-
程序员必须学会用二进制 CPU 指令思考和编写代码……有些人已经做到了。
-
计算机必须学习，或者更确切地说，被教导，才能用人类语言思考。尽管计算机看起来似乎可以做到这一点，但实际上这只是障眼法。我们距离通过图灵测试（可以查阅相关资料）还有很长的路要走。
-
程序员和计算机必须学会使用共同的语言进行工作。这些就是我们的编程语言，99% 的编程工作都是在这里进行的。
然而，这样做我们仍然面临同样的问题：我们没有直接的方法来知道计算机对我们的理解程度。我们只能通过同样的两种方式来了解这一点。
-
计算机意识到它无法理解指令，并告知程序员。这是一个“编译错误”。
-
电脑误解了信息，做了错误的事情，而我们则目睹了这一切。
然后程序员必须弄清楚计算机到底哪里理解不了，这尤其困难。
这就是软件开发与建造桥梁截然不同的根本原因。当你设计建造某件东西时，你可以精确地看到并测量出哪里出了问题。然而，当你编写代码时，你必须克服人与计算机之间的“语言障碍”才能推断出问题所在。而这正是软件漏洞的本质！
事实上，一开始你根本无法预知你的人类思维在电脑上的转化效果如何。在我们看来很简单的任务，比如从房间里的二十个人中找出最高的人，对电脑来说实际上却异常复杂。
更棘手的是，你不仅要处理自己给计算机的指令，还要处理成百上千其他程序员在编程语言、框架、库、操作系统等等方面给出的指令。这些被称为“抽象层”，它们让我们逐渐远离计算机语言的二进制代码，而更接近人类语言。进入任何一个抽象“栈”时，我们都无法预知是否存在其他翻译错误或“bug”，它们可能会拖慢我们的速度。
简而言之，编写软件的整个过程都极易受到这些翻译错误的影响，一个看似简单的任务很容易演变成长达数月的指令（编写）、观察（测试）、推断（调试）……反复操作的漫长过程。
质量三角
软件开发中有一个叫做“质量三角”的原则，它指出……
我可以做到快速、便宜或高质量，三者只能选两项。
对此其实有多种合理的解释，但与我们讨论相关的解释是这样的……
-
我们可以很快完成。
-
我们可以低成本地生产它。
-
我们可以使其相对稳定且没有漏洞。
只能二选一。如果想要速度快，开发人员就需要投入更多时间，这会增加成本。如果想要更稳定，开发人员就必须花更多时间进行测试和调试，而不是仅仅宣布“完成”就急于开发下一个功能。如果想要更便宜，他们要么牺牲质量，要么就得花更多时间。
有些项目试图同时实现这三个目标，结果却惨不忍睹，令人不寒而栗。开发人员精疲力竭，对自己的职业生涯充满怨恨；软件漏洞百出，延期严重；项目延期，预算超支。如果你试图同时实现这三个目标，最终必然会全部落空。软件会超出预算、延期交付、不稳定、漏洞百出，并且缺少关键功能。在大多数情况下，最终产品甚至都无法面世。
但是，即使只能选择两个，也有一些限制。
首先，你不能仅仅通过砸钱来加快项目进度。开发人员每周能工作的时间是有限的，超过这个时间他们就会精疲力竭，而且我们还要考虑布鲁克斯定律（见下一节）。高预算项目肯定比低预算或无预算项目完成得更快、质量更高——至少假设资金投入到开发人员及其基础设施建设中，而不是管理层奖金——但这终究是有极限的。
其次，即使预算无限，如果质量目标设定得过高，最终完成软件开发所需的时间也可能超过已知宇宙的寿命。几乎所有软件都存在漏洞。虽然存在一些罕见的、看似完美无瑕的软件，它们确实没有任何已知问题，但这通常是因为其功能集受到严格限制。唯一真正没有漏洞的软件，就是没有任何功能的软件。
或者，正如斯科特·罗森伯格恰如其分地指出的那样……
软件开发很难。
布鲁克斯定律
用大量人手加快项目进度的想法由来已久。尽管我们中的一些人可能会嘲笑这种做法，但它在某些更实际的领域确实有效：用20人的团队盖房子肯定比用10人的团队快，而用30人的团队盖房子就更快了！
IBM项目经理弗雷德·布鲁克斯在20世纪70年代初首次观察到这种方法在编程领域行不通，这促使他写下了具有里程碑意义的著作《人月神话》。在这本书及其续作《没有银弹》中，他对软件开发的本质提出了许多重要的见解。也许他最经典的见解就是所谓的“布鲁克斯定律”：
给一个已经延期的软件项目增加人力资源只会让项目延期。
即便布鲁克斯也认为这是一种过于简化的说法，但这句格言仍然很有用。参与项目的人越多，拖慢进度的因素就越多。你必须培训他们，考虑他们的意见，确保他们理解想法，确保其他人理解他们的想法，等等。
换句话说，如果有六个因纽特语使用者向一个西班牙语使用者解释如何建造冰屋，你可以想象很容易出现怎样的混乱：对西班牙语使用者来说，相互矛盾和令人困惑的指示，需要更多的人来理解这些误解的性质，以及简单的“人多手杂”。
现在，有时可以通过增加人手来加快项目进度，但这需要精准的计划、精心组织的协作以及有效的实践来促进这一切。而要把所有这些都结合起来，需要……你猜对了？……时间！
对此，许多好心的项目经理、开发人员和观察员会提出一大堆“神奇”的组织技巧和方法，声称可以解决所有问题，让团队和睦相处。值得庆幸的是，弗雷德·布鲁克斯对此也有自己的看法……
无论是技术还是管理技术，都没有任何一项单独的发展能够保证在十年内，在生产力、可靠性和简易性方面实现哪怕一个数量级（十倍）的提升。
每个项目、每个团队都是独一无二的。没有一种方法适用于所有人。或者，正如布鲁克斯所说，没有“万能灵药”。
换句话说，没有任何方法，也不可能让软件的运行速度超过它“想要”的速度。无论你用尽一切办法，它仍然会按照自己的节奏运行。
（想了解更多信息，请阅读弗雷德·布鲁克斯的《人月神话》和《没有银弹》。里面有很多有用的信息！）
不要低估基础的作用。
如果你正在观察一个项目的早期阶段，你还必须考虑到项目的另一个关键部分，尽管它是看不见的：地基！
一个高效的编程团队必须拥有完善的工具、标准和方法论，而这需要花费大量时间！举个例子，我在 MousePaw Media 花了整整两年的全职时间才为我的团队敲定了整个开发平台、工作流程和标准……而这还是在经过几年的摸索之后。2017 年全年，我几乎没有时间写代码，更不用说 2016 年下半年了，因为我都在忙着完善这些。当然，我的团队在那段时间也能工作（尽管很困难，缺少一些必要的工具），但这仍然拖慢了我们的进度。
别灰心！并没有规定每个项目都需要两年时间来完善开发平台。但是，这确实需要时间，而且就像软件开发本身一样，根本无法设定截止日期。
简而言之，如果开发人员似乎在启动项目方面拖延时间，他们很可能只是在打基础。这是一个漫长、艰辛且大多不为人知的过程，但对项目的成功至关重要！
您可以如何提供帮助
这时，你可能会想：“哦，糟糕，这个项目永远也完成不了，对吧？？？”
别担心！我刚才描述的情况适用于每一个软件项目，而且如果你还没注意到的话，我们最终确实能够交付功能完善的软件！无论是商业公司还是开源组织，都能发布优秀的游戏、应用程序、工具、网站和操作系统。软件开发的确能够完成……只不过它完成的时间线有点奇怪，难以预测。
那么，你能如何提供帮助呢？其实很简单。
-
不要催促软件开发加快进度，而是要拿出实际行动来。为项目增加资金和/或人力，就能加快项目进展。问问自己怎样才能提供最大的帮助！
-
如果你决定帮忙，记住，我们是在对抗布鲁克斯法案，所以如果你主动提出做很多苦力活被拒绝，别觉得被冒犯……这不是你的错！你或许可以帮上忙，做一些简单的编码和项目任务，这样开发人员就可以专注于真正棘手的问题。
-
最重要的是，请帮助其他人了解这些概念！被用户（甚至更糟的是，旁观者）唠叨是我们开发者面临的最令人恼火的事情之一。请分享您在这里学到的知识，帮助我们减少抱怨和攻击。