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