El valor de un buen programador

Hacía mucho tiempo que no escribía ninguna entrada por aquí, y creo que la entrada que he encontrado va a resultar muy interesante para muchos.


10 Developers For The Price Of One

O lo que es lo mismo... '10 Desarrolladores por el precio de uno'. Os dejo aquí la traducción...

Traducción
En el 'Mítico Hombre Mensual', Fred Brooks destaca una llamativa disparidad entre los buenos y los malos programadores.

Los Directores (o Managers) de Desarrollo han reconocido que existe una gran variación de productividad entre los buenos programadores y los malos. Pero las actuales medidas de magnitud nos han dejado a todos pasmados. En uno de sus estudios, Sackman, Erickson y Grant estuvieron midiendo el rendimiento de un grupo de experimentados desarrolladores. Dentro del grupo, el ratio entre los mejores y los peores rendimientos medios estuvo sobre 10:1 en medidas de productividad y un sorprendente 5:1 en la velocidad de programación y la medida de espacio (tamaño del código).

Robert Glass cita la investigación que muestra esta disparidad aún mayor en su libro 'Hechos y Falacias de la Ingeniería del Software'.

Los mejores programadores son hasta 28 veces mejores que los peores programadores, de acuerdo a la investigación de 'diferencias individuales'. Dando esto que su paga nunca está en consonancia, ellos son la mejor gana en el campo del Software.

En otras palabras, los mejores desarrolladores están, generalmente, mal pagados y los peores demasiado bien pagados.

Pero no dejes todavía tu trabajo. Esto no significa que deba haber una correlación 1 a 1 entre productividad y paga. Que la gente fuese pagada en función de su aportación y productividad es solo una parte de su propuesta de tasación, aunque es una gran parte de ella. Incluso así, deberíamos esperar ver alguna clase de correlación entre la paga y la tan drástica diferencia de productividad. Pero en general, no la vemos. ¿Y por qué es así?


Pues es porque la mayoría de Directores (o Managers) no creen en esta disparidad de productividad, pese a los múltiples y repetidos estudios que lo verifican. ¿Por qué deberían de permitir que los hechos se interpongan en sus creencias? Eso solo significaría que los defensores de los hechos (factonistas en el original) han ganado.

Bromas aparte, ¿por qué es esta diferencia de productividad tan difícil de creer?... Permitirme que ponga palabras en la boca de un Director cualquiera (straw-man: hombre de paja, manager, en el original).

Bien... ¿cómo puede haber un desarrollador en el mundo capaz de escribir código 28 veces más rápido que otro desarrollador?

Esta clase de pensamiento, representa una falacia común cuando se viene a medir la productividad de un desarrollador. La productividad no son unas cuantas líneas de código. Un enorme montón humeante de código que no logra el trabajo hecho, no es productivo. Hay muchos aspectos en la productividad del desarrollador, pero todos se caen bajo un principio principal (tomando prestado un término de la industria financiera), TCO.

TCO - Total Cost Of Ownership.

En general, siempre he intentado tener a los mejores desarrolladores que he podido encontrar. Pero he cometido errores con anterioridad. Sí, incluso yo.

Una situación que me viene a la mente, fue con un desarrollador que había contratado (bajo un montón de presión para contratar a todos los que pudiese) como formador de la compañía. Entregúe a este compañero un Proyecto para que lo llevase. Unos cuantos días después pasé por allí y no escuché nada del tío, así que asumí que las cosas estaban yendo bien.

Dejé pasar unos días y pasé a ver cómo iba la cosa, y el desarrollador me dice que no entiende algunos requisitos y que ha estado haciendo un esfuerzo tratando de entenderlo todo este tiempo.

Los buenos desarrolladores lo toman como propio, así que tú no tienes que hacerlo.

Esta es una de las primeras formas en que los buenos desarrolladores son más productivos que los desarrolladores medios. Ellos hacen suyo el proyecto. En lugar de gastar una semana haciendo esfuerzos porque no entienden un requisito, un buen desarrollador toma decisiones y arroja algo de claridad.

Igualmente, un buen desarrollador no requiere que le des un empujoncito a cada momento para asegurarte de que están progresando. Si se atascan demasiado en un problema, ellos irán a ti o sus compañeros de trabajo para resolver el problema.

Un desarrollador que puede escribir código rápido, pero no toma como propios sus proyectos no es muy productivo, porque acaban malgastando tu tiempo.

Los buenos desarrolladores escriben código con menos errores.

Una vez trabajé con un desarrollador que venía avalado por mi jefe por ser extremadamente rápido escribiendo código. ¡Y desde luego que era rápido! Pero también lo era para meter 'bugs' en el código. Su código era descuidado y difícil de entender.

La medidad clave que no figuraba en su medida de productividad era la cantidad de productividad perdida por el equipo de QA, intentando reproducir errores introducidos en su código, junto con el tiempo gastado en arreglar estos errores por otros desarrolladores.

Todos se enfocan en su tiempo para la 'terminación', pero no en el coste total de propiedad de ese código. El código no está completo cuando un desarrollador dice que está completo. No es el momento de parar el cronómetro. Es cuanado QA ha dado su SI cuando puedes parar el cronómetro, por el momento.

Como me gusta decir, la productividad no trata de correr mucho (speed en el original). Trata de velocidad media (velocity en el original). Tú puedes ir rápido, pero si vas en la dirección errónea, no estás ayudando a nadie.

Los buenos desarrolladores escriben código mantenible.

De la mano con el escribir menos errores, está el escribir código entendible y mantenible. Tran pronto como una línea de código aparece en pantalla, estás en modo mantenimiento sobre esa línea.

El código que es frágil y difícil de cambiar, malgasta horas y horas de ciclos de desarrollo cuando intentas enmendar un sistema con actualizaciones y nuevas funcionalidades. Escribiendo código mantenible, un buen desarrollador puede hacer estos cambios más rápidamente y también aumenta la productividad de su equipo, quien más adelante tendrá que trabajar con ese código.

Los buenos desarrolladores hacen más con menos código.

Otro sello distintivo de un buen programador es que saben cuándo no escribir código. Como un amigo siempre dice

¿Por qué construir cuando puedes comprar? ¿Por qué comprar lo que puedes tomar prestado? ¿Por qué tomar prestado lo que puedes robar?

Salvo unas cuantas excepciones, el síndrome NIH (Not Invented Here-No inventado aquí) es un asesino patológico de la productividad. He visto a desarrolladores comenzar a escribir sus propios frameworks para la validación de formularios hasta que les he apuntado que ya hay uno escrito en ASP.NET que hace el trabajo (No es perfecto, pero es mejor que el que les he visto escribir).

Todo ese tiempo gastado reinventado la rueda se ha perdido porque alguien ya había escrito ese código para ti. Y en muchos casos, hizo un trabajo mejor porque era su único objetivo. En tal situación, encontrar una librería existente que nos de el trabajo hecho puede darnos un enorme impulso a la productividad.

La advertencia en este caso es ser cuidadoso y evitar las librerías no extensibles y rígidas de terceras partes, especialmente para requisitos muy especializados. Puedes perder un montón de tiempo intentando meter una ficha redonda en una caja cuadrada.

Incluso cuando tú debas inventar aquí, los buenos desarrolladores tienden a escribir menos (pero todavía legible) código que hace más. Por ejemplo, en lugar de escribir una máquina de estados para parsear texto de un gran String, un buen desarrollador puede usar una expresión regular (Ok, alguno dirán que un regex no es legible. Pero es más legible que miles de líneas de texto de código de parseo).

De vuelta al TCO

Cada una de estas características que he listado, mantienen el coste total de propiedad de un buen desarrollador bajo. Por favor, no dejen que el término 'propiedad' les distraiga. A lo que me refiero aquí es al coste para la compañía de tener al desarrollador en nómina.

Por escribir menos código que hace más, y por escribir código mantenible que tiene menos errores, un buen desarrollador resta presión a la plantilla de QA, compañeros de trabajo y dirección, incrementando la productividad de todos. Esto es por lo que los números como 28 veces productivo son posibles y pueden incluso parecer poco cuando miras el total.

Espero que esta perspectiva convencerá a los directores de que los buenos desarrolladores realmente son tan productivos como los estudios muestra. Negociar un incremento del salario de 28x, es un ejercicio que dejo a los lectores.


Conclusión

Como podeis ver, el artículo da una buena visión de la importancia de tener buenos desarrolladores (que no programadores) en plantilla para afrontar un proyecto con garantías.
Y sobre todo, nos expone con claridad que la productividad no solo se debe medir por el número de líneas de un desarrollador, ni solo en el tiempo exclusivo de desarrollo.

Y si bien es cierto que a un buen programador no se le puede pagar 28 veces el salario de uno malo, sí que es importante saber reconocer a un buen desarrollador y pagarlo debidamente en función de lo que aporta en términos de productividad al proyecto, al equipo y a la dirección.

Y olvidarnos así, de una vez por todas, de esas falsas premisas de que todo el mundo desarrolla igual y por tanto a todos se les paga igual. Es decir, un desarrollador no es un operario de una máquina, que sabe cuándo pulsar los botones correctos... es más bien, como un pintor que crea con sus pinceles, y por tanto podemos tener a un pintor más... o a un Leonardo Da Vinci.