当您身处开源领域，您的错误将近乎永恒

当您拥有一家初创公司时，您会经常进行自我搜索。 这并非出于人们进行自我搜索的通常原因（实际上，每次我这样做时，我内心深处残留的朋克青春期的一些东西都会逐渐消亡）。 而是出于公关公司进行自我搜索的原因。 为了非正式地报告您为公司造势的有效程度。 在这个过程中，我发现了这份愿景文档，它解释了为什么我们（我和 Marcus Johnson）要创建一个最终成为 POI 的项目，该项目托管在 Apache。 我很好奇，所以我 查看了 四周。 在我看来，这似乎是一门关于以错误方式开发软件的课程。我主要是在三年级时自学编程，之前在现已关闭的 Howey in the Hills 天才儿童中心接受了短暂的入门介绍，该中心是县里用来处理所有旧电脑（TRS-80、Apple-II 和 IIIs）的地方。 直到后来我开始上大学课程，我才学会以“错误的方式”编写软件。

错误的方式涉及“预先大型设计”，它假设您可以在开始编码之前学习和研究所有内容。 我花了好几年才摒弃这种方法。 我曾在多家公司工作过，这些公司使用了这种方法，这种方法在 1970 年被 Royce 证伪，并在 1975 年被 《人月神话》 部分证伪。 他们称之为“系统开发生命周期”，将其画成一个圆圈，并避免称其为 瀑布模型。 这些方法误解了软件开发，认为它就像建造建筑物或物理实体。 我注意到我在这些大公司参与的大多数项目都是“政治上的成功”。 也就是说，它们完全惨败，但除了那些无意这样做的人手中之外，没有真正有效的方法来衡量失败，它们却被誉为成功。 当您用毫无意义的流程文档淹没人们时，没有人会注意到您未能实现愿景文档中的任何目标。 由于我的观察，我开始摒弃这种糟糕的方式，尝试接受“迭代”完成的想法，但后来掌握了各种 敏捷方法 来开发软件。

具有讽刺意味的是，当我开始 POI 项目时，我正处于两者之间。 直到今天，我仍然在项目开始时编写各种正式或非正式的愿景文档。 关键是要有一些开发人员（更不用说付费方）可以阅读的东西，并且至少知道他正在从事什么项目以及为什么从事该项目——就我们所知。 然而，POI 愿景文档的重点是一个现已废弃的 Cocoon Serializer，将其作为项目的重点。 幸运的是，主要是 Stefano Mazzocchi 博士 阻止了我这样做。 我们将项目拆分为 XML 部分（我后来才发现，实际上有一些人使用了它，但从未发声）和 API 部分（在世界各地的金融机构、政府、核电站 [gulp] 甚至后来的美国国土安全部 [gulp gulp] 中得到了大规模采用）。 想象一下，如果我们在我们真正了解大多数人将如何使用 POI 之前，浪费大量时间为该部分进行预先大型设计，会发生什么？

拥有那个愿景对于启动项目非常有用，但愿景本身很糟糕。 关于开源和互联网，不幸的是，我的罪过在档案中留存下来，供所有人查看（尤其是在我学会如何 *不* 通过电子邮件沟通之前）。 幸运的是，我可以警告 阿尔伯塔大学 “ece521” 的学生，他们应该只付出足以通过考试的必要注意力，然后将一切都忘掉。 然后拿起 《程序员修炼之道》 或 这本书（即使您不做结对编程）。 然后加入一个开源项目，编写一些单元测试，修复一些错误并实现一两个功能。 最后，忽略所有人对开源的看法，就像糟糕的商业模式（在互联网上销售不太吸引人的广告）使 公司盈利 一样，较少的预先设计可以做出更好的软件（这并不意味着没有设计）。