¿Cómo haría mi producto si lo empezara desde cero otra vez?

Pequeño, rápido, simple y sin complicaciones.

Ya es demasiado complicado desarrollar productos como para querer abarcar más de lo que puedes. Hay una frase de Juan, el CTO de Clevergy, que me gusta mucho:

Hacer cosas pequeñas hace que borrarlas, cuando no sirven, sea más fácil.

Cuántos proyectos de 6 años al acabar se tiran. Demasiado pocos. Es más probable que la empresa termine de quebrar a que el proyecto se elimine. Sin embargo, cuando son unas horas de trabajo, duele menos. Borrar en sí no es bueno, lo importante es borrar aquellas cosas que no aportan valor al producto. Esas ideas de bombero que se nos vienen a la cabeza y que, al ponerlas delante del usuario, nos damos cuenta de que ni las querían ni las quieren.

En el artículo de Eduardo Ferrero Basal Cost of Software, Eduardo expone los principales motivos por los que añadir más funcionalidades tiene la consecuencia negativa de aumentar las dependencias dentro del producto y hacer que el equipo vaya más lento. Hace una analogía entre el metabolismo basal del cuerpo y el metabolismo basal de desarrolladores que tiene un equipo con un producto ya desarrollado.

Hay personas que piensan que programar es como hacer una pared de ladrillos, y que cada línea de código es un ladrillo más. En este paradigma, hay programadores que programan mejor sus líneas de código, dando lugar a paredes bien alineadas, y, sin embargo, hay otros programadores que programan con desgana. Por eso, se reafirman, cuando tienes programadores que programan desganados, aparecen bugs, la aplicación va lenta y otros muchos problemas. Pero no es así. El código evoluciona, no se queda quieto entre el cemento. La variable que hace dos meses confirmamos que sería “rojo” o “verde” ahora tiene que poder llamarse “amarillo”. Y este problema es el que hace que, más que una pared de ladrillos, se parezca a un malabarista con pelotas. Hacer malabares con una pelota es muy fácil; con dos empieza a complicarse, con catorce pelotas, la cosa se pone chunga.

Borrar nos permite coger la pelota más fea de las que están en el aire y quitarla, haciendo que nuestro juego de manos vuelva a ser elegante y no forzado. También nos permite evitar que otras pelotas más frágiles se rompan. Hay veces que incluso podemos permitirnos quitar una naranja o un plátano que algún cliente nos coló. Esta analogía se traduce en una frase en concreto que a las personas de negocio no nos gusta nada:

Hay que refactorizar

Cuando haces las cosas rápido, quieres aprender si una funcionalidad va a ser utilizada o no. Y para eso, tomar atajos es lícito. Esos atajos implican que dejas de programar para casos que no sabes si ocurrirán. Por ejemplo, los riesgos pueden ser altos (rojo) o bajos (verde), hasta que llega un cliente que te pregunta por qué no puede asignar el riesgo medio (amarillo) a un proyecto. Qué hay que cambiar:

• Que el API pueda recibir el valor amarillo

• Que la base de datos pueda guardar el valor amarillo

• Que el API pueda devolver el color amarillo

• Que en la aplicación aparezca un 🟡

Son una serie de cambios que toca programar. Otro motivo que puede llevar a una refactorización es el rendimiento. A la hora de lanzar un cálculo o unas peticiones entre sistemas, puedes asumir que no habrá más de 5 usuarios a la vez realizando la misma petición al servicio. Si esa funcionalidad empieza a crecer, es normal que el uso aumente y:

• Un día aparecerán incoherencias en base de datos porque las peticiones tardan mucho en guardarse

• O la pantalla tardará mucho en cargar porque no hay suficientes recursos asignados

• O se perderán datos en unas operaciones en base de datos, porque esa funcionalidad bloquea la base de datos y no se había tenido en cuenta ese caso

A casi todos los motivos que se pueden explicar sobre por qué hay que refactorizar, siempre hay algún comentario atrevido que sugiere:

¿No podríamos haber pensado esto mejor?

A todos ellos les quiero tranquilizar diciendo: Claro que sí. Siempre se pueden pensar mejor las cosas, casi siempre se pueden anticipar este tipo de problemas, siempre se pueden programar algunos casos límite más para tenerlo todo controlado. De hecho, se pueden pensar pruebas de uso que estén detalladas y que al terminar el desarrollo se puedan evaluar cada uno de esos casos de uso. De esta forma se podrá verificar que la funcionalidad ha sido desarrollada a la perfección para todos y cada uno de los casos de uso detallados.

Esto hace que la funcionalidad tarde más en ser desarrollada y que el proyecto, en vez de dos semanas, acabe durando 6 meses. Y cuando hemos llegado a esos 6 meses de duración para sacar esa funcionalidad que nadie usa, ¿quién será el valiente que pida tirar todo ese trabajo a la basura?

Yo no. Por eso digo que a mí me gusta desarrollar cosas pequeñas, rápidas y simples. Vamos, sin complicaciones.