- 2007, 2000 líneas de código

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• A comienzos de 1982, el equipo de software de Lisa estaba concentrado en el esfuerzo final para lanzar el software dentro de los siguientes seis meses.

• Algunos de los gerentes pensaron que sería una buena idea llevar un registro semanal de la cantidad de código que escribía cada ingeniero, así que crearon un formulario que debía entregarse cada viernes, e incluía un campo para anotar la cantidad de líneas de código escritas esa semana.

• Bill Atkinson, autor de Quickdraw y principal diseñador de la interfaz de usuario, pensaba que contar líneas de código era una forma absurda de medir la productividad del software, y que solo fomentaba escribir código desordenado, inflado y con errores.

• Atkinson había estado trabajando recientemente en optimizar el motor de cálculo de regiones de Quickdraw, y reescribió por completo el motor de regiones usando un algoritmo más simple y general, que después de algunos ajustes hizo que las operaciones con regiones fueran casi 6 veces más rápidas.

• Esa reescritura también tuvo como resultado colateral ahorrar unas 2000 líneas de código.

• En la etapa final de ese trabajo de optimización, llegó el momento de llenar por primera vez el formulario de gestión y, cuando llegó a la parte de líneas de código, pensó un momento y escribió el número -2000.

• No está claro cómo reaccionaron los gerentes, pero unas semanas después dejaron de pedirle a Atkinson que llenara el formulario, y él aceptó eso con gusto.

Opinión de GN⁺

• Este artículo deja una lección importante: en el desarrollo de software, la cantidad de código no representa la verdadera productividad. Medir el desempeño por líneas de código no solo es ineficiente, sino que a veces puede resultar contraproducente.
• El ejemplo de Bill Atkinson resalta la importancia de la optimización de software. Lograr un rendimiento más rápido con menos código es uno de los principios centrales de la ingeniería de software.
• Esta historia ayuda a entender por qué son importantes las prácticas modernas de desarrollo, especialmente enfoques como las metodologías ágiles y la integración/entrega continua (CI/CD). Estos enfoques ponen más valor en la calidad, la mantenibilidad y la experiencia del usuario que en la cantidad de código.
• En la industria se usan diversas herramientas y métricas para medir y mejorar la calidad del código. Por ejemplo, herramientas de análisis estático, procesos de revisión de código y seguimiento de cobertura de pruebas.
• Este artículo les recuerda a los desarrolladores lo importante que es enfocarse en la calidad por encima de la cantidad de código, evitar la complejidad innecesaria y optimizar el rendimiento.

[GN⁺]

Opiniones de Hacker News

• Choque sobre el conteo de líneas de código entre Microsoft e IBM

  • En la serie de TV de PBS "Accidental Empires" hay una escena en la que Steve Ballmer explica su experiencia durante el desarrollo conjunto de OS/2. Mientras Microsoft trabajaba con la mentalidad de una empresa pequeña, IBM estaba internamente enfocada en usar la cantidad de líneas de código (en miles de líneas, KLoC) como medida de la productividad de los programadores. Ballmer criticó a IBM por interesarse solo en la cantidad del código y no en su calidad.

• Enlaces a debates anteriores

  • Las discusiones sobre usar las líneas de código como métrica de productividad aparecen con frecuencia. Se incluyen enlaces que muestran varias conversaciones entre 2010 y 2022.

• Usar las líneas de código como métrica de producción es muy tonto

  • Se menciona la experiencia de resolver un bug de 20 años que no se había podido solucionar con una sola línea de código, o de arreglar un bug de 3 años con order by, y se plantea la duda de cómo podría medirse el impacto de una sola línea. También se comparte la experiencia de que los malos programadores escriben más código, y se presenta un caso en el que un desarrollador de Microsoft reescribió 33,000 caracteres de código de IBM en 220 caracteres. Como resultado, el trabajo de Microsoft terminó siendo evaluado como "negativo".

• Las preguntas simples a veces tienen el mayor impacto

  • Una pregunta sencilla sobre cómo implementar una función ("¿Cómo se manejará X?") puede llevar a la decisión de no crear esa función, lo que ahorra todos los costos de intentar hacerlo. Ese tipo de aporte no puede medirse con números y a veces incluso puede ganarte enemigos, pero aun así se reconoce a quienes se atreven a hacerlo.

• Experiencia compartida de optimización de código al inicio de la carrera

  • Se comparte la experiencia de haber optimizado un programa en C de más de 10,000 líneas a menos de 500. Partiendo de la simple suposición de que el desarrollador anterior quizá no sabía usar funciones ni cómo pasar datos variables a consultas SQL, se encontró que había escrito repetidamente la misma sentencia SQL en línea. El código duplicado se reemplazó reescribiendo las llamadas SQL como llamadas a funciones, tomando los valores de bind modificados desde un arreglo y llamando la función dentro de un bucle.

• Falta de una dirección clara al iniciar un proyecto

  • A veces, al comenzar un proyecto, no se conoce con exactitud la dirección correcta. A medida que uno se mete de lleno en el proyecto, entiende mejor el problema y la respuesta deseada, y como resultado puede quitar grandes partes y reemplazarlas por algo más pequeño y mejor. En este tipo de situaciones, los desarrolladores que tenían que meterlo todo en una ROM de 64KB enfrentaban una fuerte presión para hacer el código más pequeño.

• Experimento mental sobre usar la eliminación de código como métrica

  • Se propone un experimento mental: si un gerente leyera este artículo y decidiera de forma simplista usar la cantidad de líneas eliminadas como métrica, ¿la situación mejoraría o empeoraría?

• Atkinson Dither de Bill Atkinson

  • Se proporciona un enlace sobre Bill Atkinson y su técnica Atkinson Dither.

• Percepción sobre las líneas de código

  • Se cuestiona el uso de "líneas agregadas - líneas eliminadas" al escribir código. Así como una carrera de 10 km que empieza y termina en el mismo lugar no se considera una carrera de 0 km, se expresa la opinión de que con las líneas de código pasa lo mismo.

• El papel como empleado

  • Se comparte la lección de que, aunque seas tan inteligente como Einstein, sigues siendo un empleado y hay cosas que debes hacer como tal.