¿Inteligente o Tonto?

¿Cuál es la diferencia entre ser inteligente o ser tonto? Creo que podría resumirse en dos cosas: qué tan lejos en el futuro podés pensar, y qué tan rápido podés generar este pensamiento. Cuando alguien juega ajedrez, o poker, sus habilidades están determinadas por cuántas movidas puede pensar por adelantado. Cuánta historia pueden recordar, y así planificar el siguiente movimiento.

En el desarrollo de software, ¿qué tan lejos podés mirar? ¿Estás usando prácticas destructivas porque estás muy ocupado "terminando el trabajo"? ¿Estás ignorando buenas prácticas que podrían ahorrarte tiempo?

Podemos relacionarlo con armar un camino que atraviese un bosque. Estás trabajando muy, muy duro. Todos en el equipo están transpirando, astillándose las manos, todo el tiempo. No se puede cuestionar la lealtad ni dedicación de nadie.

Pero...

¿Cuándo fue la última vez que detuviste esta tala de árboles metafórica, te subiste a un árbol... o miraste el mapa... o afilaste el hacha? El problema con la mayoría de los equipos de software que talan árboles en el bosque es que no comprueban si el camino que están armando está dirigido hacia la ciudad correspondiente. No comprueban si es un camino recto. No analizan si podrían comprar algunas sierras eléctricas para reemplazar a las hachas obsoletas que vienen usando.

Por supuesto que esto también puede abusarse. No queremos pasar todo el día en el negocio buscando herramientas nuevas, pero de vez en cuando necesitamos mirar los alrededores, ver si seguimos en línea recta. Debemos asegurarnos de estar usando las herramientas correctas para el trabajo. Comprobar si siguen afiladas las hojas.

Les dejo algunas sugerencias como herramientas para asegurarnos que seguimos en el camino correcto.

• Integración Continua. Hay muchas herramientas de Integración Continua que ayudan muchísimo al equipo. Hace que el equipo siga escribiendo código en vez de arreglar compilaciones, mantiene limpio al producto, y encuentra problemas rápido.
• Demos frecuentes. Tanto si son internas o para el cliente, estas demostraciones públicas ayudan a entender lo que estamos haciendo, y nos sugiere correciones al curso. Si estamos cortando el camino en la dirección incorrecta, ¿cuánto tiempo queremos seguir perdiendo? Debemos mostrar lo que hacemos, y averiguar lo que piensan lo antes posible.
• Iteraciones de duración fija. Las iteraciones acotadas brindan una forma más efectiva de enfocar los esfuerzos y asegurarse de estar construyendo el software adecuado.
• Pruebas automatizadas. Cuando codificamos nuestro conocimiento del producto en una prueba automatizada (que se ejecuta en un servidor de integración continua), se hace imposible que alguien del equipo rompa el código sin que se descubra rápidamente.
• Pruebas guiadas por los defectos. ¿Encontraste un bug? Agregá una prueba. Siempre. Esta perspectiva extreme a la automatización de pruebas nos brinda cobertura justo en donde era necesaria. También, no agregues una sola prueba... buscá armar escenarios derivados de la situación.
• Desarrollo guiado por pruebas. Escribir una prueba antes de escribir el código productivo hace que surja un código completamente diferente. Es más pequeño, más enfocado y (¡sorpresa!) está probado. TDD es un camino de ida... ¡probalo!
• Reuniones diarias de parado. Estas reuniones diarias y breves hacen que todos hablen y se vean la cara, todos los días. Se responden 3 preguntas que ayudan a compartir información. ¿Cuántos equipos conocen que no se hablan a diario?

Fuente