我能理解进度压力。您想取悦用户，因为它们是公司的生命线。但是，某些更改确实可以使以后的一切变得更容易。不幸的是，我组织中的管理层对这种变化有一种本能的抵制，而这种抵制是如此之强以至于阻碍了长期的改进。

例如，Apple最近为iOS程序引入了自动引用计数。这是对以前必须使用的手动保留/释放调用的重大改进。该代码更易于编写和维护。转换本身可能会导致某些崩溃。但是，一旦解决了这些问题，随机怪异崩溃的数量就可能减少。

我最近向老板提到，我想切换到自动引用计数。他的回答是他想专注于明显的改进。反过来，这种反应很可能是由于他从自己之上所承受的压力所驱动的-也许恰恰是来自首席执行官的压力。

有很多类似的例子。共同点是需要修复某些问题，但是修复的短期成本超过了短期收益，其中“短期”被定义为“未来几周内”。

我应该如何处理这种情况？

编辑：感谢您的答复。让他们来。因为这与我的情况有关，所以我应该明确说明我的经理和CEO都是程序员-尽管CEO现在可能已经忘记了这是什么样子。显然，他们的程序员方面被其他压力所淹没。

你真的是在谈论技术债务。隐喻可能会帮助您的经理。我经常将软件技术债务的影响与在肮脏的厨房里做饭的效果进行比较。如果水槽，柜台和火炉上堆满了脏盘子，并且地板上有垃圾，则用餐时间将更长。但是，准备下一顿饭的最快方法是在混乱中工作。清洁厨房并保持厨房清洁将延迟下一顿饭，但是将改善所有后续饭菜的递送。就像饭厅里的饥饿的人看不到凌乱的厨房，也不知道为什么要在开始做饭之前清理一下，您的管理人员也看不到代码中的混乱。您需要向他们展示混乱，或者表明由于混乱而导致的质量问题和延误。

也许您也可以谈论紧急任务和重要任务。如果重要任务没有完成，那么紧急任务将花费更长的时间，并且花费更多。

您偶然发现了一些困扰着职业生涯各地程序员的东西：该代码需要重构，那里存在体系结构问题，该模块变得难以维护，等等。但是，由于您组织的当前文化，您被迫专注于只能产生直接可见收益的工作。

它再次是经典的《冰山秘密》。秘诀在于，就像一座冰山在水下90％一样，任何开发项目中的大多数也是如此：90％的工作将对最终用户完全不可见。该代码将对最终用户产生影响，但是管理人员无法确定为什么您花了六个小时来重构维护/发布和自动引用调用，而他们看不到任何差异并且一切正常。

您可以就此问题采取一些事实。

• 除非他们自己是程序员，否则管理人员将不会了解“冰山秘密”。
• 这是一个无知而不是恶意的问题。首席执行官想要一个好的产品-他只是不了解一个好的产品所包含的一切。
• 首席执行官（和您的直接上司）并不愚蠢-研究并准备一些事实和具体数据，说明您为什么要花时间在此上以及其他冰山问题。

别忘了-您是公司的一个或多个男人。不是代码人。您正在为对成功或失败具有既得利益的公司开发该产品-您的项目和项目建议应反映这一点。向公司和产品展示您的热情，向您的老板和首席执行官证明您的知识，并向您的老板和首席执行官证明他们应该信任您，并说他们需要工作。向他们展示其将如何为企业增加利润-是通过为产品增加价值（更多人购买副本）还是通过节省时间（在产品出现故障时减少生气的客户）。

你不知道

我认为这个问题以及所有类似的问题都是死胡同。您不能“说服”任何人。如果他们还没有意识到或正在调查这种事情，那么他们很可能不会放弃。而且没有任何数据可以使他们信服。变革必须来自内部。您可以将一匹马带到水里，但不能让他喝水。

我说将您想要的更改烘烤到下一个技术估算中。就像，嘿，我们“必须”升级到Apple引入的这个新框架。不要让不使用ARC成为您的路线图。没有选择。迁移到ARC是唯一的方法。

我之前在这里回答过类似的问题，因此可以将其视为重复。基本上，您不会获得批准进行“重构工作”。制作代码清理器的方法是遵循童子军规则：离开代码清理器时始终要比到达时清理代码清理器。

就像偿还实际债务似乎是一项无法完成的任务（或清理一栋凌乱的房屋）。诀窍是逐步改善它，直到您开始看到“清洁岛”为止。一旦有了巨大的动力，团队中的其他开发人员将开始注意到并最终为这项任务做出贡献。

我建议阅读“叔叔”鲍勃·马丁（Bob Martin）的“ 清洁编码器 ”。编写好的代码是您工作的一部分。您无需征求您的许可就可以做，您只是去做。

与其他此类问题一样，您需要提供管理层可以理解的数字。数字显示了通过实施这些改进可以节省多少时间，将发生多少次“随机怪异崩溃”，等等。使他们相信崩溃对最终用户是可见的，并且为防止崩溃所做的一切都对企业有利。

您也可以尝试在自己的时间（即在工作时间之外）实施这些改进，然后向管理人员展示其好处。只有在管理层不了解您要传达的内容和/或他们不想为您分配时间甚至尝试这样做时，我才会这样做。

祝好运！

提出业务案例

工程师建议经常被忽略的原因有很多。解决几乎所有原因的最佳方法是提出为什么要这样做的商业案例。经典的成本/收益分析。这不仅引起了有说服力的争论，而且还为您的老板们提供了一些可以吸引上司的机会。

• 前期费用是多少？
• 持续成本是多少？
• 预计节省的金钱/时间是多少？它们来自哪里？
• 我们需要多长时间才能看到ROI？

在做业务案例时，您应该始终用数据备份论点。

• 当前，开发将花费多少时间来解决或消除这些问题？
• 您会收到多少与该问题消除或缓解的问题相关的用户投诉？
• 它还会有什么其他好处？

排列数字，使其成为一个粗糙但简单的方程式。这样做将花费X，并使Y公司受益。

注意：如果要实现学术上的好主意过于昂贵，请不要感到惊讶。

这种更改属于重构类别。敏捷的方法是您应该将充足的重构时间整合到您估计的每个故事中，这就是原因。除了工程师之外，没有人会明白为什么要这样做，这没关系，确定正确编码的方法不是您的工作，而是您的。

因此，下次您需要做大量工作时，请确保这些更改是其中的一部分。如果要提供估计，请确保将估计值增加30％以进行重构；如果不提供估计，则只需将重构作为工作的一部分即可。

它可能会使您变慢-嗯，不，这不是看待它的方法，看待它的方法是您当前的速度是一种错觉，本质上是您在上链时的谎言，实际上您应该是因为您知道需要完成这项工作，所以速度稍慢一些。

如果您不使用混凝土作为基础，则可能可以更快地建造房屋-而且它们对客户来说看起来不错，但是-即使客户看不到基础的需要，建造者需要。（这实际上是一个有趣的相似之处，因为事实证明，构建者并不总是做他们知道应该做的事情，因此我们需要通过法律来迫使他们去做，即使我们面对同样的问题，也没有这样的法律来管理软件开发。往往会做出错误的决定...）

您提到自己很幸运，您的经理和首席执行官都是程序员。因此他们可能确实了解什么是技术债务。

您应该通过尝试根据事实解决情况来处理这种情况，这意味着您很可能最终不会做出想要的技术改进（事实可能会令人讨厌）。

您的工作是确保他们了解偿还您承担的任何特定技术债务的成本和收益。他们的工作是确定资源的最佳用途是偿还资源还是做其他事情。

就像不参与代码的人很难看到改进“隐藏”内容的好处一样，程序员可能很难看到可见代码更改的好处，而好处却是在业务领域有所积累时“隐藏”。

如果您的管理层可以向您解释为什么可见功能比付技术债务更值得您花时间，这是很好的，但是，实际上，做出决定并不是您的工作。因此，向您解释这一点对您的业务没有多大帮助，只会让您开心。从某种意义上说，坚持要求他们这样做是不信任他们完成工作。如果您不喜欢他们进行微管理时，您应该了解。

因此，只要您让他们知道所有技术债务的状况以及忽略与偿还债务的成本和收益，就可以完成工作。除非您真的不信任管理层去做，否则您将面临一个更大的问题，这将是另一个要解决的问题。

也许这不是答案，而是基于我犯过的错误的回应。也与我在这里读到的一些哲学不同。

• 不要与程序员最了解的信念相违背。
• 说实话。在进行过程中进行重构，但不要为了自己的目的而撒谎和增加估计。
• 您没有代码。不要进行未经领导批准的工作。
• 您可能对某事是正确的；您可能错了...但是您应该做自己应该做的事情。

但是，一定要遵循改进方面的出色建议。

您显然是为一个尖头的老板（PHB）工作。他不再编程了，如果有的话，他可能真的不是什么好人（尽管他确实喜欢用“ const正确性”和“分段错误”之类的短语，这样，伙计们才知道他已经赢得了自己的荣誉。 ）-这就是他被挑选出来进行管理的方式。

CEO（实际上有Mohawk）喜欢PHB，因为PHB具有功能。他自豪地为每个冲刺展示了一个新的复选框（略有对齐，带有模糊的标签），一个闪闪发光的图标（在Citrix上为8位颜色，但在任何环境下均无法使用）和一种形式（由于比赛条件而随机崩溃）在基于C的定制xml变体中实现的本地数据库中，开发团队中的任何人都不敢碰，因为它是10年前一位守卫的开发传奇人物写的，并且对具有5个字母名称的宏进行了所有操作，无论它们需要5个字母还是不）。

真正做“工作位”的程序员（您知道发生的位，在完成诸如在白板上画圆圈，大喊和吃微型巴滕堡的所有实际工作后不便）知道，在一个理智的系统中，刚刚完成的工作10个人花了10天的时间努力从未维护的丛林中砍伐，包括测试在内，大概需要一到两个人的工作日。但是，要使系统从理智的状态中恢复过来，可能需要6个月的艰苦工作，而几乎没有明显的外部回报。

PHB知道，在6个月内，他可以通过钩子或骗子获得30或40个新功能，以便销售人员（鉴于他们实际销售的产品必须是魔术师）可以用来诱惑新购买和升级。

但是，请给PHB他应得的：没有这些复选框和表格销售可能会停滞不前或下降，竞争对手可能会获得市场份额，这可能比其他选择更糟糕。

我得出的结论是，走出泥潭的唯一出路是在一个新的初创公司中工作，一些人与您分享您应该如何完成软件的愿景，然后顽固地坚持这一理念（我仍在努力到达那里！）

还有其他答案未提及的其他隐藏成本。即，好的工程师倾向于离开所描述的环境类型。最终，任何有野心或重构能力的人都离开了公司，然后事情将变得非常糟糕，可能无法解决。不幸的是，您不能不自夸地告诉您的经理（“我是您最好的程序员之一”）和急躁的混蛋（“如果您不做我想做的事我就会离开”）。但是，请务必在退出面试中提及它，以确保您不会被重新雇用。

你们都是对是非，这就是为什么这些问题会长期存在并产生难感的原因。

上面已经明确说明了原因：管理层以金钱思考；或更具体地说：收入。对于他们而言，有些东西虽然成本高昂，但无法直接吸引客户，却无法增加收入，因此这是一个糟糕的计划。

您的愿景也是正确的：它将对客户有利，但长期而言。与短期计划相比，您的行动将来可能会产生更大的收入。

您不是经理，您也不是直接负责收入的人（我当然认为）。因此，您将他们的问题混在一起（这就是管理的感觉），而您没有专注于您的工作：进一步扩展软件。

所有硬朗，清晰的文字，但这就是大多数由于通讯错误而出现的问题。你们都想要同一件事，但您的短期决策却有所不同。都是因为开发商与经理相比前景不同。

您如何解决这个问题？在许多问题上，您可以很好地交流和理解。这将最有可能集中在客户参与和满意度上。

为了以一种稳定的，面向未来的方法来解决此问题，需要达成共识：测量旧代码中的错误修复成本。测量使用旧软件所需的时间，以及使用新代码库的时间。

为了证明这一点，您可以例如执行以下非常简单的操作：在版本控制中分支该软件。首先执行管理部门想要的操作，然后创建该功能。您可以这样做，但可以达成协议的是您有时间展示不同的方式。然后在新分支中执行相同的操作，但首先解决您要摆脱的问题。然后还开发解决方案。

现在，您拥有相同的解决方案，但完全不同。从中创建一个案例，将解决方案彼此相邻，包括一些管理信息，例如稳定性，所需的代码量以及代码本身。

现在，聚在一起喝杯咖啡，开始看看，不是在争论谁是对的，而是这两个方向对公司的影响。这将创建一个真正有用的会议，而不是更糟糕的讨论，因为这不会产生你们俩都需要的气氛。那不会使您的产品更好。

如果您有代码审查，请创建技术证明，指出应使用ARC改进代码并将其分配给经理。

说服他。向他解释一些您所做的类似技术增强及其对项目的好处的小例子。

您必须以管理层愿意购买的唯一方式出售这些变更：

找到一个令人信服的面向用户的功能，以至于管理人员必须拥有它，但是如果不对代码进行一些低级的改进，就不可能做到。

确保公司将开发重点放在提供客户所认为的增值上是您老板的工作。有两个因素可以改变这种看法：

1. 交付客户请求需要多长时间？
2. 当您说出意愿时，您会送货吗？

大多数人希望您说将需要6周的时间并在5天内交付，而不是说您将在3个月内交付，但需要4周。

具有易于管理和增强的当前代码库，可以使您更快地交付代码并提高可预测性。如果您花费大量时间进行错误修复，则可用于添加新功能的资源将减少。评估花费在修复代码上的资源数量，以及功能部件的准确性。这种确定您当前代码（在老板的指导下）是否花费过多的方法。

让我告诉您一个20亿美元的机会，由于管理层的惯性，差一点就落空了。

我们中有些人有倾听客户声音的意思，这意味着了解客户的需求。他的要求并不总是如此，但是如果您能够与客户进行对话，那么您最终会对他的要求达成共识。（然后，他可以明确地开始要求它。）

话虽如此，了解谁应该与客户进行对话很重要。通常，您需要业务开发人员以及一些主要设计师来完成。如果您有任何竞争，可以期望客户也正在与他们进行对话。

同时，重要的是，开发人员必须保持与自己领域的最新动态，因为如果您不参与竞争，将会产生竞争。

在我们的情况下，我们有一个现有客户，并且有一个基于旧技术的有效产品，客户需要快速升级。他们真正需要的是一个完整的替代产品，但是我们公司的心态是，这将立即迫使我们进入竞争地位，而修改现有产品使我们的客户可以继续与我们合作，而无需法律上使其具有竞争力。我们的管理层认为他们拥有这个市场。问题是他们无法跟上升级请求，因为现有产品结构不够灵活，无法升级。

客户变得不耐烦，开始与竞争者进行对话。我们失去了对该市场的“所有权”，失去了数十亿美元的收入。但是，一旦市场迫使我们进入竞争地位，管理层别无选择，只能倒闭或竞争。（最终成为障碍的大多数人都被解雇了。）我们竞争了，并且能够以最细微的思路重新夺回业务。

我一开始就说这个机会几乎在我们手中溜走了。就我提到的收入来说，我们把生意还回来了。如果我们在一开始就准备好适应客户的顾虑，就不会有任何真正的竞争。

我要提供的要点是：始终尝试保持个人能力的领先地位。始终开发灵活的产品，并可以快速适应客户的需求。如果您为一家不这样认为的公司工作了太长时间，您将会枯萎，并且您的个人动力将会减少。我已经看到了它的发生。

当您出于任何原因有改善产品的想法时，请问自己以下问题：-我认为客户想要的是这吗？我能否根据客户的声音验证我对产品​​开发的想法？我的公司有能力满足客户需求吗？如果是这样，怎么办？-然后，您将有能力就您的产品开发建议进行有说服力的论证。

在所有领域和行业中，企业共同的语言是金钱。您描述的问题不是编程问题：这是业务问题。如果您想对业务主张做出适当回应，则需要以业务语言来构架。这意味着您必须能够提出包括所有成本和收益的替代项目计划。

您需要了解机会成本，ROI（投资回报率）和NPV（净现值）之类的知识。您不需要MBA才能做到这一点，但是您确实需要访问可能不可用的数据，例如人力成本，间接成本和潜在收入。如果您可以明确地说，使用硬数字，一条路径将比另一条路径提供更多的价值，那么您将得到管理层的充分关注。

当我是一个很小的团队的新开发人员时，我在空闲时间做了很多这种改进。我很喜欢它; 晚上和妻子坐在客厅里时，我将登录并尝试一些有趣的新技术。当我成为一名更高级的开发人员，然后成为一个更大的团队的经理时，我的空闲时间消失了。我们要花更多的时间来完成功能和关键修复程序。即使我们都知道这很重要，也很难证明花任何时间从事这项日常家务工作是合理的。

您的老板不需要说明有多么重要，可以降低维护成本，减少未来增长的成本，聘请有才华的开发团队等。如果这样做，您就会遇到大麻烦。但是，他们可能需要的是计划。因为现在我猜测它们在“添加功能”方面有各种各样的计划，时间表，路线图，承诺和压力，这与开发人员团队的一厢情愿和开放性要求竞争。

您可以尝试做的一件事就是制定书面计划。查看您是否可以将其与发行版绑定，或退出新功能的标准。要求“花一些时间来重做参考计数”的请求可能很难让您的老板批准，但是从现在起安排4天的5天时间段可能会更容易。但是，基本上，您基本上会看到已计划并计划了新功能，请尝试模仿它，或在其中添加“引擎盖”部分。

从要求分配给此类东西的5％的时间开始，然后逐渐建立自己的技术路线图优先级，并不断地为它们的业务案例，ROI，风险水平等辩护。很快，您甚至会领会到老板的挑战，因为您很快就会发现比自己有更多时间要做的更多好主意。

祝好运！

这就是为什么您的自动引用计数请求被拒绝的原因：

1. 这不是改善。一旦您拥有比问候世界更大的东西，任何改变都将朝错误的方向发展。大量的重构都不会改变以下事实：如果您需要进行更改，那么它总是会朝错误的方向发展。诀窍是要知道您的更改何时足够重要，以至仍值得承担引发新问题的风险。您的管理层已明确表示，如果最终用户看不到它，则不值得冒险。
2. 引用计数是完全疯狂的功能。您看到一些现有的知名大公司实现了某些功能，然后立即想到您需要相同的功能。好吧，您的代码库很可能与苹果使用的代码完全不同。引用计数可能无法正常工作，或者只是浪费时间。您应该找到一种不需要在代码中到处传播引用计数原语的方法。可能您的重新计价计划需要在代码库中进行数千次修改，而其中大多数修改都是不必要的。只是浪费时间和金钱。
3. 您正在解决错误的问题。管理层通常知道系统中存在什么样的问题。刷新解决方案正在解决的一些无关的内存泄漏问题不是其中之一。关注计算机处理内存的实际问题，而不是某些想象中的问题。
4. 实施它花费的时间太长了。苹果公司比没有多少程序员和一些管理人员的微不足道的团队要大得多。他们只需付出代价就能做出重大改变。如果要花费几百万美元来实现某件事，那就是花生。如果小公司试图做同样的事情，他们将很快耗尽金钱。软件开发已经非常昂贵。增加不必要的成本将无济于事。一个不相关的功能（如内存管理）将打开闸门：在获得批准后，一半的程序员希望实施自己的“改进”。这是永无止境的故事，该公司可能正在做一些有用的事情。

您可以使用以下步骤来解决此问题：

1. 删除功能
2. 找出真正的问题是什么
3. 开始做一些有用的事情
4. 仔细计划时间
5. 了解您的改进如何带来收益
6. 仅选择可带来最多收入的功能
7. 意识到软件开发的编程方面只是整个系统的一小部分-对其进行改进永远都不值得花时间