Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

18 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
jueves, 19 de julio de 2007
Hace tiempo ya, oí hablar sobre el libro The Mytical Man-Month, de Frederick P. Brooks, donde se asegura que los mejores programadores rinden hasta 10 veces más que los que se encuentran en el lado opuesto, los peores. Otras fuentes, como "Facts and Fallacies of Software Engineering" llegan a indicar que la diferencia puede ser incluso de 28 a 1.

Sin duda, la productividad en el desarrollo es algo más que tirar muchas líneas de código por día; ya lo comenta Charles Connell en su artículo It's not about lines of code, donde explica por qué la productividad no puede ser medida en esos términos, de hecho, ¿muchas líneas de código implican un trabajo bien hecho? ¿y si se trata de un nido de bugs?

Así, a lo largo de su artículo, Charles va definiendo y añadiendo características que debería presentar el código creado hasta llegar a una posible unidad de medida de la productividad, líneas de código limpio, simple, correcto y bien documentado por día, para finalmente llegar a la conclusión de que tampoco es del todo apropiado: ¿qué ocurre si un buen desarrollador es capaz de crear una función en 100 líneas de código perfecto y salir de la oficina a la hora habitual, mientras que otros realizan el mismo buen trabajo en 2000 líneas de código trabajando hasta altas horas de la madrugada? ¿quién es más productivo?

La conclusión de Charles es que la productividad de un desarrollador es justamente su habilidad para resolver problemas de forma rápida. La ingeniería del software trata precisamente de eso, de aportar soluciones a los usuarios que usarán el sistema desarrollado, todo lo demás sobra. Sin embargo, como él mismo indica, es realmente difícil medir estas capacidades utilizando indicadores habituales como número de líneas de código, bugs provocados o tiempo de trabajo en la oficina.

Partiendo de esto, en "10 Developers For The Price Of One", Phil Haack, cuyo apellido seguro que lo predestinó a dedicarse a la informática, escribe sobre este tema centrando la medida de la productividad de los desarrolladores en torno al concepto TCO (Total Cost of Ownership), o Coste Total de Propiedad (CTO), e introduce algunas características propias de los buenos desarrolladores que hace que este factor sea óptimo.

La primera de ellas es la asunción de un proyecto como propio, la autosuficiencia en la resolución de problemas, tomar el control, resolver y asumir el avance del mismo como un objetivo personal. De esta forma se libera a los responsables de estar tan pendientes de estos aspectos y se recurre a ellos sólo cuando surgen problemas de entidad y con objeto de plantear una solución. Un desarrollador que escribe código rápido no es productivo, pues requiere de tiempo de los demás, y sobre todo, de aquellos que por sus responsabilidades disponen de menos tiempo.

La segunda hace referencia a la escritura de código con pocos errores. Un mal programador que escriba código muy rápidamente es un generador de bugs a una velocidad proporcional, lo que provocaría un mayor gasto de tiempo del equipo de testeo y control de calidad, así como del propio equipo de desarrollo en la corrección de los errores. Como comenta Phil, de nada vale ir rápido hacia la dirección equivocada.

En la tercera, se introduce el concepto de la creación de código mantenible. Y no sólo pensando en el mantenimiento futuro del software, sino durante el propio desarrollo inicial. Me ha gustado mucho su visión sobre esto, textualmente, Tan pronto como una línea de código sale de la pantalla y volvemos a ella, estamos en modo mantenimiento de la misma". Un código bien escrito, comprensible y limpio puede ahorrar mucho tiempo en el presente y futuro.

En cuarto lugar, comenta que los buenos desarrolladores hacen más con menos código, son capaces de identificar cuándo deben y cuándo no deben escribir software y utilizar componentes o elementos existentes. El reinvento de la rueda, no es beneficioso para nadie, y los buenos programadores suelen y deben esquivarlo.

Teniendo todos estos aspectos en cuenta, Phil retoma el concepto TCO indicando que todos estos factores son importantes a la hora de evaluar la productividad de un desarrollador en tanto en cuanto que influyen en el coste total de tener a un programador en la empresa, y no sólo fijándose en el coste directo que representa su nómina. Por ello asegura que intenta contratar, aunque no siempre lo consigue, al mejor desarrollador que encuentra en cada momento puesto que si es capaz de hacer más con menos código, escribir de forma inteligible, fácilmente mantenible y con menos errores, incrementará la productividad de sus compañeros, directivos y colegas. Por el contrario, un mal desarrollador puede disminuir la productividad de su entorno por los motivos anteriormente expuestos. Por este motivo puede justificarse la relación de 28 a 1 en la productividad entre unos y otros.

Estoy absolutamente de acuerdo con estas apreciaciones, un desarrollador no puede ser evaluado únicamente teniendo en cuenta aspectos cuantitativos como la cantidad de líneas de código que es capaz de generar: si lo que buscas es velocidad a la hora de teclear, contrata a un mecanógrafo, leche. Y aunque para cerrar un proyecto hace falta escribir líneas, tanto o más importante es la calidad con que esto se haga o tener capacidad para decidir cuándo hay que reutilizar en vez de escribir.

Quizás, por poner alguna pega, echo en falta un par de factores que a mi entender son fundamentales para aumentar la productividad en el desarrollo, y están relacionadas con la visión global introducida en el artículo citado anteriomente.

En primer lugar, la capacidad de comunicación bidireccional, es decir, ser tanto capaz de entender los mensajes de los usuarios, de analistas, comerciales o cualquier otro grupo de interés, como transmitir claramente mensajes, problemas o cuestiones siempre adaptándose a su interlocutor. Esta es, en mi opinión, una habilidad difícil de encontrar y que puede repercutir de forma muy negativa en la productividad global de un equipo de trabajo. ¿Quién no ha tenido que desechar código por culpa de un malentendido?

En segundo lugar, es fundamental la facilidad de integración en equipos de trabajo. Los desarrolladores trabajando en islas son difíciles de ver, la complejidad del software actual hace que en casi cualquier proyecto tengan que intervenir varias personas colaborando de forma muy estrecha. Además, en una máquina perfecta de producción de software la información y conocimientos fluyen con facilidad, lo cual influye en la productividad de cada uno de los componentes de la misma.

Curiosamente, ninguna de estas dos habilidades son técnicas... Sin duda esto de la productividad es un tema tan interesante como complejo, ¿eh?

21 Comentarios:

LgEaObNrAiReDlO dijo...

Excelente entrada y totalmente de acuerdo, creo que esto va de la mano con el supuesto problema de falta de desarrolladores, las empresas tienen que comprender esto que contás y todo lo que supone, no es más barato mal programador que cobra 1K que uno bueno de 4K.

Anónimo dijo...

Es que tampoco debería cobrar 1K un mal programador.

Un programador aparte de progamador deber ser un "ingeniero" o un "profesional", y debe cobrar más que 1000€ al mes.

Es más, que motivación puede tener una persona que cobra 1K al mes ¿?

Anónimo dijo...

No se a lo que estareis acostumbrados, pero la mayoría no creo que cobremos más de 1000 ó 1200 € y eso si tenemos la suerte de aún siendo programadores, no acabar trabajando de otra cosa. Un saludo

Anónimo dijo...

Lo gracioso es que todo el que lee el artículo se cree que es ese programador especial que vale más que 28 malos.

Me parece gratuita la cifra de 1 x 28, si sólo se dan argumentos de tipo de general, no se pueden dar números concretos. Así que en mi opinión 1 x 27 ó 1 x 304 es también posible.

Anónimo dijo...

No en todas partes es asi. 1000-1200 al mes? Ahora mismo, como programador, me estan pagando unos 500 euros al dia. Esto en una "startup", que suele ser un riesgo, y andan mas flojos de capital, si me fuera a alguna empresa consolidada, podria sacar 600+ euros al dia.

Claro que yo no estoy viviendo en espa~a, cambiara alli? quien sabe.

Anónimo dijo...

Y eso en que pais es??? Porque vamos, me largo para allá ahora mismo....

Anónimo dijo...

¿Se puede ser un buen programador dentro de un mal equipo de trabajo?

Muy interesante tus reflexiones sobre el concepto de productividad en el trabajo de programador. Desde mi experiencia personal, estoy de acuerdo contigo respecto de la dificultad de evaluar a un buen programador como elemento humano final de la cadena de un proyecto informático (en otro tipo de proyectos, este elemento humano final es mucho más controlable menos sofisticado y aporta menos valor)

Creo que el único método para desenredar la madeja es partiendo del concepto de buen proyecto informático: si el proyecto es bueno, es que su PM es bueno, ha habido una planificación/diseño buenos y los programadores han hecho eficientemente su trabajo

Lo que me temo es que, en un país como el nuestro, lo tenemos por mentalidad muy muy crudo. ¿quién no ha visto en su trabajo situaciones como éstas?:
- gente tocándose los güevos todo el día se queda despues de hora para aparentar/cobrar horas extras
- gente echando balones fuera (y sobre todo para abajo)
- proyectos que se hacen deprisa y corriendo y solo evaluados economicamente por un comercial que tira a la baja
- todos, todos, todos queremos salir en la foto
- todos, todos, todos, nos creemos los mejores y los demás son unos inútiles (parece que esto tiene cierto fundamento psicologico, pero los hispanos nos pasamos)

O sea, en trabajos de caracter sofisticado y colaborativos la determinacion de la productividad es muy compleja cuando la carga "humana" es tan grande

Por cierto ¿hace falta titulacion en informatica para ser un buen programador? (en ese caso, yo no lo soy)

Anónimo dijo...

500 euros al dia ... si, en sueñolandia

vitus dijo...

HAy que tener presente que la mejora de la productividad no solo es responsabilidad del programador sino de las condiciones ambientales de la empresa. Cuando a un programador se le proporcionan las herramientas, el entorno y el soporte adecuado mejora su rendimiento. No solo es pagar un buen sueldo, sino de proporcionar un entorno adecuado.

Anónimo dijo...

Hei, buen post, interesante el tema de los factores para la productividad. Gracias :)

Pero añado: me resisto a creer que en españa no pagan como deben porque no hay buenos profesionales! Pienso que es solo por razones de tradicion, poder y picaresca. A mi entender es culpa de los programadores, que aceptan lo inaceptable. Yo, personalmente, prefiero por este orden las opciones ante la injusticia: 1.Emigracion; 2.Paro/Autoempleo;...; 1000.Trabajar por un sueldo injusto.

A Mr.500 euros/ida: (O_o)! no lo veo si no lo creo. Podria usted decir en qué sector del mercado y/o en que pais trabaja????

Anónimo dijo...

A pesar de que la desastrosa situacion de la profesion informatica (y de casi todas las demas) en España pueda hacer pensar lo contrario, una retribucion de 500 euros al dia no es ningun absurdo, aunque eso si en condiciones de cierta precariedad (profesionales independientes, contratos por proyecto, etc) Desde luego que de programador con contrato fijo y eterno en la administracion o en un gran banco no se gana eso. Pero en otras cosas, y siempre con el coste de la precariedad, si que se gana esto: actualmente yo estoy en Turquia y precisamente me ofrecen 400 euros al dia para participar en un proyecto financiado por la Union Europea como programador de JBoss y Oracle.

hebep dijo...

Programar es una obra de arte que debería de pagarse más por la calidad del trabajo, que por las horas que inviertes en él.

Pd: Muy buena entrada

Anónimo dijo...

Muy interesante el artículo, pero un factor que creo importante es el tiempo de entrega del proyecto. Me refiero, por qué se comprometen a entregar un proyecto en 3 meses que en condiciones normales se tardaría 6 meses? Así salen los churros que salen: mejor o peor, todos los informáticos sabemos programar y buscar soluciones al problema, pero este factor influye mucho en la posible calidad del sw.

Anónimo dijo...

Leo en el blog de J.M. Aguilar un interesante artículo en el que habla sobre programadores, y productividad, en el que explica que un buen programador puede ser entre 10 y 28 veces mas productivo que uno “”malo”",

Anónimo dijo...

Yo estoy en 3K€/mes, por programar en Perl...

Si renegociara el contrato, estaría en 5,5K€/mes...

Pero si me fuera a Londres, podría llegar más de 7K€/mes (de hecho, ya estoy aprendiendo inglés londinense).

Anónimo dijo...

Lo que más he apreciado es la legibilidad del código, creo que es lo más importante frente al mantenimiento.
Lo otro es que los mensajes de error sean muy claros, y ayuden a depurar el programa mostrando algunos datos clave.
Y suele ocurrir que algunos errores de programa pueden preverse y generar también un mensaje.
Y es fundamental un análisis muy cuidadoso del sistema, que eleva la productividad en gran medida haciendo la programación casi automática.
Desgraciadamente las especificaciones suelen darse de mala gana, como si el analista tuviera la bola de cristal y sólo preguntara por molestar.

Anónimo dijo...

Hola,

a esa gente que trabaja por cualquier suelgo, un programador con un año de experiencia cobra unos 24.000€ al año, mirad ofertas de trabajo por favor. Si cobrais menos, una de dos, u os estáis dejando timar o sois malos programadores y deberíais buscaros la vida en otro tipo de trabajo que no sea escribir líneas de código.

Perdón por trollear, pero me gusta que se valore mi trabajo, si no me valoran, me voy a otro sitio mejor lo antes posible, y hay no me sirve la excusa de la hipoteca.

No os estanqueis, progresad, nunca dejéis de aprender, haced caso del artículo, ser un buen programador es darle al cliente lo que no sabia que necesita.

Un saludo

Motxileros dijo...

Hola a todos,

estoy de acuerdo en la mayoría de comentarios escritos aquí así como en el post (muy bien).

Es por ello que me gustaría hablar de un tema que no se ha comentado aquí, al menos explícitamente. Se trata de la evolución profesional del programador. Me explico. Yo, como desarrollador, tengo mis inquietudes profesionales, hambre de aprender nuevas tecnologías aplicables a proyectos. El caso es que en muchos proyectos el programador requiere de un tiempo para pensar, analizar y probar cual es el mejor entorno de producción para ese proyecto. Este precioso tiempo para la empresa (y para el programador) casi nunca existe en la realidad con lo cual te tienes que apañar con lo que sabes. Al final al cabo de un tiempo te das cuenta de tu propio estancamiento profesional y que no haces más que darle la vuelta a las mismas tecnologías y soluciones propuestas con anterioridad y que has gastado un tiempo precioso de tu formación como profesional en algo que a día de hoy no es lo óptimo (aunque si funcional).
Sin duda, aunque parezca mentira, esto afecta a la productividad. Supuestamente, si siempre utilizas una misma solución debería acarrear una disminución del tiempo en el desarrollo, pero en verdad, lo que acarrea es desilusión y una baja calidad en el producto final.
Toda persona que se defina como "desarrollador de software" creo debería tener un espacio para el auto-aprendizaje dentro de la empresa. Ya no digo un I+D constante pero si que se le debería permitir invertir tiempo en buscar mejores soluciones y más profesionales.. Esto conllevaría una mejora de la productividad, un mejor ambiente de trabajo y como no, tener a un programador contento con su puesto de trabajo (de momento, no me atrevo a comentar cuánto debería cobrar).

Un saludo.

Anónimo dijo...

No hay forma de hacer que alguien sea un buen programador, se tiene o no se tiene el telento.
Totalmente de acuerdo con que programar es arte.
http://gpitech.wordpress.com/
PD: EXELENTE ARTICULO !!!!!

Anónimo dijo...

100% Identificado con el articulo y los post, especialmente con Oscar.
Aca en Buenos Aires en promedio gano unos 761 euros como analista programdor por mes. Totalmente de acuerdo con el tema de que los programadores siempre vamos corriendo detras de la tecnologia lo que a mi entender a veces es por un tema puramente marketinero, o sea "esto es nuevo y es mejor que lo anterior, porque asi,asi y asi,.... y si logra el apoyo de alguna universidad de renombre y con algunos comentarios de "gurues" al respecto, ya todo lo anterior "no sirve" y hay que capacitarse en el ultimo grito de la moda.
Saludos

Anónimo dijo...

Los que no os creéis que se pueden ganar 500EUR/día (fuera de España, claro) creando software, os merecéis lo que ganáis (seguramente será entre 800 y 1200 al mes), por una razón muy sencilla: No conocéis el mundo del desarrollo de software fuera de vuestra ciudad, y eso demuestra gran miopía y una alcance de miras bastante corto. Yo no pagaría un salario decente a alguien así, así que vuestros jefes os remuneran correctamente xDD

P.D: mirad cualquier web de empleo en UK o USA: 300-500 por día es bastante normal.