En el libro "
The Mythical Man-Month", Fred Brooks señala una asombrosa disparidad de producción entre los buenos y los malos programadores.
Los encargados de programación han reconocido amplias variaciones de productividad entre los buenos programadores y los malos. Pero las magnitudes medidas han asombrado a todos nosotros. En uno de sus estudios, Sackman Erickson y Grant midieron el rendimiento de un grupo de programadores con experiencia. En este grupo los ratios entre los mejores y peores rendimientos fue sobre 10:1 en medidas de productividad y 5:1 en medidas de velocidad de programación y espacio requerido.
Robert Glass cita la investigación que pone esta disparidad más de manifiesto en su libro
"Facts and Fallacies of Software Enineering".
Los mejores programadores son hasta 28 veces mejores que los peores programadores, de acuerdo a la investigación "diferencias individuales". Dado que su pago no es comensurado, son los mayores negocios en el campo del software.
En otras palabras, los mejores desarrolladores a menudo están
mal pagados mientras que los peores son los que mejor pagados están.
Pero no abandones tu trabajo ahora. Con esto no quiero decir que deba haber una relación 1:1 entre productividad y pago. Las personas deberían ser pagadas por el valor que traen y la productividad, aunque no lo es todo, es una parte importante. Incluso podríamos esperar ver bastante correlación en el pago con una diferencia drástica de productividad. Pero en general, no lo hacemos. ¿Por qué?
Porque la mayoría de los encargados de programación no creen esta disparidad de productividad a pesar de la comprobación repetida por múltiples estudios. ¿Por qué permiten que los hechos se ajusten a sus creencias? eso sólo puede significar que los factonistas han ganado.
Bromas aparte, ¿por qué es tan difícil de creer esta diferencia de productividad? permítame poner palabras en la boca de un mal encargado de programación:
"¿Cómo un desarrollador puede escribir código 28 veces más rápido que otro desarrollador?"
Este tipo de pensamiento representa una falacia común cuando medimos la productividad de un desarrollador. La productividad no es el número de líneas de código. Una enorme pila de código que no hace bien el trabajo no es productiva. Hay muchos aspectos que influyen en la productividad de un desarrollador, pero todos están gobernados por un principio (tomemos prestado un término de la industria de finanzas): TCO.
TCO (Coste total de la propiedad)En general siempre he tratado de contratar a los mejores programadores que puedo encontrar. Pero he cometido errores anteriormente. Si, incluso yo.
Una situación que me viene a la mente con un desarrollador que contraté (debo añadir que bajo mucha presión) para una empresa anterior. Le di trabajo a este compañero para que asumiera el control del proyecto. Al cabo de unos pocos días no se nada de esta persona, así que suopngo que las cosas están marchando bien.
Al cabo de otros pocos días me dejo caer por allí para ver como marcha el proyecto y el desarrollador me comenta que no comprende algunos requisitos y ha estado intentando comprenderlo todo este tiempo.
Los buenos desarrolladores toman la propiedad de forma que no tengas que hacerlo túEste es uno de los primeros aspectos en los que los buenos desarrolladores son más productivos que los desarrolladores mediocres. Ellos toman la propiedad del proyecto. En vez de gastar una semana dándole vueltas a un requisito que no comprenden, los buenos desarrolladores se comunican con el que toma las decisiones y sacan cosas en claro.
De forma similar, un buen desarrollador no requiere que lo supervises a cada momento para asegurarse de que está progresando. Si se encuentran con un problema que le trae complicaciones irá a tí o a sus compañeros de trabajo y resolverán el problema.
Un desarrollador que puede escribir código rápidamente, pero no toma la propiedad de sus proyectos no es muy productivo porque acaba desperdiciando TU tiempo.
Los buenos desarrolladores escriben código con menos bugsUna vez trabajé con un desarrollador elogiado por mi jefe por ser extremadamente rápido escribiendo código. Seguro que era rápido! tambien lo era introduciendo errores en el código. Su código era lento y difícil de entender.
La medida clave que no fue tenida en cuenta en su productividad fue la cantidad de productividad perdida para intentar reproducir los errores que este desarrollador introdujo en su código, junto al tiempo gastado arreglando esos errores por este u otros desarrolladores.
Todo el mundo centró sus esfuerzos en terminar la tarea, pero no en el coste total de propiedad de ese código. El código no está terminado cuando un desarrollador dice que está terminado. No es ese el momento de parar el cronómetro. Lo es cuando el equipo de calidad dice que el proyecto está completado temporalmente.
Como me gusta decir, la productividad no es la velocidad. Tiene que ver con ella. Puedes ser rápido, pero si vas en la dirección equivocada no estás ayudando a nadie.
Los buenos desarrolladores escriben código fácil de mantenerDe común acuerdo escribiendo menos errores es escribir código entendible y mantenible. Tan pronto como una línea de código es escrita, estás realizando el mantenimiento de ese trozo de código.
El código que es frágil y difícil de cambiar desperdicia horas y horas de ciclos de desarrollo cuando tratamos de enmendar un sistema con actualizaciones y nuevas funcionalidades. Escribiendo código mantenible, un buen desarrollador puede hacer estos cambios de forma más rápida y mejorando también la productividad de los miembros de su equipo que más tarde tienen que trabajar con ese código.
Los buenos desarrolladores hacen más con menos códigoOtra característica de un buen desarrollador es que sabe cuando no hay que escribir código. Como siempre me dice un amigo:
"¿Por qué construir lo que puedes comprar? ¿Por qué comprar lo que puedes tomar prestado? ¿Por qué tomar prestado lo que puedes robar?"
Con unas pocas excepciones, el síndrome NIA (no inventado aquí) es un asesino patológico de la productividad. He visto a desarrolladores empezar a escribir su propio entorno de formularios de validación hasta que señalo que hay uno hecho actualmente en ASP.NET que hace el trabajo (no es perfecto, pero es mejor que el que vi que se estaba escribiendo).
Todo ese tiempo desperdiciado reinventando la rueda es desperdiciado porque alguna otra persona ha escribo el código para tí. Y en muchos casos, hizo un mejor trabajo ya que se centraba concretamente en ese objetivo. En una situación de este tipo, encontrar una librería que hace el trabajo puede proveernos de un gran impulso para la productividad.
La advertencia en este caso es ser cuidadoso para evitar rígidas y no extensibles librerías ajenas, especialmente para requisitos muy especializados. Puedes gastar mucho tiempo intentando meter a una mascota redonda en una caja cuadrada.
Incluso cuando debes inventar, los buenos desarrolladores tienden a escribir menos código (pero de forma legible) que hace más. Por ejemplo, en vez de construir una máquina de estados que analice texto de una cadena grande, un buen desarrollador puede usar una expresión regular (de acuerdo, algunos dirán que una expresión regular no es legible. Incluso más legible que cientos de lineas de código de análisis de texto).
Vuelta a TCOCada una de estas características que he listado mantienen el coste total de propiedad bajo en un buen desarrollador. Por favor, no dejes que el término propiedad te distraiga. A lo que me refiero es al coste de la empresa de tener un desarrollador así en nómina.
Escribiendo menos código que haga más, y escribiendo código mantenible que tiene menos errores, un buen desarrollador elimina presión al departamento de calidad, trabajadores y encargados, incrementando la productividad de todos. Por esto es por lo que expresiones como "28 veces más productivo" son posibles y pueden incluso parecer bajas cuando lo consideras desde un más alto nivel.
Esperamos que la visión de esta perspectiva convenza a encargados de que los buenos desarrolladores realmente son tan productivos como muestran los estudios. Negociar un incremento de pago 28 veces superior es un ejercicio que dejamos al lector.
