En este artículo, el autor analiza la cantidad de tiempo que se dedica a escribir libros o código de programa, y llega a un patrón interesante. Se puede usar para programar el trabajo del proyecto.Ley de Hofstadter: cualquier negocio siempre dura más de lo esperado, incluso si tiene en cuenta la ley de Hofstadter.
- Douglas Hofstadter, Gödel, Asher, Bach
Escribir prosa y código tiene mucho en común. Pero la similitud más notable es probablemente que ni los escritores ni los programadores pueden terminar su trabajo a tiempo. Los escritores son conocidos por romper los plazos. Los programadores se han ganado la reputación de personas cuyos resultados siempre son muy diferentes de los cálculos iniciales. Surge la pregunta: ¿por qué?
Hoy tuve una idea de cómo responderlo. Y mis hallazgos me sorprendieron.
Estudiando mis libros
Mis dos libros,
Hello, startup y
Terraform: lanzamos y trabajamos , escribí en el entorno de creación de libros
Atlas , que proporciona la gestión de todo el contenido con Git. Esto significa que cada línea de texto, cada edición y cada cambio se ha confirmado en el registro de confirmación de Git.
Veamos cuánto esfuerzo se dedicó a escribir dos libros.
Hola inicioComencemos con mi primer libro.
Hola, inicio . Tiene 602 páginas y aproximadamente 190 mil palabras.
cloc en el repositorio
Hello, Startup git y obtuve los siguientes resultados
(por simplicidad, las partes fraccionarias se descartan):
602 páginas contienen 26.571 líneas de texto. La mayor parte está escrita en
AsciiDoc , similar a Markdown. Atlas lo utiliza para escribir casi cualquier contenido. Usando HTML y CSS, Atlas define el diseño y la estructura de un libro. Además de ellos, hay otros lenguajes de programación (Java, Ruby, Python y no solo), en los que se escriben varios ejemplos para los temas tratados en el libro.
Pero 602 páginas y 26.571 líneas son solo el resultado final. No reflejan cerca de 10 meses de escritura, cambio, edición, revisión, ajustes estilísticos, investigación, notas y otros trabajos que contribuyen a la publicación del libro. Por lo tanto, para obtener ideas más útiles, utilicé
git-quick-stats para analizar todo el registro de confirmación del libro.
Entonces, agregué 163,756 líneas y eliminé 131,425, lo que en total da 295,181 líneas de material procesado. Es decir, resultó que escribí o eliminé un total de 295 181 líneas, de las cuales quedaron 26 571 líneas como resultado. Esta relación es un poco más de 10: 1. Para obtener cada línea publicada, ¡primero tenía que escribir otras 10!
Admito que contar el número de líneas agregadas y eliminadas de Git no puede considerarse una métrica ideal para el proceso de edición. Pero, al menos, esto nos permite comprender que un cálculo simple no es suficiente para evaluar el trabajo realizado. Una parte sustancial del proceso no se reflejó en absoluto en el registro de confirmación de Git. Por ejemplo, los primeros capítulos se escribieron en Google Docs antes de mudarme a Atlas, y muchas modificaciones se realizaron en mi computadora sin compromisos.
A pesar de que estos datos están lejos de ser ideales, creo que la proporción general de "material de texto original" a publicado es 10: 1.
Terraform: empezamos y trabajamosVerifiquemos si esta proporción es aplicable a mi segundo libro
Terraform: lanzamos y trabajamos , que contiene 206 páginas y alrededor de 52 mil palabras.
La salida simplificada de
cloc :
206 páginas constan de 8410 líneas de texto. Nuevamente, la mayor parte del texto está escrito en AsciiDoc, aunque este libro contiene significativamente más ejemplos de código escritos principalmente en HCL, el idioma principal de Terraform. Además de él, hay muchos Markdowns que usé para documentar ejemplos de HCL.
Usaremos
git-quick-stats para verificar el historial de revisiones de este libro:
Durante casi cinco meses, agregué 32,209 y eliminé 22,402 filas, totalizando 54,611 filas recicladas. La precisión de la evaluación del proceso de edición de este libro sufre aún más, ya que el trabajo comenzó como una
serie de publicaciones en el blog que pasaron por una revisión tangible antes de pasar a Atlas y Git. El volumen de estas publicaciones de blog ocupa al menos la mitad del libro, por lo que será lógico aumentar la tasa final del texto procesado en un 50%. Es decir, resultará 54611 * 1.5 = 81 916 líneas de texto editable, resultando en un total de 8410 líneas.
¡Y de nuevo, se observa una relación de aproximadamente 10: 1!
No es sorprendente que los escritores no cumplan con los plazos. Si se supone que el calendario debe entregar un libro de 250 páginas, en la práctica resulta que en el proceso escribiremos 2500 páginas.
¿Qué pasa con la programación?
¿Cómo va el desarrollo? Decidí revisar varios repositorios de código abierto de diferentes niveles de madurez: desde unos pocos meses hasta 23 años.
terraform-aws-couchbase (2018)terraform-aws-couchbase es un conjunto de módulos para implementar y administrar Couchbase en AWS, cuyo código fuente se abrió en 2018.
La salida simplificada de
cloc :
Y aquí está el resultado de verificar
git-quick-stats :
Obtenemos hasta 37 693 líneas de código de trabajo, lo que resulta en 7481 líneas del código final en una proporción de 5: 1. ¡Incluso en el repositorio de menos de 5 meses, tuve que volver a escribir cada línea cinco veces! No es sorprendente que evaluar el desarrollo de software sea complicado: ni siquiera imaginamos que para obtener 7.5 mil líneas de código final, en realidad tenemos que escribir 35 mil
Veamos cómo están las cosas con productos más antiguos.
Terratest (2016)Terratest es una biblioteca de código abierto creada en 2016 para probar el código de infraestructura.
La salida simplificada de
cloc :
Los resultados de
git-quick-stats :
Estas son 49 126 líneas de código de trabajo, que se convirtieron en 6140 líneas del texto final. Para un repositorio de dos años, la proporción fue de 8: 1. Pero Terratest todavía es bastante joven, así que echemos un vistazo a los repositorios más antiguos.
Terraforma (2014)Terraform es una biblioteca de código abierto creada en 2014 para administrar la infraestructura utilizando métodos de programación.
La salida simplificada de
cloc :
Los resultados de
git-quick-stats :
Obtenemos 12,945,966 líneas de código de trabajo, lo que resulta en 1,371,718 líneas del resultado final. Relación 9: 1. Terraform ha existido durante casi 4 años, pero la biblioteca aún no se ha lanzado, por lo que incluso con esta relación, su código base aún no se puede llamar maduro. Miremos aún más el pasado.
Express.js (2010)Express es un popular marco de JavaScript de código abierto lanzado para desarrollo web en 2010.
La salida simplificada de
cloc :
Los resultados de
git-quick-stats :
Obtenemos 224 211 líneas de código de trabajo, reducidas a 15 325 líneas finales. Resultado 14: 1. Express tiene aproximadamente 8 años, sus últimas versiones son la número 4.x. Se considera el marco web más popular y probado en batalla para Node.js.
Parece que tan pronto como la relación alcanza el nivel de 10: 1, podemos decir con confianza que la base del código ya está "madura". Veamos qué sucede si profundizas aún más en el pasado.
jQuery (2006)jQuery es una popular biblioteca JavaScript de código abierto lanzada en 2006.
La salida simplificada de
cloc :
Los resultados de
git-quick-stats :
Total de 730,146 líneas de código de trabajo, lo que resulta en 47,559 líneas del resultado final. Relación 15: 1 para un repositorio de casi doce años.
Vayamos otros diez años atrás.
MySQL (1995)MySQL es una popular base de datos relacional de código abierto creada en 1995.
La salida simplificada de
cloc :
Los resultados de
git-quick-stats :
Obtenemos 58 562 999 líneas de trabajo, 3 662 869 líneas del código final y una proporción de 16: 1 para un repositorio de casi veintitrés años. Wow! Cada línea de código MySQL ha sido reescrita 16 veces.
Conclusiones
Los resultados generalizados para mis libros son los siguientes:
Titulo
| Lineas de trabajo
| Líneas de resumen
| Ratio
|
Hola inicio
| 295 181
| 26,571
| 11: 1
|
Terraform: empezamos y trabajamos
| 81 916
| 8410
| 10: 1
|
Y aquí hay una tabla resumen para varios proyectos de programación:
Titulo
| Año de fabricación
| Lineas de trabajo
| Líneas de resumen
| Ratio
|
terraform-aws-couchbase
| 2018
| 37,693
| 7481
| 5: 1
|
Terratest
| 2016
| 49 126
| 6140
| 8: 1
|
Terraforma
| 2014
| 12 945 966
| 1 371 718
| 9: 1
|
Expreso
| 2010
| 224 211
| 15 325
| 14: 1
|
jQuery
| 2006
| 730,146
| 47 559
| 15: 1
|
MySQL
| 1995
| 58 562 999
| 3 662 869
| 16: 1
|
¿Qué significan todos estos números?
Regla 10: 1 en prosa y programaciónDado que mi conjunto de datos es limitado, solo puedo sacar algunas conclusiones preliminares:
- La proporción de "materia prima" a "producto final" para el libro es de aproximadamente 10: 1. Tenga en cuenta esta cifra cuando discuta con el editor un cronograma para enviar material. Si necesita escribir un libro de 300 páginas, de hecho debe componer unas 3 mil páginas.
- Se puede deducir una regla similar para software maduro y no trivial: la relación del volumen del código procesado con el total es de al menos 10: 1. Tenga esto en cuenta cuando un gerente o cliente le pida que calcule los costos de tiempo. Una aplicación de 10 mil líneas requerirá que escriba aproximadamente 100 mil líneas.
Estos hallazgos pueden resumirse como una
regla 10: 1 para escribir y programar :
Escribir un buen software o texto requiere que cada línea se reescriba un promedio de 10 veces.
Próximos pasos
Por supuesto, las líneas de código y las líneas de texto no pueden considerarse una medida ideal. Pero, creo, si recopila una cantidad suficiente de datos, puede determinar si la regla 10: 1 es universal y útil para determinar la fecha límite para completar un proyecto.
Algunas preguntas que me gustaría recibir una respuesta:
- ¿Es posible usar la relación de líneas de código procesadas a líneas finales como una métrica rápida para evaluar la madurez de un software en particular? Por ejemplo, ¿podemos confiar en la solución de problemas clave de infraestructura a bases de datos, lenguajes de programación o sistemas operativos si para ellos esta relación ha alcanzado al menos 10: 1?
- ¿El volumen del texto de trabajo depende del tipo de software? Por ejemplo, Bill Scott descubrió que en Netflix solo aproximadamente el 10% del código de la interfaz de usuario tiene una vida de hasta un año , y el 90% restante en este momento está completamente reescrito. ¿Cuál es la velocidad de reemplazo de código para el backend, las bases de datos, las utilidades de línea de comandos y otros tipos de programas?
- ¿Qué porcentaje del código se procesa después del lanzamiento inicial? Es decir, ¿qué porcentaje del trabajo puede considerarse "soporte de software"?
Si es autor de libros y puede hacer un análisis similar, me complacerá saber sus resultados. Y si alguien tiene tiempo para automatizar dicho análisis, será genial conocer las relaciones que se encuentran en varios proyectos de código abierto.
13 de agosto actualizaciónLa discusión de una publicación en
Hacker News y
la r / programación de Reddit reveló otros dos puntos interesantes:
- ¡Aparentemente, una regla similar 10: 1 se aplica a películas , periodismo, música y fotografía! ¿Quién lo hubiera pensado?
- Los lectores dejaron muchos comentarios de que incluso un solo cambio de caracteres se puede contar en Git como una inserción o eliminación de una línea, por lo que un indicador de 100 mil líneas cambiadas no significa que cada línea haya sido procesada.
La última observación es cierta, pero, como escribí anteriormente, mis datos no tienen en cuenta otros tipos de cambios:
- No hago commits para cada línea separada. Puedo cambiarlo diez veces, pero solo hago una confirmación.
- La situación descrita en el párrafo anterior es aún más relevante para la programación. Durante la prueba de código, puedo cambiar una línea 50 veces, mientras hago solo una confirmación.
- Muchos ciclos de edición y escritura se realizaron fuera de Git (algunos capítulos se escribieron en Google Docs o Medium, y las ediciones estilísticas se hicieron en PDF).
Creo que todos estos factores compensan la peculiaridad de tener en cuenta la inserción o eliminación de líneas en Git. Por supuesto, mis estimaciones pueden ser inexactas, y la proporción real será de 8: 1 o 12: 1. Pero en general, la diferencia no es demasiado grande, y 10: 1 es más fácil de recordar.
Actualización del 14 de agostoGithub
Decagon creó un repositorio llamado
hofs-churn con un script bash para calcular fácilmente
cuánto código se ha resuelto en sus repositorios. También lo utilizó para analizar una serie de repositorios, como React.js, Vue, Angular, RxJava y muchos otros, y los resultados fueron bastante interesantes.
