ACM通信
软件报价和计数器报价
在软件工作中，有一些特定的短语和主题被重复。我经常遇到一些特别有问题的，所以我把它们分类了，我还收集了一些反引用，作为现场治疗和预防未来不良思维的疫苗。
光与热
- “在任何做决定的时刻，你能做的最好的事情是正确的，次好的事情是错误的，而你能做的最坏的事情是什么都不做。”
- 这是美国第26任总统泰迪·罗斯福的作品
泰迪·罗斯福被认为建立了国家公园系统，这是一个不小的成就，直到今天仍有数百万美国人在使用。他在担任总统期间曾短暂学习过柔道——无疑是第一个，也可能是最后一个学习柔道的总统。他开始修建巴拿马运河。尽管他支持商业，但他是一个反托拉斯者。他是一个帝国主义者，但他基本上克服了这一点，至少在执政期间没有发动任何战争。他是出了名的精力充沛。虽然大多数软件领导者通常不会直接引用罗斯福的话，但他们可能会误用上面的这句话，强调他的“忙碌”，并假设他同样有效。快点!赶快!诀窍在于，罗斯福博览群书，是一位多产的作家，可以说，他比他那个时代的大多数人都更善于在忙碌中做出“正确的事情”决定。 Most people aren't that adept and should take the time to stop and think, especially when making big decisions. Doing "nothing" at a certain point in time might be a better option than blowing something up accidentally.
- “这是飞行控制的第一条规则。如果你不知道该做什么，那就什么都不要做!”
- NASA太空任务小组飞行主任Gene Krantz失败不是一个选项, pg 32。
Gene Krantz并不是提倡不作为，而是提倡反对“随机”行动。对问题进行研究，选择一条路径，记录它，测试它，如果这个路径成立，那么就实现它。否则，就回到开头。在任何情况下，都不要急于通过任务控制中心的开关，希望好事会自然而然地发生。这同样适用于今天的任何生产软件环境。软件领导者经常不仅错过编写问题研究的纪律和严洁性，而且经常在预算、测试环境和有效测试的时间上失败。不能充分地测试变化——无论是功能上的还是技术上的(例如，规模或性能)——应该吓到任何人。提前计划。
主动与被动
- “我们应该成立一支特警队，然后……”
- 和我一起工作过的很多人。
我已经记不清有多少次听到人们这么说了，这句话通常是在某物着火或即将燃烧时说的。解决问题和响应紧急情况是很好的，有时需要快速插入一些激烈的编码。但“特警”要求的精神往往是短期的，没有后续解决根本原因。类似地，被提议的团队的成员可能正在做其他的事情，或者被要求加班加点。“我们应该举办一场黑客马拉松，而且……”也属于同样的范畴。
- “赢得战争的不是特种部队，而是军队。”
- 跟我一起工作过的一个前以色列突击队队员告诉我的。
我的同事并不是在反对特种行动本身，而是在反对对特种行动的过度依赖。他强调了容易被忽视的活动的重要性，如运输部队、食物、住所和其他物资;维持通讯网络，治疗伤员，建立防御周长，收集情报，并试图与盟国建立关系。简而言之，那些看起来没有踢门那么刺激的东西，但仍然是复杂的，支持持续的努力和进步。如果你的软件想要拥有用户和市场份额，它需要能够占领并保持它，而不是在第一次发布后耗尽团队。配备适当人员的DevOps和SRE团队是关键技术支持活动的一个例子，他们可以和产品本身一样重要——特别是在第一时间防止事情出错，并有足够的日志记录、度量收集和在出错时进行监控。
我们到了吗?
- “我们需要一个MVP。”
- 和我一起工作过的很多人。
说到在第一个版本发布后精疲力尽，“mvp”是软件开发中最常被引用和错误引用的方面之一。无论采用何种开发方法，发布一个满足市场需求的版本是完全合理的，它充满了代表最小可行产品的功能。但我已经见过太多的例子，其中MVP有效地成为最终状态，因为在第一次发布之后，对工作的资助或兴趣消失了。“我们做的还不够多吗?”但mvp应该是一个开始，而不是结束。
- “如果你的框架成功了，你就永远不会结束。”
- 我在几年前的Strata Data会议上听到了这个消息。我想这是Netflix的一个演示。
成功的软件工作由拥有用户和前进动力来定义。如果用户喜欢他们所看到的内容，他们便会要求更多内容;如果有前进的动力，他们就会得到它。如果用户喜欢他们得到的东西，他们就会继续使用。如此循环往复。正如我在ACM博客中所写的安娜·卡列尼娜谈软件开发“不管采用什么软件方法，所有成功的软件工作都有一些共同的特征，也不缺少使它们偏离轨道的方法。愉快的软件工作都是一样的，不愉快的软件工作各有各的不愉快。
极品飞车
- “我们需要它是因为性能原因。”
- 和我一起工作过的很多人。
性能问题是任何软件解决方案中的一个因素，瓶颈总是存在的——它们只是随着时间和地点的变化而变化。但是在进行任何与性能相关的更改之前，团队应该首先获得性能数据，而且是大量的数据。人们很容易相信某件事就是“问题所在”，然后才发现它只是一个阴影或背景噪音。以直觉开始研究并没有错，但这不能成为完整的分析。投资于性能监视和工具，以便这些信息定期提供给团队进行增量改进，而不仅仅是在紧急情况下。
- “我们应该忘记小效率，在97%的情况下，过早的优化是万恶之源。”
- Don Knuth，《计算机编程的艺术》，第一卷
软件在计算机上运行，但由人类编写和维护，而人类的混淆是一个昂贵的问题。由困惑的人编写的令人困惑的优化软件甚至更加昂贵。
另请参阅
关于软件工作中的决策，我的帖子在遗憾的设计艺术．
参考文献
“决定”这句话是由于但可能是杜撰的。
道格·梅尔是onada公司的投资组合架构师。他还创立了克利夫兰大数据聚会在2010年。更多Doug的ACM文章可以在这里找到https://www.linkedin.com/pulse/publications-doug-meil
没有发现记录