Si el agilismo tiene tantas ventajas, ¿Por qué no lo está practicando ya todo el mundo? La resistencia al cambio es uno de los motivos fundamentales. Todavía forma parte de nuestra cultura pensar que las cosas de toda la vida son las mejores. Ya se sabe... Si es de toda la vida, es como debe ser. Si los ingenieros y los científicos pensásemos así, entonces tendríamos máquinas de escribir en lugar de computadoras (en el mejor de los casos).
Existen fuertes razones históricas para ser tan reticentes al cambio pero los que trabajamos con tecnología podemos dar un paso al frente en favor del desarrollo. ¡Ojo! Podemos dejar nuestro lado conservador para otros aspectos no tecnológicos, que seguro nos aportará muchos beneficios. No se trata de ser progresista ni estamos hablando de política, limitémonos a cuestiones de ciencia y tecnología.
¿Estamos preparados para darle una oportunidad a la innovación o nos quedamos con lo de toda la vida, aunque sólo tenga una vidade medio siglo? (en el caso de programadores junior, sólo un par de años). Hemos aceptado una determinada forma de trabajar (en el mundo del software) y nos parece inmutable aún cuando esta industria todavía está en pañales. Hemos llegado al punto en que la informática ya no es una cuestión de matemáticos sino de especialistas en cada una de las muchas áreas de la informática. Ni siquiera se han jubilado aún los primeros expertos en software de la historia.
Cuando era niño no se me pasaba por la cabeza que todo el mundo llevase un teléfono móvil encima y se comunicase desde cualquier lugar (hace sólo 15 años). Hace poco no nos imaginábamos que compraríamos por Internet ni que las personas encontrarían pareja a través de la red. Los que han tenido confianza en el cambio y han sabido crecer orgánicamente trabajan en lo que les gusta y no tienen problemas para llegar a fin de mes. Las nuevas tecnologías son el tren de alta velocidad que une el presente con el futuro en un abrir y cerrar de ojos.
Ahora bien, aprender una nueva técnica supone esfuerzo. Es natural que nos dé pereza dar los primeros pasos hacia el cambio y por eso usamos mil excusas:
- Que es antinatural...
- Que está todo al revés...
- Que es un caos...
- Que no tenemos tiempo ahora para aprender eso...
- Que no tenemos los conocimientos previos para empezar...
- Que no sabemos por dónde empezar...
- Mañana empiezo...
- Es que,... es que...
Nos comportamos como lo haría un fumador al que le dicen que deje de fumar. La corriente popular en términos de software no es capaz de evolucionar lo suficientemente rápido como para que sus teorías sean las mejores. Hay que plantearse si seguirla es buena idea o conviene cambiar de corriente. Esto es,... ¿Prefiere la pastilla azul o la roja? (célebre frase de la película Matrix).
No negaremos que hay que hacer una inversión en tiempo y esfuerzo para aprender y poner en práctica una nueva forma de funcionar, la cuestión es que tal inversión se amortiza rápidamente. Si esperamos a mañana para que se den las condiciones perfectas y empezar a ser ágiles, quizás nunca llegue el día. ¿Acaso piensa que alguna vez tendrá tiempo y dinero de sobra para todo lo que quiera? El plan es más bien parecido al de echar monedas a la hucha para irse de vacaciones; pequeñas inversiones poco a poco. No se interprete que podemos jugar con el dinero del cliente, aprender no significa jugar con su dinero, ¿vale?.
Si aceptamos que el software siempre se puede mejorar, el siguiente paso es admitir que es positivo mantener un cierto aire inconformista en nuestra actitud profesional. La autocrítica nos lleva a escribir código de mayor calidad y a reconocer nuestros errores. El juicio sano sobre nuestro trabajo nos guía en la búsqueda de mejoras estrategias y nos ayuda a superar la pereza que nos produce la idea del cambio. Todos los días aprendemos algo nuevo. El día que deje de ser así habrá que reflexionar seriamente sobre si estamos ejerciendo bien el puesto de ingenieros de software.
Este capítulo ha sido compuesto a base de pinceladas procedentes diversos temas. No pretende ser completo, ya que se podría escribir un libro entero sobre metodologías, sino solo establecer un contexto de partida para el resto de capítulos.