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