2011年，JohnD.Cook写了一篇博客，其中提到：我的朋友CliftNorris发现了一个基本常数，我称之为诺里斯常数。受过训练的程序员在遇到瓶颈之前可以编写的平均代码量。Clift估计此值为1500行。超过这个数后，代码会变得很混乱，无法轻易调试和修改。我认识的初级程序员还不够多，无法对此进行测试，但我自己认识到，程序员职业生涯的下一个瓶颈将是20,000行。我将Norris常数更改为2,000，正好是原来的十倍。在我大学毕业后的第一份工作中，我和我的同事（与我年龄相仿）多次遇到20,000行的瓶颈。在梦工厂，我们有950个程序供动画师使用，行数显示一些较大的程序大约有20,000到25,000行。超出这个数字再多的努力也无法添加新功能。1996年年中，我受命编写DreamWorks的照明工具（与另外两名程序员一起），我知道这将超过20,000行代码。我改变了我的编程方法，一年后该工具以大约200,000行代码成功交付。（该工具计划于2013年退役，它每天使用16年，用于拍摄21部电影。）我写过几个100,000到200,000行的程序，我很确定我遇到过下一个瓶颈，我已经能感觉到了。特别困难的部分是与那些没有像你一样突破瓶颈的人讨论技术。突破这些瓶颈意味着做出不同的权衡，尤其是那些在短期内看似不合理但后来却有所帮助的决策。很难争辩，短期优势是显而易见的，但我无法说服任何人相信一年后可能会做出破坏现有代码的看似无害的更改。EdsgerDijkstra在1969年写道：一个一岁以上的孩子会以一定的速度爬行，比如每小时一英里。但是每小时一千英里是超音速喷气式飞机。两者在移动物体的能力方面没有可比性，任何一个可以到达而另一个不能到达的东西，反之亦然。一位初级程序员Clift提到，他学会了爬行，然后蹒跚学步，然后走路，然后慢跑，然后跑，最后冲刺，他想，“以这种速度，我可以跟上超音速喷气式飞机的速度。”速度！”但是他遇到了2,000行的限制，因为他的技能将不再扩展。他必须改变他的移动方式，比如开车以获得更快的速度。然后他学会了开车，开始很慢，后来越来越快，但到了20000行的极限。驾驶汽车的技术并不能转化为驾驶喷气式飞机。我的朋友BradGrantham用新手程序员解决“蛮力”问题的方式说明了这一点。我认为这是真的：当代码在2000行以下时，你可以写任何乱七八糟的脏代码，靠你的记忆来拯救你。周到的类和包分解可以使您的代码大小达到20,000行。突破这个瓶颈的关键是什么？对我来说，这是关于保持简单。除非现在绝对需要，否则拒绝添加任何新功能或新代码。我在EveryLineIsaPotentialBug中提出了这个问题（在SimpleisGood之前仍然略知一二）。梦工厂的首席特效设计师是这样理解的：对我来说，灯光工具之所以成功，是因为他选择了一系列易于使用和维护且功能强大到足以成为出色灯光工具的小功能。作为一名技术主管，我明白我的主要贡献是对那些觉得自己很重要但无法证明自己的需求的同事说“不”。但真正的诀窍是了解哪些需求增加了线性复杂性（仅与自身相关）和指数复杂性（与其他需求相关）。两者都应该避免，但后者需要更有说服力的理由。例如，2012年，Linux内核有1500万行代码。其中75%是线性复杂度（驱动程序、文件系统和处理器架构相关代码）。您可能有许多视频驱动程序，它们之间没有任何（或很少）交互。其余的有更多的依赖性。Dijkstra发现很难教授这些高级方法，因为它们只对20,000或200,000行的程序有意义。任何类或规范都必须将其实例限制在几百行以内，暴力破解方法也适用于此。您确实需要示例来向您展示30,000行代码并证明可以轻松添加新功能，因为该程序上手并不复杂。但这实际上是不可能的。.不知道要做什么改动才能突破20万行的瓶颈。我最近切换到一种更纯粹的函数式风格，可变状态更少，也许这会让我休息一下。我很好奇当代码量达到2000万行时会是什么样子。
