每个软件项目都涉及管理一个复杂性预算。
复杂性预算可以定义为：
在整个应用程序中明确或隐式分配的复杂性
这里的"复杂性"是主观定义的（而不是形式化的），并且以斯图尔特式术语："我看到它时就知道它是什么。"
或者，更具体到软件开发："我感觉到它时就知道它是什么。"
应用程序架构师的主要工作之一是管理项目的复杂性预算：
复杂性的一个令人恼火的方面是，试图解决它的尝试实际上可能会增加更多的复杂性。
一个来自经验的好例子是我工作过的一家公司添加了OSGi来管理系统日益增长的复杂性。这似乎是一个合理的方法，它提供了一个复杂的模块系统，由新聘请的架构师推荐，甚至在"什么是OSGI"页面上说：
OSGi显著减少了几乎所有开发方面的复杂性：代码更容易编写和测试，重用性增加，构建系统变得简单得多，部署更易于管理，错误可以早期检测，运行时提供了对正在运行的内容的巨大洞察。
有什么不喜欢的？
不幸的是，将OSGi添加到那个项目中实际上使整个项目陷入停滞：它让我们最好的几个工程师脱离正常的应用程序开发超过一年，当他们完成时，代码库比他们开始时更难处理。已经摇摇欲坠的功能开发速度崩溃了。
这并不是说OSGi普遍不好。但在这种情况下，它没有提高我们开发团队的生产力，而是实际上终结了它。
一个好的软件架构师是能够有效管理项目软件预算的人，无论是明确还是隐式地。
我的感觉（虽然没有确凿证据）是，斯图尔特式应用程序复杂性大致随着应用程序的大小呈几何级数增长。有经验的开发人员适当的分解可以在相当长的时间内抑制这条曲线。
然而，这并不能改变一个事实：在某个地方，潜伏着一堵复杂性墙。
如果你不小心，你会一头撞上它，让你的开发速度陷入停滞。
我有过多次这样的经历：有一天，莫名其妙地，我正在开发的系统从感觉"大但可管理"变成了"这简直无法处理"。
以下是管理复杂性预算的一些工具：
不幸的是，经验表明，管理斯图尔特式复杂性是一项主观的工作，许多有才华和经验丰富的开发人员会在特定决策点上对正确的行动方案产生分歧。
尽管如此，通过在软件项目中明确复杂性预算的概念，这些对话可以更有成效，最终带来更好的软件结果。
几乎所有成熟的应用程序都是复杂的。
发现一个新的代码库"复杂"并不是拆解一切或激进重构的借口。我们必须始终牢记切斯特顿的栅栏。
如果一个应用程序运行良好（甚至只是合理），那么我们应该假设复杂性预算管理得很好（或至少合理）。
我们必须永远记住，不幸的是，在现有的、大型应用程序中解决复杂性的大胆尝试经常失败，或者更糟，使事情变得更糟。