某人是否在帮助团队向用户交付有价值的软件？如果他们花了一周时间将程序的内存降低了10%而用户一点也不在乎，那么答案是"否"。 -网友留言

在走上现在走的怪异软件之路之前，我是某toB公司的后端开发人员。主要负责核心Rails应用程序，基础架构之类的东西。我做过一些非常有用的事情和一些蠢事，也知道我不是最好的团队合作者。直到现在我仍然和几个还在那里工作的人是很好的朋友。我本周一直在想一个我之前的项目。由于时间太久远，我对此项目的记忆并不完整，为了叙述而对某些内容进行了调整，因此并不是100％准确。

2016年某天，我接到一个紧急任务：我们的数据科学家的数据库查询没有相应，我需要对此进行调查。我重启了"数据仓库"（运行Postgres的AWS服务器），进行了一些参数调整，然后让数据科学家重新执行查询。

"超时了吗？"

"它仍在运行，但我们还不知道。"

"你什么时候知道？"

"明天。"

平均查询要花一天的时间！

没有人认为这有什么问题。那就是过去的样子。但这深深地困扰着我。我们只有几TB的数据，应该花这么长时间吗？我决定调查一下，看看是否可以花更少的时间。

（当时我的主要动机之一是"内在快乐"。我对服务最终客户的兴趣不高，对服务于内部人员——比如数据科学家——更感兴趣。）

最终，我得出结论，问题出在我们的基础架构。我们不应该在单个Postgres机器上运行，我们应该有一个真正的数据仓库！因为我们部署在AWS上，所以我选择更换为Redshift。我设计了迁移方案和架构，从而可以让每个查询都快很多！然后我将此建议给管理层。

"这对学生有帮助吗？老师？管理员？公司收入？"

"不，这只会使数据科学家更轻松。我认为。 "

CTO把我叫到一边，并解释了最重要的业务规则之一：做能为客户带来价值的事。如果最终用户不在乎，那就不要做。

但是我当时是一个自大的年轻程序员，因此决定继续推进它。我用我所有的空闲时间来改进现有架构。我深入研究了AWS基础架构，学习了如何组织redshift表和使用架构功能。我自学了如何使用窗口函数和CTE优化查询。

中途有其他同事看了一下超时问题，并在一小时内解决了这个问题。 Postgres数据库位于RDS实例上。他增大了RDS实例的性能和磁盘空间。问题解决了。数据科学家再次感到高兴。

但是我不开心，所以我继续工作。我建立了所有基础架构，并将事件日志迁移到该基础架构。我花了几天时间调整数据库，设置排序键并运行测试。开始一两个月后，我自豪地将其投入生产。通过测试和无数汗水，我获得了超过1000倍的加速！过去需要一天时间的查询不到两分钟即可完成。

在大多数情况下，这个故事结局应该是一个让我了解我多么幼稚的反例。但是这次不是。每个人都喜欢它。数据科学家可以随时进行迭代查询。销售人员可以运行临时查询并获得有用的结果。工程师发现新系统更稳定，更易于修改。而且使用适当的数据仓库每年可以为我们节省6万美元。会计师当然喜欢这一点。直到他们第一次使用，没人知道他们想要这个真正的数据仓库。

没错，客户比我们更了解他们的大多数需求。但是他们并不比我们更了解所有需求。他们是领域专家，但我们也是领域专家。他们可能没有意识到，如果我们的产品更快，更安全，更稳定，他们会感到多么幸福。他们看不到我们所做的内部工作如何对下游产生影响，从而使我们更轻松地更好地帮助他们。因为他们不像我们这样精通软件工程，所以他们不知道我们能做些什么来使事情变得更好。他们可能甚至还没有意识到这会变得更好，直到我们改善了一切。

这并不是说我们所有或大部分想法都应该付诸实行。我们仍然不是客户，我们不应该以为我们比他们还了解他们的需求。然而这个项目取得了惊人的成功。还有一起其它类似成功的例子，于是我确信人们并不知道他们真正需要什么。同时我也有很多失败的例子，有些项目我希望可以做得更好，做出改变，结果证明是错误的。总之这并不容易！这就好像一个钟摆。我们在两端之间移动——先是认为我们比客户了解更多，然后认为他们比我们了解更多。我们和客户都无法完全了解真正的需求，但是我们可以一起迭代和确认真正的需求——客户想要的并不总是客户需要的。