在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萬行的時候會變成什麼樣子。
在三百萬到四百萬行程式碼左右似乎有一道無形的牆，無論多少人（數以百計）或多少年（數十年）花在上面增長率將會顯著降低。－Dan Wexler