……我能够雇佣几位经验丰富的工程师开始对单体架构进行下一轮改进。我们需要为基于容器和云的未来做好准备，因为我们的客户正朝着这个方向发展。创始人不断抱怨，他无法接受我们在做客户看不到的事情。我花了很多时间协商，争取核心设计变更的总速度的一定比例。我们其余的时间和精力将专注于客户要求的事情，以及创始人认为我们应该专注的事情。我们已经将速度提高了2000%。他想要4000%。我们需要为后端重新部署安排冲刺。当创始人听到我们在讨论重构后端的某些东西，比如部署脚本和数据架构时，他明显很生气。资深工程师给他一本《大教堂与集市》，只是想分享一些能带来共同词汇的东西。创始人周末在自己的书上做了很多批注，周一他坚决宣布完全拒绝这本书的内容。……
源讨论哪些因素解释了软件的本质？原帖 91 条评论 · 导入时统计把你的经验，加入这段讨论。
“把驴放到驴的主人想让你放的地方”——埃及谚语 我不知道这家公司赚了多少钱，为什么不能在后端和面向客户沟通上同时投资 但另一方面，以客户为中心并持续交付面向客户的功能，可能是保持收入流的关键 换句话说，我过去总是站在开发人员这边，但随着时间的推移，我开始更同情客户。我曾处于过开发人员高估了更清晰架构价值的情况。这是一家金融服务公司，不是软件公司。我认为真正的解决方案是完全将软件开发外包
完整原文《CatB》是一本好书。这感觉像是对情况的一种很好的选择，除了看看这个人是否愿意接受软件中的想法之外。 我想知道大家会推荐哪些书籍给非开发人员，以获得一些见解。 我想到的有《人月神话》、《人件》、格拉斯的《软件工程的真相与谬误》，或者甚至1968年的软件工程北约报告。
完整原文我发现微软在其良好架构中的五个支柱是对非技术人员解释这一点的一种有用方式。 在项目开始时，专注于功能是合理的。但随着项目的发展，如果不解决非功能性问题，这些可能会破坏商业模式。 - 可靠性 - 安全性 - 成本优化 - 性能效率 - 运营卓越 前四个直接影响客户。有缺陷或不安全的软件，或过高的成本，都会直接影响客户。 第五点是关于DevOps，确保我们能够持续（作为一个流程）在所有这些方面满足客户的需求。 我发现如果我能将重构归入这五个支柱之一，就更容易向非技术人员解释。当然，有些人就是无法被帮助，他们不接受软件项目的新思维方式。
完整原文我认为这是高级工程师的一个好决定。部分原因是我做过类似的事情，我想相信这是正确的事情。 这改变了什么吗？创始人是否设法继续推进？
完整原文这对每个人都有利。创始人得到了他的文化所要构建的东西。客户更快地获得了他们的功能。高级工程师显然知道这里不是他的位置，于是离开了。每个人都赢了。
完整原文这样的领导者的企业不应该被自由市场淘汰吗？他们应该被更快、更灵活的竞争对手淹没才对？ 但遗憾的是，似乎惯性让一些相当无知的组织持续运作了几十年。
完整原文在这种情况下，隐瞒所有的技术改进，只展示客户面前的交付速度提升，是否合乎道德呢？ 看起来每个人都会更开心。
完整原文这让我想起了一档装修节目中的房主，当工人在施工中途发现结构缺陷时，他们解释这意味着现在预算中没有那么多钱来添加额外的设施。 这个故事中的老板相当于要求不解决结构问题，以保持预算中的大理石台面，然后一年后房子就会坍塌。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。