christian.soronellas

Recientemente me he visto envuelto en una discusión de alto nivel en LinkedIn, pues un compañero y amigo de allí dónde trabajo me recomendó qué le echara un vistazo por ciertos comentarios vertidos en ese hilo. El título del hilo, JQuery or YUI? Pro’s and Cons. Dentro del grupo Front end Developer Group. Un interesantísimo debate. Lo recomiendo a quién me esté leyendo, tenga facilidad con el inglés y sobretodo le interesen temas de front-end.

Está mi ciclo de desarrollo en … peligro?

A lo largo de este debate cierto individuo, tengo qué decir con toda sinceridad que equivocadamente, pone por delante de cualquier otra decisión técnica el valor qué tiene la velocidad de ejecución cuándo se trata de decidir usar un framework de JS. Si ya te has puesto las manos a la cabeza, por favor, espera a acabar de leerme.

Es evidente qué la velocidad es un factor a tener en cuenta cuándo hemos de decidir usar una librería u otra. Pero nunca puede ser el único motivo por el cuál decantarse. Estaríamos incurriendo en una mala decisión, qué nos puede llegar a afectar muy negativamente en un futuro, ya qué las decisiones técnicas deben venir siempre motivadas por unas necesidades de negocio. Estás necesidades responden a la medición de unos costes sobre las mismas oportunidades de negocio qué nunca se pueden menospreciar. Es decir, me explico. Cuál puede ser el coste, para un negocio, de perder una oportunidad? Un gran oportunidad? Puede suponer perder el hecho posicionarse delante de la competencia en una posición realmente privilegiada. Luego la propia marca empieza a perder valor (o le cuesta horrores recuperarlo), delante de la competencia. Y esto, sólo sería el principio de la cadena de consecuencias. Y eso lo puede solucionar un factor cómo la velocidad de ejecución de una librería JS? Esto qué parece tan mezquinamente lógico, para ciertos individuos no lo es. Se debe ir con calma y humildad.

Qué impacto puede tener esto en el ciclo de desarrollo?

El caso más simple y más fácil de ver, es el del típico tío de negocios, cliente, Product Owner qué quiere ver lo qué ha solicitado a desarrollo, online lo antes posible. Obviamente, su misión será presionar para conseguirlo cuánto antes. Hasta aquí, nada raro. Nada qué no se viva en una empresa cotidianamente. Pero qué pasa cuándo por ejemplo, el diseño de esa librería tan rápida no permite desarrollar la nueva funcionalidad tan rápidamente? O cuándo la curva de aprendizaje es realmente pronunciada? O cuándo resulta qué cómo consecuencia del pésimo diseño de ese framework, tenemos algo muy costoso de mantener? Pues qué ese ciclo de desarrollo se puede ver incrementado sensiblemente, debido al coste de implementar/mantener la nueva funcionalidad. O de aprender cómo funciona la librería. O un largo etcétera.

Y ¡Carámba! Ahora a negocio, ya no le sirve de nada qué usemos algo realmente ultrarápido, pues todo lo qué ganamos con un aspecto, lo perdemos irremediablemente al perder esa oportunidad de negocio. Después, de su pertinente tirón de orejas. E incluso, dependiendo de la oportunidad perdida, nuestro puesto de trabajo.

Conclusiones finales

Elegir una herramienta de trabajo, no es un juego. Es algo de suma importancia y no debe nunca ser tomado cómo tal. De ello puede depender toda una empresa, por lo qué se deben considerar todos los requerimientos impuestos por negocio. Sin excepción.