Norris constant in programmer's career

My friend Clift Norris found a basic constant called the Norris constant, the average amount of code that an untrained programmer can write before he or she encounters a bottleneck. Clift estimates that this value is 1500 rows. After this number is exceeded, the Code becomes so messy that I cannot easily debug and modify it.

I still don't know enough Junior programmers to verify this result, but I realize that the next bottleneck in my career will happen in 20,000 rows. I changed the Norris constant to 2,000, Which is exactly ten times that.

In my first job after I left college, I encountered a bottleneck of 20,000 rows in the same way as my colleagues (almost the same age as me. At DreamWorks, We have 950 programs for animators. The number of rows statistics shows that the number of rows is between 20,000 and 25,000. If this number is exceeded, more efforts cannot be made to add new features.

In 1996, I was responsible for writing DreamWorks lighting tools (and two other programmers), and I knew this would be far more than 20,000 lines of code. I changed my programming method and the tool was successfully delivered in about 200,000 lines of code a year later. (This tool was planned to retire in 2013 and was used every day for 21 movies in 16 years .) I have written several programs with lines ranging from 0.1 million to 0.2 million. I am sure that I have encountered the next bottleneck and I can feel it.

The most difficult part is to discuss technology with people who have not broken several bottlenecks like you. Breaking these bottlenecks means making different trade-offs, especially some decisions that seem unreasonable in the short term but will be helpful in the future. This is hard to argue. The advantages in the short term are obvious, but I cannot convince anyone that from now on someone may make a seemingly harmless change within a year, but it will damage the existing code.

Edsger Dijkstra wrote in 1969:

A one-year-old child crawls at a certain speed, for example, a mile per hour. But one thousand miles per hour is a supersonic jet. In terms of the ability to move objects, the two are incomparable. Either of them can be reached, but the other cannot, and vice versa.

A junior programmer referred to by Clift, learned to crawl, then toddler, then walk, Then jog, then run, and finally sprint, he thinks, "With this acceleration, I can catch up with the speed of the supersonic jet! "But he ran into the limit of 2,000 rows because his skills would not increase proportionally. He must change the way he moves, such as driving at a faster speed. Then he learned how to drive, started slowly, and then got faster and faster, but he got into the limit of 20000 rows. The technology of driving a car will not turn into a jet.

My friend Brad Grantham understands this with a novice programmer using "brute force" to solve the problem. I think this is correct: When the code is below 2,000 lines, you can write any messy and dirty code and save you by your memory. The well-thought-out class and package decomposition will bring your generation size to 20,000 rows.

What is the key to breaking through this bottleneck? For me, it is to keep things simple. No new features or code will be added unless necessary. I have raised this point in the every line is a potential bug (before simple is good ). The chief special effect architect of DreamWorks understands this:

For me, the successful lighting tool is that it has chosen a series of small functions that are easy to use and maintain and is powerful enough to become a great lighting tool.

As a technical leader, I understand that my main contribution is "no" to those colleagues who think it is very important but cannot prove their reasonable needs ". But the real trick is to know what needs increase linear complexity (only related to itself) and exponential complexity (associated with other needs ). Both should be avoided, but the latter must be more convincing.

For example, in 2012, the Linux kernel had 15 million lines of code. Among them, 75% are linearly complex (drivers, file systems, and Code related to the processor structure ). You may have many visual screen drivers, but there is no (or very few) interaction between them. The rest have more dependencies.

Dijkstra finds it difficult to teach these advanced methods, because they only make sense for those 20 thousand-line or 0.2 million-line programs. Any class or specification must limit its example to a few hundred rows. The same applies to brute force methods. You really need an example to show you 30,000 lines of code and then confirm that new functions can be easily added because the program is not very complex to get started. But this is actually impossible ..

I don't know what changes I made to break the bottleneck of 0.2 million rows. I have recently switched to a more pure functional style and reduced the variable state. Maybe this can make me break through.

And I 'd like to know what it will look like when the Code volume reaches 20 million lines.

Norris constant in programmer's career