ACM通信

---

媚兰其实

2013年10月16日01:40

我可以想象人们对故意拖延的建议会有多么愤怒和反对!开发人员会知道这些延迟被设置了吗?他们真的会使用这些延迟吗
仔细想想眼前的问题?我认为这个话题很吸引人，我提出了一个不同的解决方案。我的建议是，需要引入的“延迟”应该以自动检查工具在后台运行的形式出现。每隔一段时间，应该提醒开发人员检查的结果。发现了特定的pclint错误，或者某些模块超出了可接受的McCabe复杂度或嵌套级别，或者无论选择的编码违反可能是什么)。这种形式的“延迟”实际上利用了计算能力，而不仅仅是让计算机“等待”开发人员“思考”。此外，我认为如果程序员知道他们将面对检查结果，他们将不得不在继续工作之前花时间修正，那么他们就可以更聪明地工作。该解决方案的良好实现实际上可能等同于更快=更快!

---

菲利普盔甲

2013年10月16日07:30

这真是个好主意，它利用了延迟而不是简单地延迟。

有相当多的证据表明，我们真正的创新思维发生在空闲时间——当我们不“工作”的时候，但对延迟的任何反应都会在某种程度上抵消好处。

此外，我还记得在20世纪80年代在运行在“TSO”下的IBM大型机上工作时，它通常会有非常恼人的延迟。每个VT终端交互可能需要2-30秒来响应一个简单的键输入。延迟的持续时间不允许任何其他工作(甚至思考)发生，而响应时间的不确定性阻止了您离开。所以可能有一些延迟的特征是有效的，也有一些是无效的。它可能被更好地称为“批处理模式”处理，其中有一段时间的活动，然后是一段时间的不活动(思考发生的时候)，而不是“延迟”，这可能只是意味着做事情更慢。

项目团队可以很容易地建立一个工作计划或节奏来实现这一点，而不需要插入人为的慢下来。值得思考。

---

格雷格·欧文

2013年11月6日02:16

伟大的文章。很难让开发人员思考，因为他们认为自己不需要思考。当客户听说你应该能够在一夜之间构建一个新系统，任何系统时，很难让他们相信思考是重要的。只需抓取一些JS框架，启动一些虚拟服务器，然后使用MySQL。

部分问题在于工具和语言不鼓励思考。我们在自己的项目中遇到的死胡同是行业大规模范例的本地版本。

朱特拉斯女士的建议指出了我们的一个主要问题，复杂性。我们需要教会人们在每一个转折点上都与复杂性作斗争。

当我看到关于PLAN的说明时，我想到了Logo和“playing turtle”。当我看到你关于制作游戏的笑话时，这让我想起我曾经看过一个游戏:http://www.kickstarter.com/projects/danshapiro/robot-turtles-the-board-game-for-little-programmer?ref=search

我和它没有任何关系，但看起来有些极客想用这种方式教育他们的孩子。

---

艾伦·莱斯利

2013年11月15日03:03

好文章!我想我来自类似的背景，除了我在1967年加入伦敦普特尼的ICL之前，在一台使用PLAN汇编程序的1900计算机上，在一台Univac 1108超级计算机上从事光笔图形开发工作，尽管是在汇编程序级别，甚至有鼓式存储，我被糟蹋得一塌糊涂。这当然是一种减速。从那以后，我使用了各种各样的机器，包括许多微处理器，现在是Arduino，当然很欣赏响应性环境，但我不禁想到，有一种新的人群正在进入Phillip Armour图表中的红色部分，他们使用了当前的Sprint方法趋势。

即使存在一个两级Git源代码控制系统，它要求在第二级将更改的代码放入全局项目空间之前通过代码测试，也不会真正阻止验证“某些东西正在运行”，这与验证它做了一些有用的事情是不同的。

也许，作为一个有用的减速，所需要的只是在向系统引入更改的第一和第二阶段之间进行代码演练。

菲利普，谢谢你的精彩文章。也许我在1967年到1970年间在伦敦见过你!