Introducción

Si te guardas un papel para no ensuciar la playa estás haciendo lo correcto. Pero lo realmente meritorio es estar en una playa llena de basura y, aun así, andar 20 metros para tirar el papel en una papelera que siempre está vacía.

La calidad del código

Cuando explico a mis alumnos los temas relativos a la calidad del código, los principios arquitectónicos SOLID, tests unitarios, code review y, en general, todo aquello que podemos considerar guías de buenas prácticas para el desarrollo de software, siempre les hago ver dos cosas:

La primera es que seguir estas guías debe interpretarse como una inversión. Para poder implementarlas, empleamos una cantidad importante de tiempo y esfuerzo en el presente y esperamos un retorno en el medio y largo plazo en forma de un código más legible, menos incidencias que además se resuelven con menos esfuerzo, un proyecto mejor preparado para para enfrentar evolutivos y cambios en las especificaciones y, finalmente, un entorno de trabajo más amable con menos sobresaltos y estrés.

La segunda es que seguir esas reglas supone hacer un ejercicio de bonhomía, en el sentido de que con frecuencia -no siempre por fortuna- te vas a encontrar haciendo un esfuerzo en beneficio de tus compañeros, sin que otros lo hayan hecho antes por ti y con pocas esperanzas de alguien lo valore y, siguiendo tu ejemplo, lo haga en el futuro. Definitivamente hacer las cosas bien te define como una buena persona.

La regla del scout nos invita a dejar el campamento un poco mejor de cómo nos lo hemos encontrado, es decir, a que cada vez que entremos a modificar una pieza de software echemos un ojo y procuremos dejarlo algo mejor de cómo estaba previamente o, al menos, no peor.

Pero ¿qué pasa si nos encontramos el campamento lleno de basura, empezamos a limpiarlo y no solo nadie lo valora, sino que nos afean haber llegado tarde a cenar por ello y, cuando finalmente el campamento está en orden, tenemos que irnos sospechando que pronto estará hecho un desastre otra vez? Dicho de otra manera ¿qué hacer si el código es ilegible, cuando queremos arreglarlo nos tratan como si perdiésemos el tiempo y finalmente, al cambiar de empresa o proyecto, nos vamos sabiendo que nadie seguirá nuestros pasos y todo volverá a estar como antes?

Si ante esta pregunta tu respuesta es que seguirás perseverando en tus esfuerzos por hacer del mundo (al menos tu mundo como desarrollador) un lugar mejor, solo me cabe decir que eres, ya no una buena persona, sino un santo digno de ser elevado a los altares. Y es que, reconozcámoslo, la mayoría no tenemos alma de mártir y, lo habitual, es dejarse llevar por la desidia y el cortoplacismo y convertirnos en uno más de los que ensucian en vez de limpiar.

Lo paradójico de todo esto es que la mayoría de los desarrolladores somos conscientes de que esta actitud nos acerca al desastre. Los programadores están cada vez mejor formados, conocen los beneficios de aplicar estas guías de buenas prácticas, reconocen que aplicarlas es algo que mejora substancialmente el desarrollo de los proyectos y el entorno profesional en que nos movemos y, sin embargo, la dinámica del trabajo diario parece empujarles a ignorarlas.

Todos sabemos que “hacer las cosas bien” es algo que nos beneficia a todos en el medio y largo plazo. Pero al mismo tiempo sabemos que hay que sembrar, aunque no siempre somos nosotros lo que vamos a recoger y es inevitable, siguiendo misma la metáfora, que algunos piensen en no sembrar y recoger y otros piensen que si siembran, los demás se aprovecharán de ello.

Si nos fijamos detenidamente en lo que acabamos de afirmar, podemos observar ciertas similitudes, salvando las distancias, con los conocidísimos problemas del “dilema del prisionero” o “la tragedia de los comunes”. Y es que en ambos problemas nos encontramos en una situación en la que todos los actores reconocen que seguir una determinada estrategia optimiza los resultados, pero un análisis individual de la situación parece empujar a todos inexorablemente a seguir la estrategia contraria (bien para aprovecharse del buen hacer de los otros, bien por temor a que los otros se aprovechen del suyo) y en consecuencia al desastre.

Llegados a este punto ¿qué podemos hacer para escapar de lo que parece ser un círculo vicioso? En los dos problemas que acabamos de mencionar, la solución pasa por establecer algún tipo de arbitraje, incentivar la cooperación y penalizar las actitudes individualistas que van en contra del “bien común”.

En el caso de las buenas prácticas en el desarrollo de software, podríamos aplicar el mismo razonamiento e incentivar la adopción de dichas prácticas. Pero, dado un equipo que trabaja en un proyecto concreto ¿cómo lograr desincentivar la obtención de resultados a corto plazo en favor de un desarrollo sostenible a largo plazo?

Una opción es apelar a la responsabilidad individual y la profesionalidad de los desarrolladores. La ventaja de este enfoque es que las personas solemos responder mejor ante este tipo de estímulos que ante la imposición. La desventaja es que nos sitúa en una suerte de equilibrio inestable, de manera que si cualquier miembro del equipo se desvía del buen camino puede hacer que todo se desmorone en cascada y volvamos todos a “las andadas”.

La otra opción, seguramente más sólida, es establecer reglas de obligado cumplimiento por parte de todo el equipo o toda la organización. Establecer reglas no supone necesariamente “sacar el látigo”; de hecho, nuestro día a día está repleto de reglas que cumplir sin que nos sintamos agredidos por ello. Sin embargo, para que esta estrategia funcione es necesaria una condición sine qua non: Todos los responsables del proyecto y de la organización deben estar convencidos cual es la manera más adecuada de trabajar; no vale aceptarlo sin más, han de estar plenamente convencidos y defender esa manera de hacer ante las resistencias que, sin duda, van a surgir.

Y es que con frecuencia se hace hincapié en la necesidad de concienciar a los desarrolladores de las bondades del clean-code, clean-arquitecture, SOLID y demás técnicas para mejorar la calidad de software. Pero pocas veces se hace igual hincapié en convencer a los responsables de los proyectos y, mucho menos, en educar a los clientes para que entiendan que la calidad del proyecto es mucho más que pulsar un botón y que aparezca en pantalla lo aparentemente esperado.

De nada sirve convencer a un equipo de programadores de que hay que cuidar el código, si a la hora de la verdad se hace tabla rasa y se reparten las felicitaciones con el equipo responsable de otra parte del proyecto que no ha hecho ese ejercicio de calidad y no ha pagado el peaje de hacerlo, pero se ha beneficiado de las buenas prácticas de los primeros.

Tampoco sirve de nada decirle a un desarrollador que debe hacer tests unitarios, si su jefe de proyecto no está concienciado de que eso supondrá de inicio un esfuerzo extra y le exige a corto plazo como si no los hiciese. O si a las primeras de cambio cede ante las presiones de los clientes y, en lugar de explicar a estos últimos los beneficios de tener una codificación sólida y un proyecto ordenado, decide cortar por lo sano y decir a su equipo que se olviden de los tests en la siguiente entrega.

Conclusiones

Por último, como me ha recordado recientemente el CEO de DevAndDel (nuestra empresa matriz), debemos saber que aquello que no se mide es imposible de mejorar. Implementar políticas de calidad debe ir acompañado necesariamente de métricas, de un seguimiento de los proyectos y de medidas correctoras cuando sea necesario. De nuevo, para que todo esto sea posible, es necesario que los responsables de la organización estén plenamente convencidos de la necesidad de andar esta senda.

¿Te ha parecido interesante lo que te he comentado? Puedes leer más artículos relacionados en: