Seguramente la mayoría recuerden esta película por la icónica marcha que silbaban los soldados británicos internados en el campo de prisioneros japonés y cuyo trabajo, consistía en construir un puente ferroviario sobre el río Kwai en tan solo 13 semanas.

Hace poco, viendo la película, reparé en la cara de asombro primero y desazón después, que pone el coronel Saito -jefe del campo- cuando el coronel Nilcholson -oficial prisionero de mayor rango- le informa que los pilares se están colocando sobre un tramo fangoso del río y, por tanto, no aguatarán el paso del tren. Desgraciadamente hay que empezar de nuevo, provocando un enorme retraso en las obras. En aquel momento no pude sino maliciarme que el jefe del proyecto habría pensado “para estudios topográficos estoy yo, que tengo que entregar en 13 semanas. Ya haremos todos eso cuando haya tiempo, si es que lo hay”.

Si un moderno coronel Saito, encargado de construir el puente de una autopista, plantease empezar a poner pilares de hormigón saltándose todos los estudios previos para poder ahorrar tiempo y entregar en plazo, nos llevaríamos las manos a la cabeza.

Pues bien, eso es algo que durante el desarrollo de software ocurre con cierta frecuencia; que los responsables de los proyectos aboguen por eludir tareas que consideran superfluas, tales como la codificación de test o ignoren la necesidad emplear tiempo en implementar buenas prácticas de desarrollo, todo ello en aras de entregar el producto en plazo, no es una rareza. Es más, frases como “ya le meteremos al cliente el sablazo en forma de mantenimiento correctivo” o “bueno, eso será un problema para mi ‘yo’ del mañana” están a la orden del día.

Ni ganar ni perder tiempo. Invertir tiempo.

Juan y Paco necesitan comprar un coche para ir a su puesto de trabajo. Ambos disponen de 75.000€ para emplearlos como prefieran. Juan decide cumplir su sueño de siempre y darse el capricho de gastarse los 75.000€ en un coche de alta gama; Paco opta por gastar 25.000€ en un buen coche, pero más modesto, y guardar el resto.

Al cabo de un año Juan está asfixiado por los mantenimientos de un coche que está por encima de sus posibilidades, cada vez que tiene que cambiar el aceite o los neumáticos se deja medio sueldo y no dispone de liquidez para ningún imprevisto. Paco dispone de dinero para hacer frente a cualquier imprevisto, es capaz de mantener su coche sin apreturas y vive desahogado.

No se puede decir que uno ha perdido dinero (como si se lo hubiese jugado al póker, por ejemplo) y otro lo ha ganado: el valor de los vehículos está ahí. Lo que sucede es que Juan ha invertido mal su dinero mientras que Paco lo ha invertido bien y ambos padecen o disfrutan, según el punto vista de cada cual, las consecuencias que acarrean sus decisiones.

Si hablamos de la construcción de artefactos software, dicha inversión de los recursos disponibles (en nuestro caso el tiempo) pasa por la adopción de lo que venimos en denominar buenas prácticas de desarrollo que se materializa en la realización de determinadas tareas, la implementación de ciertos protocolos y el empleo del tiempo necesario para garantizar la calidad del código. Algunas (aunque no todas) de estas tareas son:

Llevar a cabo cualquiera de estas tareas conlleva un tiempo extra. El caso de la codificación de los test es evidente, pero incluso elegir un nombre adecuado para las variables lo requiere, dado que se necesita un ejercicio intelectual y un tiempo de reflexión.

Ese es el tiempo invertido y, como cualquier inversión, supone renunciar a la disponibilidad del recurso en el corto plazo a cambio de obtener unos beneficios en el medio y largo plazo. Es decir, emplearemos más tiempo en realizar la funcionalidad que tengamos encomendada, pero a la larga será beneficioso.

Cuando hablamos de economía, realizar una inversión supone renunciar a la disponibilidad de una cantidad de dinero para, pasado un tiempo, recuperar el dinero invertido más unos intereses.

En el caso que nos ocupa, empleamos cierto tiempo para realizar las tareas antes descritas y eso nos va a proporcionar unos réditos a la larga: un software más sólido, un producto de mayor calidad, menores tasas de estrés en las personas involucradas, etc. Y, sobre todo, nos va a devolver tiempo, porque el tiempo así invertido en las primeras etapas del desarrollo, retorna multiplicado hasta por 30 debido tanto a la reducción de incidencias como al menor esfuerzo necesario para abordar las pocas que se produzcan.

Sin embargo, hay una diferencia crucial entre la inversión en términos económicos y la inversión que aquí proponemos: Cuando invertimos dinero, lo normal es que a mayor riesgo se nos prometa mayor beneficio, pero cuando invertimos tiempo en adoptar buenas prácticas de desarrollo el riesgo es siempre mínimo y el beneficio máximo, el éxito de la inversión está garantizado.

Juan y Paco son programadores.

Seguro que más de uno lo sospechaba y así es, ambos desarrollan software en una empresa donde no tienen por costumbre ser demasiado cuidadosos con la calidad del código que realizan ni se preocupan de ‘cosas sin importancia’ tales como codificar test.

A cada uno de ellos se les encomendó hace unos meses desarrollar sendas funcionalidades, que forman parte de un sistema que está instalado y en pruebas por parte del cliente.

Los responsables de la empresa están encantados con Juan, visto su talento han decidido que asuma a partir de ahora más responsabilidades y dicen orgullosos a los programadores junior que Juan es el espejo en el que mirarse, que se fijen muy bien en él y aprendan. En cuando a Paco, pues no todo el mundo puede tener el talento natural que tiene Juan, que se le va a hacer; eso sí, le insisten en que se fije y aprenda de su compañero.

Pues bien, lo cierto es que los jefes de la empresa yerran en el diagnóstico de la situación, porque lo que deberían hacer es proporcionar herramientas y establecer pautas y protocolos que favorezcan buenas prácticas de desarrollo evitando encontrarse tanto en un caso como en el otro.

Espera un momento… ¿tanto en un caso como en el otro? ¿qué tiene de malo lo que ha sucedido con Juan?

Efectivamente, tampoco es deseable la situación de Juan. Evidentemente no hay nada malo en aprovecharse de los momentos de inspiración y mucho menos en exprimir el talento de los miembros del equipo, pero todo esto deben ser elementos de valor añadido y no la base sobre la que se desarrolla proyecto.

En términos financieros: No hay nada malo en que a una familia le toque la lotería o que un directivo tenga una buena idea para hacer ganar dinero a su empresa; lo malo es que una familia fie su porvenir económico en echar la quiniela todas las semanas o que la viabilidad de una empresa dependa de que un directivo tenga una idea genial con la que dar un pelotazo.

La importancia del lenguaje

Durante todo el artículo se ha estado haciendo hincapié en hablar de invertir tiempo (correctamente, por supuesto) en lugar de hablar de ganar o perder tiempo.

Como hemos visto, hay muchas razones para pensar que implementar buenas prácticas de desarrollo es una inversión. Sin embargo, hay una razón aún más poderosa para adoptar este enfoque:

Si interiorizamos que lo relevante es no perder tiempo sino ganarlo, podemos acabar llegando a la conclusión de que las tareas que no nos llevan rápidamente a la consecución del objetivo inmediato que tenemos entre manos son menos importantes y, por tanto, podemos relegarlas: la frase “si no llegamos, le quitamos tiempo a las pruebas funcionales”, es un clásico de este tipo de pensamiento. Los conceptos ganar o perder tiempo evocan el corto plazo. Nos estaremos asomando al abismo.

Por el contrario, invertir evoca el medio y largo plazo, la necesidad de renunciar en el corto plazo al tiempo para poder obtener un beneficio superior en el largo plazo. Evoca la seguridad, la solidez del proceso de desarrollo y la planificación racional del proyecto.

En definitiva, es importante cómo llamamos a las cosas porque así lograremos interiorizar cuál es el camino correcto, evitando tener la tentación de coquetear con ‘el reverso tenebroso’.

Cuantificar el retorno de nuestra inversión

Cuando hablamos de dinero es relativamente fácil saber si nuestra inversión ha sido fructífera, basta con contar el dinero que tenemos antes y después.

Determinar el retorno del tiempo bien invertido en el desarrollo de un proyecto software no es tan inmediato porque no es posible volver atrás para saber que habría pasado en caso de escoger otro camino, tanto para lo bueno como para lo malo.

Algunos estudios estiman que resolver un error en el software es hasta 30 veces más costoso si el error se detecta con el sistema en producción que si se detecta (por ejemplo, gracias a los test automatizados) en las primeras etapas del desarrollo.

No cabe duda que apoyarnos en datos, números y estadísticas es la mejor manera de hacer cualquier evaluación. Pero seamos por un momento algo menos estrictos y pensemos en la nuestra experiencia personal:

Casi todos los que hemos desarrollado software nos hemos tenido que enfrentar al problema de resolver incidencias sobre código que han escrito otros y sabemos lo dificil que resulta si no está escrito de manera cuidadosa, también lo frustrante que resulta que, al modificar cualquier módulo, parezca romperse el programa por otro lado. Invertir en buenas prácticas va precisamente en la línea de evitar estas situaciones que tantos quebraderos de cabeza dan y tanto tiempo y dinero nos hacen, esta vez si, perder.

El siguiente caso es completamente ficticio, no obstante se trata de una situación que puede darse perfectamente en cualquier empresa que desarrolla software. No solo es totalmente realista sino que, seguro, más de un lector se sentirá identificado.

El éxito de Juan acaba en desastre:

Juan ahora asume más responsabilidades y está al cargo de un pequeño equipo que trabaja para un importante cliente de la industria alimentaria. A todos los desarrolladores junior les dice lo mismo: “aquí ni perdemos el tiempo con chorradas ni se lo hacemos perder a nuestros clientes”.

Juan ha recibido un email pidiendo una pequeña modificación: El laboratorio realiza análisis para determinar la presencia de determinadas sustancias en los lotes de alimentos, esas sustancias no deben superar cierto umbral. Los resultados llevan mucha precisión, pero los informes se presentan con dos decimales y el redondeo se está haciendo ‘al más proximo’. El director de seguridad alimentaria solicita que se redondee ‘al superior’, para evitar que la perdida por redondeo haga pasar un lote con niveles ligeramente superiores a los permitidos por válido.

Juan encarga a un desarrollador junior que modifique el método estático que redondea los decimales. El programador lleva a cabo la pequeña modificación, realiza varias pruebas, genera varios informes de laboratorio simulados y verifica que, ahora sí, se redondea al superior y que ningún lote que supera el umbral permitido, aunque sea por muy poco, figura como ‘dentro del rango permitido’.

Al cabo de 20 días, coincidiendo con el final de mes, salta una alarma: El departamente de administración está revisando los importes de los pedidos de los clientes (supermercados, pequeñas tiendas, restaurantes) y no cuadran. Nadie sabe porque está pasando eso.

Al día siguiente una nueva alarma, en este caso es el director de recursos humanos quejándose de que determinados conceptos en las nóminas están mal redondeados. ¡El redondeo! Juan ata cabos.

Es viernes y son las 13:30, el lunes por la mañana tiene que estar resuelto si o si, porque el personal del departamento de ventas va a empezar a elaborar nuevamente los albaranes, a rectificar las cuentas y a llamar a los clientes para disculparse. Después de estar tres personas trabajando el viernes por la tarde y todo el sábado, por fin parece resuelto el problema; han parcheado la aplicación aquí y allá y han comprobado todos los redondeos donde se han acordado pero, por supuesto, no pueden estar seguros de no haberse dejado algún caso y, más de uno, cree que después de estar trabajando a matacaballo y poniendo parches, lo probable es antes o después aparezca otra incidencia similar.

Si analizamos este caso, ficticio pero que es perfectamente posible, podemos sacar varias conclusiones:

Como podemos deducir de situaciones como la anteriormente descrita, invertir tiempo en ‘hacer bien las cosas’ es una práctica que exige disciplina pero que, llegado el momento, nos va a dar enormes satisfacciones.