Un software testeable debe tener una estructura, diseño y concepción ¡testeable!; Sólo podemos crear software testeable si abstraemos la solución lo suficientemente bien como para luego permitir el desarrollo de las pruebas correspondientes. Esto requiere cierto cambio de mentalidad a la hora de enfocar los problemas aunque también es una cuestión de implantar ciertos principios de diseño bien conocidos, tales como S.O.L.I.D, KISS (keep it simple, stupid!), DRY (don’t repeat yourself) y un larguísimo etcétera.

En software tenemos la habilidad y capacidad de destruir, reconstruir y modificar lo que desarrollamos a nuestro antojo: es más, esta modificación para la mejora no es un paso atrás, sino todo un paso adelante si ello supone mejorar el diseño o implementación de la solución. Es una inversión aunque en ocasiones nos cueste mucho eliminar o modificar algo que nos costó horas o días desarrollar. A esta técnica la llamamos «refactoring» y no es más que buscar cómo mejorar o simplificar lo que ya tenemos desarrollado. Debemos hacernos continuamente preguntas del tipo ¿puedo simplificar este código de algún modo?, ¿puede ser entendido fácilmente por otra persona?

A la capacidad de aprender de los errores y reponerse del fracaso se llama «resiliencia». Aprendemos más de los errores que de los éxitos. El éxito en el desarrollo de software no está determinado sólo por el tiempo de entrega sino un producto que puede evolucionar y fácil de mantener.

Pruebo, Aprendo, Mejoro y Repito - Bueno no es suficiente

Nuestro trabajo es la proyección de nuestro estado mental, en este sentido, el «arte de programar» requiere de un entorno altamente creativo, lúcido, tranquilo, optimista y positivo. En software, «bello y elegante» significa fácil y barato de evolucionar y mantener. Si dentro del equipo existen las banderas rojas que no fomente un desarrollo ágil lo mejor es reestructurar.

Inspiro a los demás - Pienso en equipo no como Ninja

En la economía actual sólo podemos elegir entre competir con calidad o cantidad. Aunque al mismo tiempo sé que la cantidad depende también de una cuestión de productividad sin embargo, si hay que correr de manera extraordinaria para «entregar» como sea según las fechas previstas, es evidente el síntoma de que alguien planificó mal el trabajo y las fechas.

La genialidad de un buen desarrollador de software está en saber encontrar soluciones sencillas.

o, la presencia excesiva de comentarios en el código, precisamente, revela que algo no se está resolviendo de manera sencilla y autodescriptiva.