开放讨论星期四：尽早发布，经常发布？

还没有读者喜欢这个。
Open Thread Thursday
图片来源：

Opensource.com

您可能熟悉托马斯·爱迪生的名言：“我没有失败。我只是找到了 10,000 种行不通的方法。” 在开源之道中，这个原则有时被称为快速原型设计，或“尽早发布，经常发布”。其理念是，更快的原型可以导致更快的失败。而更快的失败会带来更快的解决方案。

您怎么看？您同意这种理念吗？如果同意，我们如何帮助组织将小的失败视为迈向巨大成功的步骤？

在下方分享您的想法。

标签
商业
Jonathan Opp
User profile image.
我是 New Kind 的总裁兼合伙人，这是一家品牌 агентство，专门帮助开源和 SaaS 技术公司发展。曾任 Red Hat 品牌传播与设计高级经理，此前曾在 IBM 和 Gateway 担任传播职务。在 LinkedIn 上查找 Jonathan。
更多关于我

12 条评论

Avatar
Rebecca Fernandez | 2010 年 2 月 4 日
还没有读者喜欢这个。

我认为美国每季度都需要良好的股票价格的体系确实影响了这一点。我在其他地方读到，日本投资者期望长期回报，并且不介意短期下跌，因此日本高管可以更自由地投资于他们的业务，并且我可以想象，尽早且经常失败，以产生更具创新性的想法。

Avatar
未具名 | 2010 年 2 月 4 日
还没有读者喜欢这个。

我认为在某些情况下，恐惧是不将失败视为最终结果的步骤的决定因素。
如果我有事要做，而我的组织过于封闭，我就不会冒必要的风险去尝试不同的方法……我会尝试我认为安全的默认方法。
也许在一个开放的组织中，我的失败会被我的同事理解并用作学习步骤。

Avatar
未具名 | 2010 年 2 月 4 日
还没有读者喜欢这个。

在最新的 Ubuntu 和 Debian 上测试一下。

对于家庭/办公室电脑（不是测试平台），您更喜欢哪个？

您应该知道答案。

Avatar
Drew Kwashnak | 2010 年 2 月 4 日
还没有读者喜欢这个。

开源项目通常可以包含的一个选项是进行更新的能力，这些更新不会添加新内容（功能、小部件或花哨的东西），但可以清理代码或重新对齐代码以方便未来的更改/附加组件。

我无法想象像 Microsoft Office 2010 基本上是 Office 2007，只是对其进行了一些不易察觉的更改，以便 Office 2012 能够利用一些新技术或范例，或者只是为了使 2010 更安全。

因此，使用开源模型，可以将它发布给人们，获得真实世界的反馈和经验，并根据需要构建或回溯。

对于 Office 示例，他们测试和尝试安全或代码清理的唯一方法是执行它，在本地和少量测试人员子集中进行测试，然后将其出售给公众，公众必须看到足够的价值才能花钱购买它。

只要管理者能够看到“好的，这是一个失败……发生了什么以及为什么以及我们将如何绕过它？”，失败就真的不是失败。

但是，通过开源，即使一个项目正在挣扎，其他人仍然有可能以正确的态度查看并将其失败转化为成功（无论是在项目中还是在项目的分支中）。

Avatar
Marc Dekens | 2010 年 2 月 4 日
还没有读者喜欢这个。

我想这将取决于您想要开发的产品或服务的类型。当我的房子要作为开放建筑网络 (http://openarchitecturenetwork.org) 的一部分建造/开发时，或者如果有人梦想着建立一个开源的健康诊所/医院。或者一条开源汽车生产线，我都不想过早地介入建设过程。

但是当风险较低时，我同意。额外的好处是，商业公司可能会避免开发类似的产品，这对整个人类来说更好。

说到这里：有多少应用程序是真正有创意和原创的开源努力？在我看来，很多活动是对商业服务或产品的反应。倒不是说这不好，但是如果你想改变世界，你想发起一场具有新的和充满希望的视角的运动，我想。就像你“反战或恐怖主义”或“促进和平”时的观点有所不同一样。转变范式，跳出框框思考之类的事情。设计你想要看到的未来。当你过于频繁地发布你的奇妙想法时，最终的结果是否会变成你想要的那样？还是可以做到的？

仅供参考。

Marc

Avatar
Gunnar Hellekson | 2010 年 2 月 4 日
还没有读者喜欢这个。

我完全同意您必须考虑风险。降低风险的一种方法，这样您就可以从“向前失败”中受益，就是保持您的任务小而精。我认为，如果您能够将一个大型、复杂和高风险的项目分解为许多较小的部分，您可以确保每个单独的部分都从早期的失败中受益，而不会损害更大的项目。这也确保了任何单独的部分都可以换成更好的部分。

可互换的零件：仍然是个好主意。

Avatar
MyRoyFriend | 2010 年 2 月 6 日
还没有读者喜欢这个。

在工程学中，您不会尝试 10,000 种不同的东西并找出哪一种有效，如果您正在设计电子电路，您不会“猜测”您将哪些组件放在哪里并希望获得最好的结果，如果您碰巧侥幸成功地获得了 1/10,000 的正确组合，您就很幸运了。

工程学不是基于运气，而是基于科学和工程原理，您不会通过“尝试事物以查看它们是否有效”来设计桥梁。您使用特定的设计、测试、分析方法，并循环使用这些方法来最终获得可行且有效的产品。

爱迪生尝试了 10,000 种不同的灯丝来制作灯泡并找到一种有效的方法是可以的，但是您不能将相同的技术应用于建筑物、桥梁、飞机、药物、软件、硬件或任何其他真正的物体。

爱迪生非常执着，尝试了很多东西，如果他背后有更多的科学知识和理论，许多东西都会被拒绝。

例如，很容易不测试那些不会导电的灯丝。就像他尝试过马毛、细绳、纸张等等。不导电的东西可以被排除在外。

对于软件，程序应该是一样的，它应该是专门设计和工程化的，软件开发不应该是“试验和错误”。这在 FOSS 中很常见，尽早且经常发布，而不是发布完成和经过测试的版本，这正在使 FOSS 失败。

我当然不希望使用来自一家在开发药物时使用“试验和错误”方法的制药公司的药物。正如我不信任应用相同试验和错误方法的软件一样。

因此，在 FOSS 软件从业余“工艺”转变为专业的工程学科，并承担起工程师设计摩天大楼不会倒塌的所有责任之前。软件 (FOSS) 需要努力达到这些专业标准或质量，而不是将二流（我们尝试过并且对我们有效）的代码和产品发布给普通用户。

如果您是一名摩天大楼工程师，并且您犯了一个错误，并且它在第一次小风中倒塌了，您可能会因过失杀人罪而被判入狱。错误根本不应该被允许出现在软件、硬件或任何工程学科中。

从质量保证标准中吸取教训，

“第一次就把正确的事情做对，每次都这样做”。

Avatar
Gunnar Hellekson | 2010 年 2 月 6 日
还没有读者喜欢这个。

我不了解您，但在我的经验中，很少有软件项目能从结构工程师的方法中受益。在某些情况下，您是对的：提前周密计划并完美执行是有意义的。但是不要低估这到底需要什么。例如，这些人

http://www.fastcompany.com/magazine/06/writestuff.html

我想您会同意，带来这种纪律的努力是非凡的。而且几乎从不需要。

您应该阅读 Fred Brooks 的《人月神话》。他们在计算机科学 101 中让我读了这本书。我很高兴他们这么做了。这是对您的论点的全面论述。我想您会喜欢的。

最后，我不会将开发模型描述为“试验和错误”。这不是一百万只猴子在编写代码。这是一群有缺陷的人，带着不完美的信息尽力而为，就像其他所有开发模型一样。开源的区别在于，该模型期望失败和错误，并提供了一种快速补救它们的方法。在此过程中，它允许来自庞大且流动的利益相关者社区的最佳想法浮出水面——这是自上而下的计划根本无法有效完成的事情。

Avatar
MyRoyFriend | 2010 年 2 月 6 日
还没有读者喜欢这个。

对“错误”的接受非常特定于软件开发。大多数（如果不是全部）其他工程学科都不谈论“错误”，他们谈论的是设计错误。这些错误，错误需要被识别和纠正，否则您就没有完成您的工作。

您不会在没有非常具体的设计标准、规范、误差预算、可能广泛的计算机模拟、PCB 设计等等的情况下设计电子系统。

所有这些都称为工程，它是一门学科，它是获得功能系统的特定方法。
就像硬件一样，您将其设计为在可接受的参数范围内工作，并且当您创建一个可以完成您设定的目标的设备时，您就满足了初始设计规范。

如果在设计阶段，您确定了问题或错误，那就在那时修复它们，构建一个您在其中构建了“错误”的电路是没有意义的。

这适用于软件，软件工程是一门学科，“黑客代码”是一种以临时方式编写代码的方法。

人月神话，我认为表达的概念是，2 个程序员的速度是 1 个程序员开发软件的速度的两倍，这是 *不* 正确的。

同样，对于任何设计，软件或硬件，纠正设计缺陷（软件中的错误）的最佳也是唯一的人应该是最初设计它的人。

如果您的设计有缺陷并且不能一直工作，那么说您是电子工程师是不可接受的。

软件工程师生产不符合规范的产品也是不可接受的。

并且应该有具体的规范，详细的，包括设计计划和时间表。
如果没有，您的项目失败的可能性将接近 100%。

因为您没有仪表或量具来确定您是否已达到规范，因为您没有任何规范。

我是一名嵌入式系统工程师，也是模拟电子工程师，在军事、科学和工业应用的电子和软件开发行业拥有超过 30 年的经验。

我设计嵌入式系统，所以我必须设计“系统”和该系统的组件，包括嵌入式处理器和软件开发。
您没有机会在数千个带有刻录 PROMS 的嵌入式处理器上应用补丁，您必须第一次就 100% 正确。

质量保证，“第一次就把正确的事情做对”。
承认您自己的错误并在发布之前修复它们是工程师的第二天性，这就是他们的工作。错误是失败和尴尬。创建带有错误的设计很容易导致入狱。

正如有人所说，我当然希望 747 喷气式飞机中的软件是“无错误”的。正如我希望我编写的控制大坝闸门的软件 100% 正确一样。
或者我所在的摩天大楼的设计中没有“错误”。
或者桥梁，或任何其他工程学科，软件开发迫切需要更多地关注质量而不是数量。

Avatar
Gunnar Hellekson | 2010 年 2 月 18 日
还没有读者喜欢这个。

您完全正确，有一类软件需要您描述的那种严谨性。但这只是所有正在开发的软件的一个子集。

我同意始终有改进开发人员、加强安全性和可靠性措施的空间等等。但这必须加以平衡。并非所有软件都需要 DO 178B 认证。

Avatar
shanna | 2010 年 3 月 23 日
还没有读者喜欢这个。

我可以看到双方的观点。当软件更接近机器时（例如，如前所述，嵌入式程序）
<ul>失败成本更高/错误容忍度更低</ul>
<ul>预期交互集更低/精确指定的可能性更高</ul>
<ul>用户界面是低优先级/低功能</ul>

当软件更接近人时，其中一些事情会发生转变。
<ul>更高的错误容忍度</ul>
<ul>界面高优先级/高功能</ul>
<ul>交互集很高，意外的交互</ul>

我正在思考的主要观点是，*人们希望如何与软件交互* 与“机器如何与软件交互”非常不同 - 需要不同的模型来指定它是否能满足我的需求。仅仅是因为人们在看到之前不知道他们想要什么。

Avatar
Wanos | 2010 年 2 月 16 日
还没有读者喜欢这个。

当结构工程师设计结构时，它的目的是什么。如果它是桥梁，您可以使用它来跨越鸿沟。如果它是建筑物，它的目的是将东西放入其中并保护它们免受自然因素的影响。
软件，尤其是 FOSS，受制于“真正的”工程师（我的意思是那些与物理世界而不是虚拟世界打交道的人）不必面对的一件事 - 变化。

想象一下尝试设计一辆既是汽车又是船，又是潜艇的汽车，它还必须接受其他外围设备（即机翼）才能飞行。然后添加您需要将发动机更换为电动、混合动力以及微型核反应堆或标准汽油发动机。然后由一个人驾驶它，让他们从 A 点到达 B 点。这就是产品的用途，但它必须允许您以您认为最好的方式来完成此操作。
同样，FOSS 需要在多种环境中的多种类型的硬件上运行。

Roy - 作为一名嵌入式系统设计师，您有多少次需要让代码在“任何”可能的系统上运行？我敢打赌永远不会，因为它违背了嵌入式系统的目的。您需要使其完美地完成其工作，这很好。它具有单一用途，易于定义和设定规则。您按照这些规则工作，并且您有目标等，这些目标使您的产品可以进行基准测试。

我认为，允许测试许多不同类型的系统并快速修复它们的短暂而频繁的发布周期非常有益。在需要时，大多数软件设计师都会在他们可以控制环境的更大程度时使系统“完美”。银行软件是一个想到的例子。

我相信快速原型设计以允许测试是好的，并且我在推出新产品时采用了这一点。测试人员的许多想法都激发了关于我们正在构建的内容的全新思考方式。它们是无价的，更快的周期使我们更容易整合它并将其放回给更多的测试人员。
有趣的是，一旦它达到关键阶段，随着它越来越接近其预期功能，它似乎会变得稍微慢一些。然后将其最终确定为“产品”并标记为稳定。

我们为什么不对建筑物这样做呢？有时我认为我们这样做。看看道路尽头正在翻新的建筑物。它可能在楼下获得一个新的办公区，在楼上获得公寓，但它仍然在执行相同的功能。免受自然因素的侵害。

当然，软件有其用途，但由于它使用语言来完成其任务，因此充满了与与您的配偶交谈相同的困难。您通常会得到正确的结果，但有时您脑海中的想法和说出来的话对您来说有意义，但对她来说却没有。我只是庆幸代码的道歉成本较低。

相关内容

知识共享许可协议本作品根据知识共享署名-相同方式共享 3.0 未本地化许可协议获得许可。
© . All rights reserved.