在2011年John D. Cook寫了一篇博客，其中提到：

我的朋友Clift Norris發現了一個基本常數，我稱之為Norris常數，一個未經培訓的程序員在他或她遇到瓶頸之前能寫出的平均代碼量。Clift估計這個值是1500行。超過這個數以后，代碼會變得如此混亂，以至于本人都無法輕而易舉的進行調試和修改。

我還不了解足夠多的初級程序員來驗證這一結果，不過我自己認識到，程序員生涯的下一個瓶頸將發生在20,000行。我把Norris常數改成2,000那樣正好變成十倍。

在我離開大學之后的***份工作中，我和我的同事一樣（和我差不多年紀）反復遇到了20,000行的瓶頸。在夢工廠我們有950個程序給動畫師使用，行數統計顯示多的一些基本在20,000 至25,000行。超過這個數的話即再多的努力也無法增加新特性了。

在1996年年中的時候我負責編寫夢工廠的照明工具（和 另外兩個程序員），我知道這將遠遠超過20,000行代碼。我改變了我的編程方法并且這個工具一年后以大約200,000行的代碼量成功交付。 （這個工具計劃于2013年退役，在16年時間里它被每天使用并用來拍攝了21部電影。）我因為寫了好幾個行數在10萬到20萬的程序，我很確定我遇到了 下一個瓶頸，我已經能夠能感覺到它。

特別難的部分是和一些沒有像你一樣打破了好幾道瓶頸的人討論技術。打破這些瓶頸意味著做出不同的取舍，特別是一些短期內看起來不合理但以后會有所幫 助決定。這很難去爭論，短期內的優點是顯而易見的，但我無法說服任何人說從現在起一年內可能有人會做出一個看似無害但是會破壞現有代碼的改動。

Edsger Dijkstra 在1969年寫道：

一個一歲多的孩子會以一定的速度匍匐前進，比如說每小時一英里。但每小時一千英里的速度就是一架超音速噴氣機。就物體的移動能力而言這兩者是沒有可比性的，任何其中一個可以到的但是另一個不能做到，反之亦然。

一個Clift 所指的初級程序員，學會了爬行，接著蹣跚學步，然后行走，然后慢跑，然后再跑步，***沖刺，他認為，“以這樣加速度前進我可以趕上超音速噴氣機的速度！ “但他跑進了2,000行的極限，因為他的技能不會再按比例增加。他必須改變移動方式，比如開車去獲得更快的速度。然后，他就學會了開車，開始很慢，然后 越來越快，但有進入到了20000行極限。駕駛汽車的技術不會變成開噴氣式飛機。

我的朋友Brad Grantham用新手程序員用“蠻力”解決問題來說明了這一點。我認為這是正確的：當代碼是在2,000行以下，你可以寫任何混亂骯臟的代碼并依靠你的記憶拯救你。深思熟慮的類和包分解會讓你的代規模達到20,000行。

突破這個瓶頸的關鍵是什么？對我而言，就是讓事情保持簡單。除非現在就非常需要，否則完全拒絕添加任何新特性或者新代碼。我已經在Every Line Is a Potential Bug中提高了這一點（在Simple is Good之前還是一知半解）。夢工廠的***特效架構師是這么理解的：

對我而言，照明工具成功的地方在于他選擇了一系列容易使用和維護的小功能并且強大到足夠成為一個非常棒的照明工具。

作為一名技術領導我明白我主要的貢獻是對那些同事覺得非常重要但不能證明其合理的需求說“不”。但真正的訣竅是知道什么需求增加了線性的復雜度（只和自身相關）和指數級復雜度（和別的需求有關聯）。兩者都因該去避免，但后者需要更令人信服的理由。

舉個例子，在2012年，Linux內核有1500萬行代碼。其中75％是具有線性復雜度的（驅動，文件系統和處理器結構相關的代碼）。你可能有許多視屏驅動，但他們之間沒有任何（或很少）的交互。剩下的則有更多的依賴關系。

Dijkstra覺得很難去教授這些先進的方法，因為他們只對那些2萬行或者20萬行的程序才有意義。任何的類或者規范必須限制其示例在幾百行以 內，暴力方法在這里也同樣適用。你真的需要范例給你顯示30,000行代碼然后證實因為程序上手并不是非常復雜所以新功能能夠很容易的被添加。但這實際上 是不可能的。.

我不知道做出什么改變來突破20萬行的瓶頸。我最近已經切換到了更純粹的函數式風格并減少了可變狀態，也許這些能讓我有所突破。

而且我很想知道到代碼量達到2000萬行的時候會變成什么樣子。