Original source: https://www.teamten.com/lawrence/writings/norris-numbers.html
En 2011, John D. Cook escribió la siguiente publicación de blog :
Mi amigo Clift Norris ha identificado una constante fundamental a la que llamo el número de Norris, la cantidad promedio de código que un programador no capacitado puede escribir antes de chocar contra una pared. Clift estima que son 1.500 líneas. Más allá de eso, el código se vuelve tan complicado que el autor no puede depurarlo o modificarlo sin un esfuerzo hercúleo.
No conozco suficientes programadores novatos para confirmar este efecto, pero de forma independiente había notado el siguiente muro en el viaje del programador, que ocurre en 20.000 líneas. Cambiaré el número de Norris a 2000 para obtener un buen salto de potencia de diez.
Me topé repetidamente con el muro de las 20.000 líneas en mi primer trabajo después de la universidad, al igual que mis compañeros de trabajo (que eran todos tan jóvenes como yo). En DreamWorks teníamos 950 programas para que los usaran los animadores, y un recuento de líneas mostró que los más grandes rondaban entre 20.000 y 25.000 líneas. Más allá de eso, fue demasiado esfuerzo agregar funciones.
A mediados de 1996 me encargaron escribir la herramienta de iluminación DreamWorks (con otros dos programadores) y sabía que esto sería mucho más grande que 20.000 líneas de código. Cambié mi enfoque de la programación y la herramienta se entregó con éxito un año después con alrededor de 200.000 líneas. (Está previsto que se retire en 2013, ya que se ha utilizado diariamente durante 16 años para hacer 32 películas). Desde entonces, he escrito varios programas más en el rango de 100.000 a 200.000 líneas. Estoy seguro de que estoy chocando contra la siguiente pared; Puedo sentirlo.
Lo que es particularmente difícil es tener discusiones técnicas con alguien que no ha derribado tantos muros como tú. Romper estos muros significa hacer diferentes concesiones y, específicamente, significa tomar una decisión que parece tener menos sentido en el corto plazo pero que ayudará más adelante. Este es un argumento difícil de sostener: las ventajas a corto plazo son inmediatamente demostrables, pero no puedo convencer a nadie de que dentro de un año alguien pueda hacer un cambio inocente que rompa este código.
Edsger Dijkstra escribió en 1969 :
Un niño de un año gateará a cuatro patas a una velocidad de, digamos, una milla por hora. Pero una velocidad de mil millas por hora es la de un avión supersónico. Considerados como objetos con capacidad de movimiento, el niño y el jet son incomparables, pues lo que uno puede hacer, el otro no puede y viceversa.
Un programador novato, del tipo al que se refiere Clift Norris, aprende a gatear, luego a caminar, luego a trotar, luego a correr, luego a correr, y piensa: “A este ritmo de aceleración puedo alcanzar la velocidad de un avión supersónico”. !” Pero alcanza el límite de 2000 líneas porque sus habilidades no aumentan. Debe moverse de otra manera, usando un coche, para ir más rápido. Luego aprende a conducir, primero despacio, luego más rápido, pero llega al límite de 20.000 líneas. Las habilidades de conducción no se transfieren a pilotar un avión a reacción.
Mi amigo Brad Grantham explica esto diciendo que el programador novato aplica “fuerza bruta” al problema. Creo que esto es correcto: cuando el código tiene menos de 2000 líneas, puedes escribir cualquier basura enredada y confiar en tu memoria para salvarte. La descomposición cuidadosa de clases y paquetes le permitirá escalar hasta 20.000 líneas.
¿Cuál es la clave para superar eso? Para mí, se trataba de mantener las cosas simples. Rechace absolutamente agregar cualquier característica o línea de código a menos que la necesite ahora mismo y la necesite con urgencia . Ya mencioné esto en Cada línea es un error potencial (y en mi segundo año antes en Lo simple es bueno ). El arquitecto jefe de efectos de DreamWorks lo expresó de esta manera:
Para mí, la genialidad de [la herramienta de iluminación] estuvo en seleccionar un pequeño conjunto de características que fueran manejables de escribir y mantener y lo suficientemente fuertes como para crear una excelente herramienta de iluminación.
Como líder tecnológico, considero que mi principal contribución es decir “no” a las funciones que los compañeros de trabajo consideran importantes pero que no pueden justificar. El verdadero truco es saber cuándo una nueva característica agrega complejidad lineal (solo su propio peso) o complejidad geométrica (interactúa con otras características). Ambos deberían evitarse, pero el segundo requiere una justificación muy convincente.
Por ejemplo, en 2012, el kernel de Linux tenía 15 millones de líneas de código . De eso, el 75% tenía complejidad lineal (controladores, sistemas de archivos y código específico de la arquitectura); es posible que tenga docenas de controladores de video y no interactúen (mucho) entre sí. El resto es más geométrico.
El punto de Dijkstra es que es difícil enseñar estas técnicas avanzadas, porque sólo tienen sentido en programas de 20.000 o 200.000 líneas. Cualquier clase o libro de texto debe limitar sus ejemplos a unos pocos cientos de líneas, y el método de fuerza bruta funciona bien allí. Realmente necesita el libro de texto para mostrarle el programa de 30,000 líneas y luego mostrarle la nueva característica que se agregó fácilmente porque el programa no era demasiado complejo para empezar. Pero eso es efectivamente imposible.
La experiencia ha demostrado que la capacidad demostrada de alguien para hacer un trabajo excelente de una escala determinada no es de ninguna manera una garantía de que, cuando se enfrente a un trabajo mucho más grande, no lo arruinará. —Edsger Dijkstra
No sé qué tendré que cambiar para superar el muro de la línea 200.000. Recientemente he estado cambiando a un estilo más puramente funcional y despojándome del estado mutable, y tal vez esto pueda ayudarme a abrirme paso.
Y tengo mucha curiosidad por ver de qué se trata la barrera de los 2 millones de líneas.
Parece que hay un muro alrededor de 3-4M LOC, y realmente, después de 3M LOC, la tasa de crecimiento parece desacelerarse significativamente sin importar cuántas personas (cientos) o años estén involucradas (décadas). —Dan Wexler
I’ve always been captivated by the wonders of science, particularly the intricate workings of the human mind. With a degree in psychology under my belt, I’ve delved deep into the realms of cognition, behavior, and everything in between. Pouring over academic papers and research studies has become somewhat of a passion of mine – there’s just something exhilarating about uncovering new insights and perspectives.