The relationship between programmer growth and the number of lines of code

In 2011, John D. Cook wrote a blog post in which he mentioned:

My friend Clift Norris discovered a fundamental constant, which I call the Norris constant, the average amount of code an untrained programmer can write before he or she hits a wall. Clift estimated this value to be 1500 lines of code. Beyond that number, the code becomes so messy that it cannot be easily debugged or modified.

I don't know enough junior programmers to verify this result, but I have learned that the next bottleneck in a programmer's career will occur at line 20,000. I changed the Norris constant to 2,000 to make it ten times larger.

In my first job out of college, I and my coworkers (who were about my age) repeatedly hit the 20,000-line bottleneck. At DreamWorks we had 950 programs for animators to use, and line counts showed that the largest ones were around 20,000 to 25,000 lines. Beyond that, no amount of effort could add new features.

In mid-1996 I was tasked with writing DreamWorks' lighting tool (along with two other programmers), and I knew it would be well over 20,000 lines of code. I changed my approach and the tool was successfully delivered a year later at around 200,000 lines of code. (The tool was scheduled to be retired in 2013, after 16 years of daily use and 21 films.) Having written several programs with 100,000 to 200,000 lines of code, I was pretty sure I had hit the next bottleneck, and I could already feel it.

The hardest part is discussing technology with people who haven't broken through as many bottlenecks as you have. Breaking through those bottlenecks means making different trade-offs, especially decisions that don't make sense in the short term but will help later. It's hard to argue, the short-term benefits are clear, but I can't convince anyone that a year from now someone might make a seemingly harmless change that will break existing code.

Edsger Dijkstra wrote in 1969:

A one year old child will crawl at a certain speed, say one mile per hour. But a thousand miles per hour is a supersonic jet. There is no comparison in terms of the ability of objects to move, and anything one can do the other cannot, and vice versa.

A junior programmer, as Clift refers to him, learns to crawl, then toddle, then walk, then jog, then run, then sprint, and thinks, "At this rate I can catch up to the speed of a supersonic jet!" But he runs into the 2,000-line limit because his skill doesn't scale any more. He has to change his way of moving, like driving a car, to get faster. Then he learns to drive a car, slowly at first, then faster and faster, but never gets to the 20,000-line limit. The skill of driving a car doesn't translate into flying a jet.

My friend Brad Grantham illustrates this point by saying that new programmers solve problems with "brute force". I think it's true: when your code is under 2,000 lines, you can write any messy, dirty code and rely on your memory to save you. Thoughtful class and package decomposition will get you there at 20,000 lines.

What is the key to breaking through this bottleneck? For me, it is to keep things simple. Unless it is absolutely necessary now, completely refuse to add any new features or new code. I have already improved this in Every Line Is a Potential Bug (I only half understood it before Simple is Good). This is how the top special effects architect at DreamWorks understands it:

For me, the success of the lighting tool is that it chooses a series of small features that are easy to use and maintain, but powerful enough to be a great lighting tool.

As a tech lead I understand that my main contribution is to say "no" to requests that my colleagues think are very important but cannot justify. But the real trick is to know what requests add linear complexity (only related to itself) and exponential complexity (related to other requirements). Both should be avoided, but the latter requires a more convincing reason.

For example, in 2012, the Linux kernel had 15 million lines of code. 75% of that was linear in complexity (drivers, filesystems, and processor architecture-related code). You might have many video drivers, but they don't have any (or very little) interaction between them. The rest has many more dependencies.

Dijkstra found it difficult to teach these advanced methods because they only make sense for programs that are 20,000 or 200,000 lines long. Any class or specification must limit its examples to a few hundred lines, and the brute force approach works just as well here. You really need examples to show you 30,000 lines of code and prove that new features can be easily added because the program is not very complex to start with. But this is not practically possible. .

I don't know what changes I need to make to break the 200k line mark. I've recently switched to a more purely functional style and reduced mutable state, so maybe that will help me break through.

And I'm curious to see what it will look like when the code size reaches 20 million lines.