HDD, Hard-Disk Drive, discos duros, NO. HDD son las siglas de Hype-Driven Development tal y como lo define Marek Kirejczyk en su blog tecnológico.
Se trata de una tendencia muy humana según la cual las novedades más promocionadas, aquéllas a las que se les da mucho bombo, parecen tan innovadoras, revolucionarias, excitantes, que sería una locura no unirse a ellas, unirse a los ganadores.
En el mundo de la tecnología esto ocurre bastante a menudo, ya que aparecen estas nuevas tecnologías, procesos, modelos, lenguajes, frameworks, etc. cada pocos meses. Hace apenas 3 meses que Angular 2 era toda una novedad ¡y ya se está hablando de Angular 4! (Nos constan que los cambios entre dichas versiones son significativamente pequeños y el coste del cambio también lo es, pero ciñámonos al hecho de que hay una fuerte campaña de marketing detrás, cuyo propósito es aumentar las expectativas, ya que bien podría haberse llamado Angular 2.2).
Y este es precisamente el problema. Cuando nos dejamos llevar por las expectativas, cuando la tecnología no está madura, contrastada, cuando no es estable o, incluso, cuando hay detalles legales que no hemos considerado; corremos un gran riesgo de tener que deshacer el camino andado, tirar todo a la basura y empezar de nuevo.
¿Por qué HDD?
Básicamente para protegernos y evitar perder el tiempo escribiendo y rescribiendo código. Es importante preguntarse de antemano por qué necesitamos esa herramienta: ¿qué aporta?, ¿va a reportar algún beneficio?, ¿a corto plazo o a largo?, ¿va a mejorar el rendimiento de nuestras aplicaciones?… Si la única razón es que está de moda o que alguien la ha usado anteriormente y le gusta, posiblemente usarla no sea la mejor decisión.
Muchas de esas herramientas, tecnologías, frameworks, están pensados para problemas particulares, de modo que en otros escenarios no funcionan igual de bien que en aquellos. Si no estamos trabajando en el escenario concreto o el problema no nos impacta (o el impacto es mínimo), probablemente el esfuerzo del cambio no compense y sea más práctico implementar una solución personalizada que solvente la parte que nos afecta.
Buenas prácticas
El tiempo corre, se acerca la entrega, la espada de Damocles pende sobre nuestras cabezas y queremos ir más rápido, queremos ahorrarnos ese tiempo de compilación, esos tests, esos despliegues, ¡todo!
Lo que no debemos perder de vista es que un equipo es tan fuerte como el más débil de sus eslabones. Si nuestra forma de trabajar es inadecuada ni la mejor herramienta nos va a salvar la vida.
Es más, tras parchear nuestros problemas con esa nueva tecnología llegará un momento en que no será suficiente y volveremos a estar como al principio, sólo habremos ganado algo de tiempo. Del mismo modo que un barreño de agua sólo puede llenarse hasta el menor de sus tablones, nosotros podemos cambiar un tablón que seguiremos haciendo aguas por otro lado.
El objetivo debe ser detectar las ineficiencias, mejorar la forma de trabajar, ser más efectivos. Claro, supone más esfuerzo de gestión, pero a la larga merece la pena.
Conclusión
Tras estas reflexiones es posible que nos queden pocas ganas de probar cosas nuevas, y tampoco es ésa la solución. Una tecnología adecuada a nuestro problema, madura, que podamos conocer en profundidad antes de que se vuelva obsoleta. Lo mismo ocurre con las metodologías como Scrum o Kanban, incluso utilizando estos modelos la tasa de éxito en proyectos de desarrollo de software sigue estando por debajo del 80%, que es mayor que el 50% de los modelos tradicionales, pero sigue sin ser la panacea.
