Cambiar un botón en la página de inicio recibe una estimación de dos semanas. La actualización de plugins espera al lunes, porque el viernes nadie quiere arriesgarse. Tras una semana, el desarrollador nuevo sigue sin tener una copia de la web funcionando en su equipo. El dueño de la empresa ve crecer las facturas y saca la conclusión más fácil: la gente trabaja demasiado despacio.
Ally Piechowski, que audita equipos de desarrollo, describió en el artículo Why Your Engineering Team Is Slow (It’s the Codebase, Not the People) cinco señales de que el ritmo lo frena el código y no el equipo. Escribía sobre aplicaciones, pero cada señal tiene su equivalente en una web WordPress y en una tienda WooCommerce. A continuación tienes cada una, junto con una forma de medirla en tu propia instalación.
Por qué es tan alta la estimación de un cambio sencillo en WordPress
La autora llama a la primera señal la estimación con disculpa. Para una función que debería llevar tres días, el desarrollador dice: “Conociendo este código, seguramente serán unas dos semanas” (Ally Piechowski, traducción propia). Sabe que un cambio en un sitio rompe algo en otros tres. Según la autora, las estimaciones que salen siempre 2-3 veces más altas de lo que deberían no son un problema de estimación. El equipo sabe lo que cuesta ese código, solo ha dejado de explicarlo.
En WordPress, estos acoplamientos ocultos tienen orígenes habituales: un tema que genera parte del contenido por su cuenta en lugar de usar bloques, plantillas de WooCommerce sobrescritas que se copiaron hace varias versiones, varios plugins que hacen lo mismo y código propio enganchado a los mismos hooks.
Cómo medirlo: toma los últimos diez cambios del historial de tickets y compara la estimación con el tiempo real. Si la desviación es constante y siempre en la misma dirección, la estimación dice la verdad sobre el código.
Por qué nadie quiere actualizar la web un viernes
La segunda señal es el miedo a publicar. El artículo cuenta el caso de un equipo con la norma no escrita de “nada de publicar después del miércoles”. Nació después de tres jueves seguidos con una publicación cada uno que acabaron en caídas el fin de semana, sin plan para volver atrás, con pruebas en las que nadie confiaba y un proceso de publicación de 45 minutos.
En una web WordPress, este miedo se ve así: actualizaciones de plugins hechas directamente en producción, ningún entorno de pruebas o uno con una base de datos de hace seis meses, una copia de seguridad que nadie ha restaurado nunca. El resultado es el mismo que en el artículo: los cambios se acumulan en paquetes, y cada paquete es más grande y arriesgado que el anterior.
Cómo medirlo: responde a tres preguntas. ¿Existe un entorno de pruebas con la base de datos actual? ¿Alguien ha restaurado una copia de seguridad en el último trimestre? ¿Hay días en que el equipo no publica? Cada “no” en las dos primeras y un “sí” en la tercera suben la puntuación.
Qué archivo del tema de WordPress es la zona prohibida
La tercera señal es el archivo que nadie toca. La autora lo busca en el historial del repositorio: un archivo que aparece una y otra vez en git log, pero cuya estructura nadie ha cambiado en años. Alrededor de un archivo así el equipo construye rodeos, de modo que el código crece en torno a una zona que todos evitan.
En WordPress suele ser el functions.php del tema, que con los años ha crecido hasta varios miles de líneas, o el plugin propio de la empresa, al que cada uno añadió “solo una función más”.
Cómo medirlo: en el repositorio del tema o del plugin propio, ejecuta
git log --since="1 year ago" --format= --name-only | sort | uniq -c | sort -rn | head -10La lista muestra los archivos que más se modifican. El archivo en lo alto cuyos cambios son solo añadidos al final es candidato a zona prohibida. Si el tema no tiene repositorio, la puntuación de esta señal es alta de todos modos: no hay forma de saber quién cambió el código ni por qué.
De paso, cuenta los plugins activos:
wp plugin list --status=active --format=countEl número por sí solo no decide nada, pero varios plugins de formularios, caché o SEO a la vez son una fuente habitual de conflictos que alargan cada cambio.
Una cobertura de pruebas alta protege el checkout de WooCommerce
La autora llama a la cuarta señal la mentira de la cobertura. El panel muestra un porcentaje de cobertura saludable, mientras tres modelos que manejan dinero no tienen ni una sola prueba. Además, las pruebas en el servidor de CI tardaban 40 minutos, así que los desarrolladores dejaron de ejecutarlas en local. Su prueba es sencilla: ¿cuándo fue la última vez que una prueba detectó un error antes de que llegara a producción?
Una tienda WooCommerce sin ninguna prueba tiene el mismo problema de forma más aguda. El flujo del dinero es el carrito, el checkout, la pasarela de pago y el correo de confirmación del pedido. Si después de cada actualización alguien hace un pedido de prueba a mano, la tienda tiene una prueba, solo que manual y dependiente de la memoria de una sola persona.
Cómo medirlo: comprueba si existe alguna prueba automática que haga un pedido y pregunta cuándo detectó algo por última vez.
Cuánto se tarda en poner a trabajar a un desarrollador nuevo en una web WordPress
La quinta señal es el tiempo hasta el primer cambio: cuánto pasa hasta que una persona nueva publica una corrección real. Según la autora, en un proyecto sano es un día o dos, y en los que no lo están ha visto dos semanas o más. La causa suele ser una configuración que se ha ido pudriendo: scripts de instalación desactualizados, datos iniciales rotos, variables de entorno sin documentar.
En WordPress la lista es parecida: ningún repositorio, un volcado de la base de datos que hay que suplicar al proveedor de alojamiento, claves de API guardadas solo en producción, plugins premium sin licencia de desarrollo.
Cómo medirlo: monta desde cero una copia local que funcione, por ejemplo con wp-env, y anota el tiempo y cada cosa que tuviste que pedirle a alguien.
Cómo se calcula la puntuación de las cinco señales
La autora puntúa cada señal de 0 a 2. Un total de 4 o más significa que el código necesita inversión directa antes de que otras medidas sirvan de algo. A partir de 7 puntos, según escribe, empiezan la mayoría de sus encargos.
| Señal | 0 puntos | 2 puntos |
|---|---|---|
| Estimación con disculpa | las estimaciones coinciden con el tiempo real | desviación constante al alza |
| Miedo a publicar | entorno de pruebas, plan para volver atrás, publicación cualquier día | cambios en producción, ninguna copia comprobada |
| Archivo que nadie toca | ningún archivo domina el historial | un archivo acumula añadidos |
| Cobertura de pruebas | una prueba detectó hace poco un error antes de producción | checkout sin ninguna prueba |
| Tiempo hasta el primer cambio | copia local en una hora | varios días y peticiones de acceso |
Los puntos en sí son convencionales, lo que cuenta es el orden de las señales. La autora aconseja empezar por la señal con la puntuación más alta, dedicarle dos semanas de trabajo concentrado y medir algo concreto, como la frecuencia de publicación o el acierto de las estimaciones.
Por qué el mejor desarrollador de la web es el más lento
La autora señala una paradoja: con un código así, quienes más se frenan son los mejores. Ven el riesgo, saben que un cambio en este archivo puede romper aquel proceso, así que trabajan con cautela, escriben código defensivo e inflan las estimaciones. Una persona con menos experiencia a veces es más rápida porque no ve el peligro, y luego provoca una caída tras la cual todos se vuelven aún más prudentes.
Un ejemplo de su artículo: dos desarrolladores pasaron una semana añadiendo una exportación a CSV al panel de administración, cuando el trabajo en sí era quizá de un día. El resto del tiempo se fue en entender el código existente lo bastante como para cambiarlo con seguridad. Ese sobrecoste no aparece en ningún informe, así que la dirección solo ve gente lenta.
Rehacer la web desde cero soluciona la lentitud de los cambios
No siempre. La autora describe a un cliente por el que pasaron seis equipos de desarrollo en diez años. Cada vez el patrón fue el mismo: presión por nuevas funciones, limpieza aplazada, hasta que el código parecía imposible de salvar. Entonces alguien proponía reescribirlo o separar microservicios, lo que empeoraba las cosas, porque en lugar de un sistema había dos, y el antiguo seguía funcionando.
En WordPress este escenario suena conocido: un tema nuevo montado junto al antiguo, un frontend headless que se queda con parte de las páginas mientras el resto sigue pasando por la plantilla vieja, o una tienda nueva a la que la mitad de las integraciones nunca llega a migrarse. Rehacer la web tiene sentido cuando sabes qué señal está frenando y si la nueva arquitectura la elimina. Sin eso, los viejos obstáculos se mudan al código nuevo.
Qué arreglar primero en cada señal
La autora da un primer paso distinto para cada señal. Aquí tienes sus recomendaciones y su equivalente en una web WordPress.
- Estimación con disculpa: desacoplar los módulos cuyos cambios repercuten en más sitios. En WordPress suele significar dividir
functions.phpen archivos separados o en un plugin con funciones de nombre claro, y retirar las plantillas de WooCommerce sobrescritas que nadie ha actualizado. - Miedo a publicar: un proceso de publicación más rápido, vuelta automática a la versión anterior y paquetes de cambios más pequeños. En WordPress: un entorno de pruebas con la base de datos actual, publicar el código desde el repositorio en lugar de por FTP y una restauración de copia de seguridad probada.
- Archivo que nadie toca: primero pruebas a su alrededor, después cambios de estructura. Para un tema, al principio bastan unas pocas pruebas que comprueben que las páginas clave se muestran.
- Cobertura de pruebas: una prueba del flujo del dinero. En WooCommerce es una prueba automática que hace un pedido en el entorno de pruebas y comprueba que ha llegado el correo de confirmación.
- Tiempo hasta el primer cambio: según la autora, un solo día dedicado a arreglar la configuración se amortiza solo. En WordPress: un archivo de configuración de wp-env en el repositorio, un script que descarga un volcado anonimizado de la base de datos y una lista de variables de entorno.
Cuando hables de esto con la dirección o con un cliente, lo concreto funciona mejor que lo genérico. La autora contrapone dos frases: “cada función tarda aproximadamente el doble por el acoplamiento entre estos tres módulos” es una conversación completamente distinta a quejarse de la deuda técnica (Ally Piechowski, traducción propia).
La IA acelerará los cambios en una web WordPress antigua
Es tentador dar por hecho que un agente de IA reescribirá el problema. La autora cita un estudio de METR de 2025: 16 desarrolladores experimentados de código abierto trabajaron un 19% más despacio con herramientas de IA en repositorios que conocían bien. Añade que escribir código nunca fue el cuello de botella.
El agente choca con las mismas dependencias ocultas que una persona, solo que genera más rápido el siguiente rodeo alrededor del archivo que nadie toca. Por eso conviene bajar las cinco señales antes de dejar entrar a la IA en el repositorio.
Por dónde empezar a arreglar una web WordPress lenta
Con cuatro puntos o más, empieza por eliminar el obstáculo con la puntuación más alta. Un desarrollador nuevo o un tema nuevo se toparán con los mismos obstáculos. Normalmente se trata de un entorno de pruebas con la base de datos actual y un repositorio para el tema, porque sin ellos no se puede tocar con seguridad ninguna otra señal.
Así funciona nuestro sprint de rescate de WooCommerce: un diagnóstico de pago, correcciones por orden de prioridad, publicación primero en el entorno de pruebas y un informe escrito con lo que se cambió y por qué. Si te preguntas si todavía merece la pena arreglar la web, empieza por la auditoría de preparación para el rediseño o por la guía sobre cuándo reconstruir un sitio web.
