与复杂性作斗争是软件开发中经常出现的主题，我已经看到过一遍又一遍在各个级别上争论不休：在函数和方法中应该进行多少注释？理想的抽象量是多少？框架什么时候开始具有“太多的魔力”？组织中什么时候出现太多语言？
我们试图摆脱复杂性，控制它，并寻求简单性。我认为这种逃避复杂性的方式进行构架是错误的。复杂性必须生活在某个地方。
弹性工程学告诉我的一件事是控制论中的“需要多样性”的概念：只有复杂性才能处理复杂性。
使用构建工具时，一些事情变得显而易见：
- 如果简化构建工具，它将无法处理存在的所有奇怪的边缘情况
- 如果要处理奇怪的情况，则需要偏离要建立的任何规范
- 如果您想简化通用默认设置的使用，则通用默认规则必须在工具和用户之间共享，这些用户可以调整他们的系统以适应该工具的期望
- 如果允许配置或脚本，则可以为用户提供一种方法，以指定必须共享的规则，因此该工具适合他们的系统
- 如果您想保持该工具的简单性，则必须强制用户仅在适合该简单性的参数内播放
- 如果用户的用例不能很好地映射到您的简单性，他们将围绕您的工具建立填充以实现其目标
这是无法避免的。复杂性必须生活在某个地方。无论您是否意识到，解决问题始终是人们解决问题的一部分。
不幸的是，如果我们到达上述列表的最后一点（我们总是以某种方式这样做），复杂性不会处于休眠状态。它是每个人的学习经历的一部分，他们会适应它。
他们解决了这个问题，看到了两个冲突概念之间的不匹配。必要的复杂性可能会四处移动-回到工具（或新工具）中，或者通过重新组织事物来消除。每个这样的更改都需要付出努力和更多的调整，并且人们可以看到复杂性，了解复杂性并解决复杂性。在某些情况下，更改不会简化事情，而是会在各个人的假设之间造成新的不匹配，从而使事情复杂化，这将需要新的调整。偶然的复杂性只是表明其年龄的基本复杂性。它是不可避免的，并且一直在变化。复杂性必须生活在某个地方。
在设计心理学，唐·诺曼提到“在头脑知识”和“知识世界”的概念（类似于概念更学术的Roesler＆Woods的呈现设计的专业知识）。头脑中的知识是您知道的，已经学习的，记忆中的东西。知识就是一切：记下来的信息，设计线索（您可以通过查看电源按钮的符号来了解电源按钮，并且知道它可以像按钮一样被按下）。一个棘手的事情是，世界上对知识的解释既是文化的又是上下文的，并且依赖于头脑中的知识（您知道可以按下电源按钮，因为您首先知道按钮是什么）。
在某些方面，专业知识正在您的脑海中积累知识，使您可以更好地阅读世界。
我们在软件设计中的一个常见陷阱来自关注于我们如何以“简单”的方式读取和解释给定的代码。专注于简单性充满了危险，因为复杂性无法消除：它可以转移。如果将其从代码中移出，它将流向何处？
设计Rebar3时，我们觉得该工具可能很简单。其简单性的条件是您对Erlang / OTP项目的预期结构有基本的了解。只要遵守这些规则，一切都会顺利进行。我们将一些复杂性外部化为更广泛的生态系统。规则总是需要学习的（因此我们假设），但是工具现在取决于对规则的理解。在为了解规则的人简化工具使用时，我们使仍在学习规则的人变得更加困难。其他生态系统中用于其他目的的其他工具都在进行类似的权衡。
陷阱在软件体系结构和架构中是隐蔽的。当我们采用微服务之类的东西时，我们会尝试使之微不足道，以便每个服务都变得简单。但是，除非这种简单性如此之大，以至于您的实际应用程序继承了它并被迫简化为简单性，否则它仍然必须走到某个地方。如果不在单个微服务中，那么它在哪里？
复杂性必须生活在某个地方。如果幸运的话，它可以住在定义明确的地方。在您决定应该增加一些复杂性的代码中，在支持该代码的文档中以及在为工程师提供的培训课程中。您为它提供了一个位置，而没有试图将其全部隐藏。您创建管理它的方法。您知道在需要时可以去哪里见面。如果您不走运，并且您只是假装可以完全避免复杂性，那么这个世界就无处可去。但是它仍然不会停止存在。
它无处可去，它必须在您的系统中漫游，无论是在代码中还是在人们的脑海中。随着人们四处走走和离开，我们对此的理解逐渐减弱。
复杂性必须生活在某个地方。如果您接受它，请给它应有的位置，在知道它存在的情况下设计系统和组织，并专注于适应，它可能会成为一种优势。