A principios de 1982, algunos directores de Lisa Software Team decidieron que sería una buena idea seguir el progreso de cada ingeniero en términos de la cantidad de código que escribieran. [...] Sin embargo, a Bill Atkinson (autor de Quickdraw) no le gustó la idea de medir así su trabajo...
No creo que sea para nada algo raro, el código bien escrito suele tener menos líneas, cualquier buen programador habrá escrito alguna vez una cantidad de líneas de código negativa. Como estudiante que soy nunca he tocado el código de otro pero mi propio código si que lo he reducido para mejorarlo mas de una vez. Donde esté el código limpio y bien pensado que se quite lo demás, para medir la calidad hace falta un tío que sepa, no hay otro modo.
#2 "Como estudiante que soy nunca he tocado el código de otro"... y eso es una de las peores cosas que hacen las universidades. Dos de las cosas que todo aspirante a trabajar en IT debería aprender a hacer son 1. tocar el código de otro y 2. tocar tu propio código de hace un par de años, porque por desgracia no sería realista pedir que fuese de hace más tiempo. Las dos enseñan muchísimo, pero lo más instructivo de todo es tocar el código de otro de hace cinco o seis años...
Y luego, esta es una de esas cosas que siempre me tocan las narices ¿A alguien se le ha ocurrido medir la productividad de un abogado en paquetes de folios gastados y la longitud de sus alegatos en los juicios, o la de un médico en recetas extendidas y pruebas encargadas? Sería absurdo, pero no más que medir la productividad de un programador en líneas, que incentiva las mismas prácticas nocivas y antiproductivas.
#4 "algo para lo que se necesitan verdaderos profesionales, y eso cuesta dinero." Lo dicho, un tío que sepa
#3 Código de otros no he tocado, pero código mío de hace meses (no llevo 2 años programando :P) si, por mi cuenta claro, y suele terminar con una reducción de líneas y una estructura más clara, además les voy metiendo mis librerías. Por ejemplo tengo pendiente reescribir un buscaminas que hice hace tiempo con OpenGL añadiéndole las cosas nuevas que he hecho ahora ya que fue la primera aplicación gráfica que hice y está algo chapucera.
#2 "para medir la calidad hace falta un tío que sepa, no hay otro modo."
En realidad sí que lo hay, medir los objetivos conseguidos en una determinada franja de tiempo en base a su complejidad.
Pero claro, para ello es necesario un seguimiento más serio de cada programador además de unas estimaciones más realistas, algo para lo que se necesitan verdaderos profesionales, y eso cuesta dinero.
Comentarios
Cantidad != calidad
No creo que sea para nada algo raro, el código bien escrito suele tener menos líneas, cualquier buen programador habrá escrito alguna vez una cantidad de líneas de código negativa. Como estudiante que soy nunca he tocado el código de otro pero mi propio código si que lo he reducido para mejorarlo mas de una vez. Donde esté el código limpio y bien pensado que se quite lo demás, para medir la calidad hace falta un tío que sepa, no hay otro modo.
#2 "Como estudiante que soy nunca he tocado el código de otro"... y eso es una de las peores cosas que hacen las universidades. Dos de las cosas que todo aspirante a trabajar en IT debería aprender a hacer son 1. tocar el código de otro y 2. tocar tu propio código de hace un par de años, porque por desgracia no sería realista pedir que fuese de hace más tiempo. Las dos enseñan muchísimo, pero lo más instructivo de todo es tocar el código de otro de hace cinco o seis años...
Y luego, esta es una de esas cosas que siempre me tocan las narices ¿A alguien se le ha ocurrido medir la productividad de un abogado en paquetes de folios gastados y la longitud de sus alegatos en los juicios, o la de un médico en recetas extendidas y pruebas encargadas? Sería absurdo, pero no más que medir la productividad de un programador en líneas, que incentiva las mismas prácticas nocivas y antiproductivas.
#4 "algo para lo que se necesitan verdaderos profesionales, y eso cuesta dinero." Lo dicho, un tío que sepa
#3 Código de otros no he tocado, pero código mío de hace meses (no llevo 2 años programando :P) si, por mi cuenta claro, y suele terminar con una reducción de líneas y una estructura más clara, además les voy metiendo mis librerías. Por ejemplo tengo pendiente reescribir un buscaminas que hice hace tiempo con OpenGL añadiéndole las cosas nuevas que he hecho ahora ya que fue la primera aplicación gráfica que hice y está algo chapucera.
#2 "para medir la calidad hace falta un tío que sepa, no hay otro modo."
En realidad sí que lo hay, medir los objetivos conseguidos en una determinada franja de tiempo en base a su complejidad.
Pero claro, para ello es necesario un seguimiento más serio de cada programador además de unas estimaciones más realistas, algo para lo que se necesitan verdaderos profesionales, y eso cuesta dinero.