每個軟體專案都涉及到管理複雜度預算。
複雜度預算可以定義為：
在整個應用程式中，明確或隱含地分配的複雜度。
這裡的「複雜度」是主觀定義的（而不是正式地），並且用史都華式術語來說：「我看到就知道」。
或者，更具體地說，在軟體開發中：「我感覺到就知道」。
應用程式架構師的主要職責之一是管理專案的複雜度預算。
複雜度令人惱火的一個方面是，試圖解決複雜度的嘗試實際上可能會增加更多的複雜度。
一個很好的經驗例子是，我曾經工作過的一家公司為了管理專案日益增加的複雜度，將OSGi 加入到系統中。這似乎是一個合理的方法，它提供了一個複雜的模組系統，是新聘的架構師推薦的，甚至在「什麼是 OSGI」頁面上說：
OSGi 大幅降低了開發的幾乎所有方面的複雜性：程式碼更容易編寫和測試、重複使用率提高、建置系統變得更加簡單、部署更易於管理、早期發現錯誤，並且執行時可以深入了解正在運行的內容。
有什麼不好的呢？
不幸的是，將 OSGi 加入到那個專案中實際上使整個專案停頓：它讓幾個我們最好的工程師脫離正常的應用程式開發一年多，當他們完成時，程式碼庫比他們開始時更難使用。已經搖搖欲墜的功能開發速度也崩潰了。
這並不是說 OSGi 本質上是不好的。但是，在這種情況下，它並沒有提高我們開發團隊的生產力，反而有效地結束了它。
一個好的軟體架構師是能夠有效地管理其專案軟體預算的人，無論是明確地還是隱含地。
我的感覺，雖然沒有確鑿的證據，但史都華式的應用程式複雜度會隨著應用程式的大小而大致成幾何級數增長。經驗豐富的開發人員進行適當的分解可以在相當長的時間內將此曲線保持在較低水平。
但是，這並沒有改變一個事實，那就是，在某個地方，潛伏著一面複雜度牆。
而且，如果你不小心，你會一頭撞上它，並使你的開發速度停頓。
我經歷過多次這種情況：有一天，不知何故，我正在開發的系統上的開發從感覺「很大，但可管理」變為「這不可能處理」。
以下是一些管理複雜度預算的工具：
不幸的是，經驗表明，管理史都華式的複雜度是一項主觀的嘗試，許多才華橫溢且經驗豐富的開發人員在給定的決策點上會對正確的行動方案持不同意見。
儘管如此，透過在你的軟體專案中明確複雜度預算的概念，這些對話可以更有效率，並最終帶來更好的軟體成果。
幾乎所有成熟的應用程式都是複雜的。
發現新的程式碼庫「複雜」並不是拆除所有東西或積極重構的藉口。我們必須始終牢記卻斯特頓的籬笆。
如果應用程式運行良好（甚至還算合理），那麼我們應該假設複雜度預算得到了很好的管理（或至少還算合理）。
我們必須始終記住，令人遺憾的是，在現有的大型應用程式中，解決複雜度的大規模嘗試往往會失敗，或者更可悲的是，會使情況變得更糟。