El trabajo de un programador debe medirse en eficacia y eficiencia, y medir líneas de código puede ser tan absurdo como medir el trabajo de un médico por el número de recetas extendidas en lugar de por la calidad de vida de sus pacientes.
#3 Hay diferentes medidas. La que tú dices se usa generalmente para evaluar costes (concretamente el coste en recursos humanos de un proyecto), no el tiempo y esfuerzo requerido o empleado (que es un concepto más amplio).
De hecho para evaluar el coste en recursos humanos existe formalmente la unidad "mes/hombre". Aunque ésta tiende a usarse cada vez menos, debido a la falaz costumbre que tienen las empresas cárnicas intermediarias de cumplir con ese número simplemente dividiéndolo entre mucha gente a base de añadir más y más programadores ceporros, en lugar de crear un equipo de pocos programadores pero que sean de calidad. Por decirlo de alguna manera, confunden "meses/hombre" con "hombres/mes", y no es lo mismo.
Esta mala costumbre lleva a la paradoja conocida precisamente como "The Mythical Month Man", según la cual si añades más y más gente a un proyecto paradójicamente no estás reduciendo su coste en tiempo sino aumentándolo, porque estás añadiendo complejidad al proyecto (comunicación, trabajo en equipo, reparto de tareas, secuenciación de hitos, coordinación de las pruebas, etc.) y con ello retardas los resultados, aumentando el coste del proyecto e invalidando la estimación inicial del coste humano.
Aún así son mejores los "meses hombre" que las "horas de trabajo". Porque el "mes hombre" trata de medir el coste por resultado (obtenido o esperado), mientras que una simple "hora de trabajo" sólo mide el coste en salarios y nada más. Además la hora es una unidad lo suficientemente pequeña como para que la medición se pueda ver alterada simplemente porque algún gilipollas se pasa medio día chateando y jugando en Facebook o chuminadas similares.
#5 "Además la hora es una unidad lo suficientemente pequeña como para que la medición se pueda ver alterada simplemente porque algún gilipollas se pasa medio día chateando y jugando en Facebook o chuminadas similares."
El que ha escrito este artículo no parece saber de qué habla.
Cuando un proyecto se mide en "líneas de código" se está evaluando el coste temporal del proyecto entero (lo cual incluye especificación, diseño, desarrollo, pruebas, instalación, lanzamiento, administración, gestión, tarea comercial, infraestructuras, formación, etc, etc, etc... o sea, TODO). A la unidad de medida se la llama "línea de código" como se la podía llamar "piojo en escabeche", y es una simple unidad de tiempo y esfuerzo. Es de tontos pensar que dicha unidad representa una línea de código desarrollado propiamente dicha.
Por ejemplo, si en un día desarrollas veinte líneas de código, es perfectamente plausible que el coste total de ese desarrollo para el proyecto sea de mil líneas de código (y no, no estoy exagerando las cifras, los desarrolladores no son los únicos que curran aunque tiendan a pensar que sí).
De hecho el artículo pone un ejemplo aún más claro: si refactorizas un algoritmo y eliminas líneas de código es evidente que no estás creando código. Sin embargo ese esfuerzo tiene un coste perfectamente mesurable en "líneas de código" (o "piojos en escabeche"), cosa que el autor del artículo ignora por completo.
Considero el meneo erróneo, debido a la ignorancia del autor.
#2 Siempre pensé que los proyectos se evalúan en horas de trabajo, que es una unidad que engloba toda actividad dedicada a él. ¿No? Yo por lo menos lo hago así. Por lo menos yo no conozco a nadie que llame las horas "lineas de código".
Si me dieran un euro cada vez que leo un post del típico programador llorón que se cree el ombligo del mundo, que dice que es el más eficiente en su trabajo y que debería de cobrar lo mismo que Ronaldo, tendría suficiente dinero para el macbookpro con pantalla retina.
#4 Cuando lees el típico post del programador llorón, ¿sueles leer también el último párrafo? ¿O simplemente te imaginas lo que va a decir y piensas que va a ser todo defendiendo a su gremio?
Comentarios
#3 Hay diferentes medidas. La que tú dices se usa generalmente para evaluar costes (concretamente el coste en recursos humanos de un proyecto), no el tiempo y esfuerzo requerido o empleado (que es un concepto más amplio).
De hecho para evaluar el coste en recursos humanos existe formalmente la unidad "mes/hombre". Aunque ésta tiende a usarse cada vez menos, debido a la falaz costumbre que tienen las empresas cárnicas intermediarias de cumplir con ese número simplemente dividiéndolo entre mucha gente a base de añadir más y más programadores ceporros, en lugar de crear un equipo de pocos programadores pero que sean de calidad. Por decirlo de alguna manera, confunden "meses/hombre" con "hombres/mes", y no es lo mismo.
Esta mala costumbre lleva a la paradoja conocida precisamente como "The Mythical Month Man", según la cual si añades más y más gente a un proyecto paradójicamente no estás reduciendo su coste en tiempo sino aumentándolo, porque estás añadiendo complejidad al proyecto (comunicación, trabajo en equipo, reparto de tareas, secuenciación de hitos, coordinación de las pruebas, etc.) y con ello retardas los resultados, aumentando el coste del proyecto e invalidando la estimación inicial del coste humano.
Aún así son mejores los "meses hombre" que las "horas de trabajo". Porque el "mes hombre" trata de medir el coste por resultado (obtenido o esperado), mientras que una simple "hora de trabajo" sólo mide el coste en salarios y nada más. Además la hora es una unidad lo suficientemente pequeña como para que la medición se pueda ver alterada simplemente porque algún gilipollas se pasa medio día chateando y jugando en Facebook o chuminadas similares.
#5 "Además la hora es una unidad lo suficientemente pequeña como para que la medición se pueda ver alterada simplemente porque algún gilipollas se pasa medio día chateando y jugando en Facebook o chuminadas similares."
Eso lo resume todo
#0 Es duplicada:
Escribiendo -2000 líneas de código [EN]
Escribiendo -2000 líneas de código [EN]
folklore.orgEl que ha escrito este artículo no parece saber de qué habla.
Cuando un proyecto se mide en "líneas de código" se está evaluando el coste temporal del proyecto entero (lo cual incluye especificación, diseño, desarrollo, pruebas, instalación, lanzamiento, administración, gestión, tarea comercial, infraestructuras, formación, etc, etc, etc... o sea, TODO). A la unidad de medida se la llama "línea de código" como se la podía llamar "piojo en escabeche", y es una simple unidad de tiempo y esfuerzo. Es de tontos pensar que dicha unidad representa una línea de código desarrollado propiamente dicha.
Por ejemplo, si en un día desarrollas veinte líneas de código, es perfectamente plausible que el coste total de ese desarrollo para el proyecto sea de mil líneas de código (y no, no estoy exagerando las cifras, los desarrolladores no son los únicos que curran aunque tiendan a pensar que sí).
De hecho el artículo pone un ejemplo aún más claro: si refactorizas un algoritmo y eliminas líneas de código es evidente que no estás creando código. Sin embargo ese esfuerzo tiene un coste perfectamente mesurable en "líneas de código" (o "piojos en escabeche"), cosa que el autor del artículo ignora por completo.
Considero el meneo erróneo, debido a la ignorancia del autor.
#2 Siempre pensé que los proyectos se evalúan en horas de trabajo, que es una unidad que engloba toda actividad dedicada a él. ¿No? Yo por lo menos lo hago así. Por lo menos yo no conozco a nadie que llame las horas "lineas de código".
Si me dieran un euro cada vez que leo un post del típico programador llorón que se cree el ombligo del mundo, que dice que es el más eficiente en su trabajo y que debería de cobrar lo mismo que Ronaldo, tendría suficiente dinero para el macbookpro con pantalla retina.
#4 Cuando lees el típico post del programador llorón, ¿sueles leer también el último párrafo? ¿O simplemente te imaginas lo que va a decir y piensas que va a ser todo defendiendo a su gremio?
#7 No, cuando va por el segundo berrinche dejo de leer, saco el teléfono y llamo a la buhambulancia.