技术债务_技术责任而不是技术债务

技术债务

我的最后一次–沮丧–发布此行：

“银行以收集次级抵押品的方式收取技术债务”

我一直不喜欢技术债务的隐喻，部分是因为通常使用它的方式与Ward Cunningham最初定义的技术债务不同，部分是因为使用技术债务的人通常对债务有简单的理解，例如信用卡债务（通常避免这种情况）与抵押债务不同（许多读者对此感到非常高兴而无法承担。）

几年前，克里斯·马特斯（Chris Matts）和史蒂夫·弗里曼（Steve Freeman）提出了一个更好的类比： 未对冲的看涨期权 。 尽管从技术上讲，这种隐喻需要一个人才能理解金融市场和期权，但金融界以外的大多数人（以及其中的不少人！）都不熟悉这种概念，因此这个想法陷入困境，因为这种隐喻比难理解得多。它描述的东西。

克里斯和史蒂夫的直觉仍然是正确的，尤其是在金融领域，技术债务的隐喻弊大于利。 对于收集债务的银行家来说是好事……让我解释一下。

对于您和我（个人）来说，债务是我必须偿还的东西，这是对我未来现金流量的呼吁。 对于个人-以及许多非金融公司-债务是负债。 因此，我们宁愿没有它。

但是对于银行来说，债务是一种资产。

银行持有债务，当我贷款​​时，我承诺将来会偿还银行款项。 因此，我的责任是他们的资产。 它是同一枚硬币的两个面。

相反，对于银行家来说，负债就是他们拥有他人的东西，例如我的积蓄。 当我将1000英镑存入我的储蓄帐户时，这对我来说是一种资产，但对银行却是一种负债，因为银行将来需要在某个日期向我支付1000英镑。 （重要的是，我决定该日期，不太可能警告他们。）

银行家想要更多的债务，因为债务是一种资产。 债务是好的。

因此，每次软件工程师对银行家说：“这样做会增加技术债务”，银行家会听到“这样做会增加资产”。

在2000年代发生的问题之一是银行找到了承担更多债务的新方法。 债务以“抵押债务义务”和“分期付款”的技术方式打包，使银行承担更多债务。 一段时间以来，事情进展顺利，银行家们相信他们已经找到了新的赚钱方式。 问题在于这些债务组合非常复杂，实际上如此复杂，以至于许多使用这些工具进行交易的人都不理解它们。

银行也没有风险官。

监管机构也没有。

这听起来很熟悉吗？ 这不是技术债务吗？

接下来发生的事情使情况变得更糟：一些不了解原始工具的结构的人将新工具分散了。 在《 愚人金》中，吉莉安·泰特（Gillian Tett）讲述了最初设计这些债务产品的摩根大通团队如何警告其他银行推出他们认为没有意义的产品。

听起来不熟悉吗？

这听起来不像总工程师告诉船长“她可以拿来，船长”和船长一样吗？ （《星际迷航》是否让指挥官们忽略了工程师的建议？）

银行在这里不是唯一的，但是他们的商业模式使问题更加严重。 甚至在银行业之外，技术债务的隐喻也鼓励“债务思考”，即人们可以从未来借钱以更快地交付某些东西并在以后偿还的想法。 如果我们将此类债务视为抵押贷款，从而可以立即购买资产以换取长期付款计划，则这可能是可行的。

但是，当程序员使用技术债务从未来借款时，它更像是发薪日贷款，很快就会膨胀，并要求我们增加提供贷款的能力（现金流量）。

银行是债务融资业务的一个极端例子。 大多数公司会平衡所承担的债务数量，如果他们需要更多的钱，他们可以借贷或询问股东。 一般而言，将公司从股东那里获得所需资金的一半，从借款中获得一半的资金视为合理。

但是银行没有。

银行可能会从股东那里获得少于其资金10％的资金，而他们会借钱休息。 Anat Admati和Martin Hellwig在《银行家新衣服》中对此进行了详细解释，但基本上非金融公司无法做到这一点，因为该公司破产的风险很高。 但是，银行之所以能够做到这一点，是因为一旦失败，他们就会相信（并经苏格兰皇家银行证明）政府将挽救银行。

换句话说：银行之所以负债累累，是因为如果发生问题，还有其他人会救他们。 （经济学家称之为“道德风险”。）

借贷（增加债务）来提高回报率是一种常见的商业惯例，因此，并非只有银行家认为金融债务是好的，但它们是极端的。

因此，问题是： 银行家是否相信他们可以承担技术债务，因为有人会救他们？

我无法回答这个问题，但显然工程师与银行家对债务的看法不同。 它比简单的无法理解还复杂。

银行IT运行在项目模型上：正如我在#NoProjects中所说的那样，该模型由于目标错位以及将其“完成”的错误观念而鼓励降低质量。 即使银行经理不相信这会“完成”，他们也可以看到参与结束了，他们可能是承包商，或者可能会进行另一个“项目”。

有很多公司，无论是外包商还是工具供应商，他们都很高兴地说他们的服务或工具可以解决问题：

“技术债务太高了？ 远东外包商No.1没问题，我们可以解决它！”

“您是否经历了较长的测试周期？ 然后使用Cyber​​ Tester 3.0，它将比发现的可转换债券更快地发现您的错误并缩短周期”

正如威利·萨顿（Willy Sutton）所说：“我将IT卖给银行，因为那是金钱所在。”

那么有没有解决的办法？

好吧，还有另外一种可能实际上可以提供解决方案的复杂性。

银行业务的另一个方面是时间：银行（其资产）所提供的贷款可以长期（抵押贷款为25年）提供，而银行则无力强制还款。 据说它们缺乏流动性–难以取消现有贷款，因此您不能轻易将已发放的贷款转为现金。

但是，银行接受的存款（其负债）流动性很强。 我可以随时从自动提款机中取出钱，而使银行的钱减少了–曾经想知道为什么银行要支付较高的固定存款利率吗？

有人说，这是银行要解决的问题：将短期流动性存款转变为长期非流动性贷款； 在不同的时间范围内匹配资产和负债。 （Mervyn King在《炼金术的终结》中对此进行了有趣的讨论。）

当我们构建软件系统时，我们正在构建资产。

该系统本身-零售银行系统，交易平台，风险管理系统-是长期投资，已成为主要资产。 最近几十年，但它们缺乏流动性，难以更改系统。 由于难以建立新的零售系统， 苏格兰皇家银行 （RBS）最近中止了分拆业务（英国《金融时报》： 苏格兰皇家银行总裁警告说，今年可能无法出售威廉姆斯和格林 ）。

相反，这些系统中的缺陷（错误）和体系结构不良（通常称为技术债务）是责任。 更重要的是，就像银行的金融负债一样，这些随时可能发生。 我今天可以访问自动提款机，而今天一个未知的错误可能使系统崩溃。 同样，设计欠佳的子系统（例如，系统中有一个单例）可能不会使系统崩溃，但会减慢操作，增强功能等。

当然，这些问题可能不会在今天出现，但它们可能（同样地，我今天可能不会访问自动柜员机提现）也可能会出现。

因此，让我建议我们放弃语言或技术债务。 （或者让技术债务回到Ward的原始含义。）

让我们来谈谈技术责任：

软件中的技术责任是代码的一部分，甚至是整个系统，由于其（较差的）设计而难以更改，显着地阻碍了增强并为失败打下了肥沃的土地。 这样的代码通常缺少单元测试和一致的设计。

这些责任具有很高的流动性，问题随时可能消失，从而阻碍了系统本身的性能或程序员的增强。

建立资产时会产生一些负债。 但，

• a）在建造和建造时有可能将这些责任减至最小
• b）这些负债可以通过投资减少。

减少负债将使资产本身更具价值，并增强资产未来的变化能力。

用“技术责任”代替“技术债务”是我们语言的一个小变化，我们都可以轻松理解，消除了理解不清，易于误解的隐喻。

翻译自: https://www.javacodegeeks.com/2016/11/technical-liabilities-not-technical-debt.html

技术债务