Hace poco, durante una reunión, un cliente me explicó una funcionalidad que quería incorporar a su web.
Necesitaba que determinados pedidos siguieran un proceso diferente dependiendo del tipo de cliente, del producto comprado y de la provincia de entrega. También quería que el sistema enviara varios correos, actualizara una hoja de cálculo y avisara al responsable correspondiente.
Mientras hablábamos, la solución empezó a crecer.
Un desarrollo a medida en WordPress . Varias condiciones en WooCommerce. Una pantalla de configuración. Un proceso automático conectado con la herramienta de gestión. Registros para comprobar qué había ocurrido en caso de error.
Todo era técnicamente posible.
El problema es que, después de hacer unas cuantas preguntas, descubrimos que aquella funcionalidad solo iba a utilizarse dos o tres veces al mes.
La conversación cambió por completo.
Ya no se trataba de decidir cómo desarrollar el sistema. Se trataba de comprobar si realmente tenía sentido desarrollarlo.
Y no lo tenía.
Terminamos resolviendo el proceso con una automatización bastante más sencilla, una pequeña adaptación en la administración de WordPress y un procedimiento interno que el equipo podía seguir sin dificultad.
El cliente no consiguió exactamente el desarrollo que había imaginado. Consiguió algo mejor: resolver el problema sin añadir una nueva pieza compleja a su proyecto.
Que algo pueda programarse no significa que deba programarse
Como desarrollador, es fácil caer en una trampa bastante curiosa: pensar que todos los problemas se solucionan escribiendo código.
Cuando llevas años trabajando con WordPress, PrestaShop, integraciones, APIs y desarrollos personalizados, casi siempre puedes encontrar una forma de construir lo que te están pidiendo.
Pero poder hacerlo no es el criterio más importante.
La pregunta debería ser otra:
¿Compensa hacerlo?
Cada desarrollo nuevo tiene un coste inicial, pero también genera una pequeña deuda futura.
Hay que mantenerlo, actualizarlo, documentarlo y comprobar que sigue funcionando cuando cambia WordPress, PHP, WooCommerce, PrestaShop o cualquiera de los servicios externos con los que se conecta.
También hay que pensar en los casos extraños.
¿Qué ocurre si una API no responde? ¿Qué pasa si un producto cambia de categoría? ¿Y si el usuario completa el proceso dos veces? ¿Qué sucede cuando dentro de seis meses otra persona modifica una parte de la web sin saber que existe esa dependencia?
"El código que hoy parece sencillo puede convertirse en el problema que alguien tendrá que investigar dentro de dos años."
Y muchas veces ese alguien soy yo.
La funcionalidad visible suele ser la parte más pequeña
Desde fuera, algunas peticiones parecen muy simples.
“Solo queremos añadir un botón.”
“Cuando el cliente haga esto, que se envíe un correo.”
“Necesitamos copiar estos datos automáticamente.”
“Queremos que los precios cambien según el tipo de usuario.”
El problema es que la frase “solo queremos” suele ocultar bastantes decisiones.
Pensemos en el botón.
¿Quién puede verlo? ¿Aparece en móvil? ¿Qué ocurre si el usuario no ha iniciado sesión? ¿El botón ejecuta una acción inmediata o pide confirmación? ¿Qué pasa si el proceso falla? ¿Se puede pulsar dos veces? ¿Hay que guardar un registro? ¿Debe notificarse a alguien?
El botón son veinte líneas de código.
Todo lo que ocurre alrededor del botón es el desarrollo de verdad.
Esto no significa que haya que convertir cada pequeño cambio en un proyecto enorme. Significa que conviene entender las implicaciones antes de empezar.
Después de más de quince años trabajando en proyectos web, una de las cosas que más valoro no es programar rápido. Es detectar pronto cuándo una petición aparentemente pequeña está a punto de generar una complejidad innecesaria.
A veces ya existe una solución, pero está en otro sitio
En una ocasión me pidieron desarrollar un sistema dentro de PrestaShop para exportar determinados pedidos, transformarlos y enviarlos a otra plataforma.
La primera idea era crear un módulo completo.
Habría funcionado. El módulo tendría su propia configuración, un proceso programado mediante cron y un histórico de ejecuciones.
Pero, al revisar la infraestructura del cliente, vimos que ya utilizaban una herramienta de automatización para otros procesos. Podíamos obtener los pedidos a través de la API de PrestaShop, transformar los datos fuera de la tienda y enviarlos desde allí.
La tienda únicamente tenía que hacer lo que ya sabía hacer: gestionar pedidos.
No era necesario añadirle otra responsabilidad.
Esta separación es importante.
Cuantas más tareas distintas acumulas dentro de una web, más difícil resulta mantenerla. Una tienda online no siempre debería encargarse también de procesar documentos, sincronizar hojas de cálculo, enviar avisos internos y actuar como sistema de gestión empresarial.
A veces es mejor que la web exponga los datos y que otra herramienta haga el trabajo.
No porque esté de moda hablar de automatizaciones, sino porque cada pieza queda más aislada. Si mañana cambia el proceso interno, no necesitas tocar el núcleo de la tienda.
También hay que desconfiar de la solución que parece rápida
El extremo contrario al desarrollo a medida es instalar un plugin para cada necesidad.
Necesitas una redirección: plugin.
Quieres modificar el checkout: plugin.
Hace falta añadir un campo: plugin.
Quieres cambiar el envío de correos: otro plugin.
En poco tiempo, una web puede terminar con cincuenta extensiones resolviendo cuarenta problemas pequeños y creando diez problemas nuevos.
No estoy en contra de los plugins. Sería absurdo trabajar con WordPress o PrestaShop pensando que todo debe programarse desde cero.
Un buen plugin puede ahorrar semanas de trabajo y ofrecer una solución mucho más probada que un desarrollo nuevo.
La cuestión es elegirlo con criterio.
Antes de instalar uno suelo revisar qué partes de la web modifica, con qué frecuencia se actualiza, si almacena datos propios, si depende de servicios externos y qué ocurriría si dentro de un año dejamos de utilizarlo.
También intento evitar los plugins que resuelven cien cosas cuando únicamente necesitamos una.
Una extensión enorme puede parecer una solución cómoda, pero introduce más código, más opciones, más posibles incompatibilidades y más superficie de ataque. La superficie de ataque, explicado de forma sencilla, es el conjunto de puntos por los que una web podría sufrir un problema de seguridad.
En ocasiones, veinte líneas de código bien colocadas son más razonables que un plugin completo.
En otras, el plugin es claramente la mejor elección.
El trabajo está en saber distinguir una situación de la otra.
Mi primera tarea no siempre es buscar una solución
Cuando alguien me plantea un desarrollo, normalmente intento entender primero qué quiere conseguir, no qué quiere construir.
No es exactamente lo mismo.
Un cliente puede pedir un panel personalizado porque necesita consultar unos datos rápidamente. Quizá no necesite un panel. Quizá baste con mejorar los filtros que ya existen en la administración.
Puede pedir una aplicación interna porque su equipo pierde mucho tiempo copiando información. Tal vez no necesite una aplicación, sino conectar dos herramientas mediante sus APIs.
Puede querer rehacer toda la web porque ciertas páginas cargan lentamente. Es posible que el diseño no sea el problema y que la lentitud venga de una consulta mal planteada, una configuración deficiente de caché o un plugin que realiza peticiones externas en cada visita.
Si empiezo a construir demasiado pronto, puedo resolver exactamente lo que me han pedido y no resolver lo que realmente les ocurre.
Por eso suelo revisar cuatro cosas antes de plantear un desarrollo importante: la frecuencia con la que se utilizará, el impacto que tiene el problema, las alternativas existentes y el mantenimiento que generará la solución.
No hace falta convertirlo en una metodología con un nombre sofisticado. Es, simplemente, intentar no complicar un proyecto sin necesidad.
El coste más peligroso es el que no se ve al principio
Un desarrollo puede funcionar perfectamente el día de la entrega y ser una mala decisión a largo plazo.
Lo he visto muchas veces en proyectos que llegan a mis manos después de pasar por varios proveedores.
Funciones duplicadas. Código añadido directamente al tema. Modificaciones en archivos del núcleo de PrestaShop. Plugins que no pueden actualizarse porque alguien cambió su código. Procesos automáticos que nadie sabe exactamente cuándo se ejecutan.
En algunos casos, la funcionalidad sigue funcionando. El problema aparece cuando hay que modificarla.
Entonces descubres que una condición aparentemente pequeña está repetida en cinco archivos. Que una actualización puede romper el checkout. Que los datos se guardan en una tabla personalizada sin ninguna documentación. O que el proceso depende de una cuenta personal de alguien que ya no trabaja en la empresa.
Eso es deuda técnica.
No significa que el código esté necesariamente mal hecho. Significa que las decisiones tomadas en el pasado están limitando o encareciendo las decisiones del presente.
Toda web tiene cierta deuda técnica. Es normal. Los proyectos cambian, los negocios evolucionan y las herramientas se quedan antiguas.
Lo importante es no generarla gratuitamente.
En ocasiones, no desarrollar exige más experiencia que desarrollar
Decir que algo se puede construir suele ser fácil.
Lo difícil es explicar que quizá no debería construirse de esa manera.
A veces la alternativa menos espectacular es la más sensata. Aprovechar una funcionalidad nativa. Cambiar ligeramente un proceso interno. Conectar dos sistemas existentes. Eliminar un paso que nadie necesita. Esperar unas semanas para comprobar si la necesidad es realmente recurrente.
Esto puede resultar menos atractivo que presentar un gran desarrollo personalizado.
Pero un proyecto no mejora por tener más código.
Mejora cuando resuelve mejor sus necesidades, tiene menos puntos de fallo y puede evolucionar sin que cada cambio se convierta en una operación delicada.
He trabajado en webs donde añadir una funcionalidad nueva era relativamente sencillo, aunque el proyecto fuese grande. También he trabajado en webs mucho más pequeñas en las que tocar cualquier cosa daba miedo.
La diferencia no estaba en el tamaño.
Estaba en las decisiones que se habían ido acumulando.
El objetivo no es evitar el desarrollo a medida
Hay ocasiones en las que desarrollar una solución propia es claramente la mejor opción.
Cuando el proceso forma parte importante del negocio, cuando las herramientas existentes no cubren bien la necesidad o cuando depender de un servicio externo supondría una limitación seria, el desarrollo a medida tiene todo el sentido.
De hecho, algunos de los proyectos más interesantes en los que he trabajado nacieron precisamente porque las soluciones estándar no eran suficientes.
Pero incluso entonces intento que el desarrollo sea lo más pequeño posible.
No pequeño en posibilidades, sino en responsabilidades.
Prefiero varias piezas claras y comprensibles a un sistema enorme que intenta controlarlo todo. Prefiero utilizar los mecanismos nativos de WordPress o PrestaShop antes que sustituirlos sin necesidad. Y prefiero dejar una estructura que otro desarrollador pueda entender sin tener que reconstruir mentalmente todo el proyecto.
El buen desarrollo no es el que demuestra cuánto código puedes escribir.
Es el que resuelve el problema con la cantidad adecuada de código.
Antes de añadir algo, conviene mirar lo que ya tenemos
Cuando una web lleva años funcionando, es habitual pensar que necesita más funcionalidades.
A veces es cierto.
Otras veces lo que necesita es ordenar, simplificar o conectar mejor las que ya tiene.
Antes de crear un nuevo panel, conviene revisar el actual. Antes de instalar otro plugin, merece la pena comprobar si la funcionalidad ya existe. Antes de construir una integración compleja, hay que preguntarse si el proceso puede simplificarse.
Y antes de empezar un desarrollo de varias semanas, quizá sea razonable probar la idea durante un tiempo con una solución más sencilla.
No todo tiene que escalar desde el primer día.
No todo tiene que estar completamente automatizado.
Y no todos los problemas necesitan convertirse en software.
Después de muchos años desarrollando, sigo disfrutando cuando una solución exige programar algo complejo. Pero también he aprendido a valorar esos momentos en los que, después de analizar bien el problema, descubres que no hace falta hacerlo.
Porque a veces el mejor desarrollo no es el más sofisticado.
Es el que consigues no tener que mantener dentro de dos años.