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’.

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

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.

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 sólo significaría que los defensores de lo empírico han ganado.

¿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.

Componentes del TCO (Total Cost Of Ownership):

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

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. Entregué a este compañero un Proyecto para que lo llevase. Unos cuantos días después pasé por allí y no escuché consulta alguna de su parte, 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.

2 – Los buenos desarrolladores escriben código con menos errores

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.

3 – Los buenos desarrolladores escriben código mantenible

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 cuando 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. Trata de velocidad media. Tú puedes ir rápido, pero si vas en la dirección errónea, no estás ayudando a nadie.

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.

4 – 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.

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í (NHI), los buenos desarrolladores tienden a escribir menos código (pero todavía legible) 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).

Conclusión

Cada una de estas características que he listado, mantienen el costo 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 costo 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.