使用系统不仅仅是编写代码，它是主动知识的生成。 在这篇文章中，Michael Feathers描述了这个概念，以及如何使用它来影响组织决策：
就其核心而言，软件开发是一个知识生成过程。当我们思考这到底意味着什么时会发生什么？
关于软件开发，有许多不同的观点。我们的观点往往取决于我们的角色和有利位置。通常情况下，开发人员专注于代码和架构。经理和团队领导关注的是项目和人员。对于其他角色来说，过程和产品的观点是主要的。
这种观点的多样性似乎没有什么问题。我们完成了我们的工作，通过软件传递价值。
然而，由于我们没有一个统一的视角，管理大型复杂系统的许多方面都被忽视了。
我想提供一个我把它称为知识激活的观点。
我将通过一个例子轻松地进行解释：
想象一下，你是一个有五个人的开发团队。你的一个团队成员去度假了几个星期。这个假期的影响取决于团队如何组织其工作。如果团队中的人实行结对或聚众编程，可能不会有太大的影响。现有系统的知识和即将到来的工作是在整个团队中共享的。
敏捷软件开发中最重要的举措之一是找到处理经典上被称为总线因素的做法。它解决的问题是：一个团队可以失去多少人而不使工作陷入停顿？结对编程和暴徒编程是处理这个问题的两种方法，但还有许多其他的方法：回顾、文档、共享工作空间，等等。所有这些做法都是有效的，但值得考虑的是，我们是否已经足够仔细地研究了问题背后的现象。我们是否对软件开发中的知识进行了研究，并对它是什么以及它的品质建立了一个模型？
知识是一种东西
非常宽泛地说，我们可以把知识想象成一个数量。我们可能无法测量它，但我们知道一些关于它的事情。其一是，除非我们采取行动，否则它将随着时间的推移而恶化。
在团队编写代码时，业务知识掌握有一个快速的上升过程，而之后的下降过程要长得多。坡度下降只是由于记忆的原因。随着时间的推移，我们会忘记这些工作的细节。我们继续做其他事情；也许一个团队成员离开了。
当团队不得不通过重构或额外的功能工作触及旧代码时时，我们对该领域的知识量就会增加。围绕该类的知识被激活。
关于这个过程，有几种思考方式。一种是，团队正在重新发现关于该类的知识。另一种是再生知识；我更喜欢这种说法。我们从代码和其他系统工件以及彼此之间的对话和调查中再生出知识。
同样，我们不能精确地确定在这个过程中激活的知识量，但它比我们开始在那个阶段工作之前的知识量要多。密切的工作在社会技术系统中激活并产生了知识。
主动知识的特质
当我们认真对待主动知识的概念时，我们可以看到它有一些影响我们如何管理它和围绕它发展实践的特质。
主动知识是在与一个系统的互动中产生的。我们通过阅读或讨论获得知识，但与之合作是理解某种事物的最佳方式。工作能调动阅读和讨论所不能触及的思维部分。它能增强记忆和注意力。
知识会随着时间的推移而消逝。
当我们转向其他工作时，我们对旧工作的知识就会逐渐消失。有时我们有清晰的记忆，但当我们在工作环境中没有被提醒时，重要的细节就会从我们的记忆中消失。这种消退不仅发生在个人层面，也发生在团队和组织层面。如果一个人离开了一个团队，那么这个人所拥有的那部分积极的知识，如果不是通过分享工作产生的，那么实际上已经消失了。
知识会变质。
主动知识是准确的知识。如果你一周前在系统的一部分工作过，后来人们在你不知道的情况下对其进行了修改，那么团队中的活跃知识就会减少。你所拥有的知识已经变质了。是的，你团队中的一些人有了当前的理解，但这种理解并没有完全分布在团队中。陈旧的知识在一个组织中是有问题的--使用不准确的信息工作的人往往会重复工作或以适得其反的方式改变系统。
如果工件是清晰易懂的，那么知识就更容易再生了。
代码、构建脚本和文档是外部化的知识。它们是不存在于我们头脑中的部分。我们很容易高估这些人工制品的价值。它们很少是完整的，而且可能变得陈旧，但它们常常构成知识再生的基础。当我们想学习更多的东西时，我们就会回到这些东西上。
被发现的知识可以提高决策水平。
只要我们在一个系统中工作，知识就会被激活。当我们意识到这一点时，我们可以选择在一个系统的不同领域工作，以获得背景并更全面地了解它。通常情况下，我们学到的东西会让我们意识到新功能的潜力，或者让我们意识到增加我们计划中的功能的更简单方法。
当我们把所有这些品质放在一起看时，最重要的是要意识到，知识管理不应该集中在保存和存储上。相反，它应该专注于生成和流动。随着时间的推移，知识会消散，人们也会从一个地方转移到另一个地方。我们需要专注于发展帮助我们快速获取和按需生成知识的实践，以支持我们在系统中所做的宝贵工作。