Conclusiones sobre el Open Agile del Sabado

Este sábado fui al open agile que se realizó en el centro cultural Borges y del cual 10Pines fue auspiciante. Personalmente me gusta mucho la dinámica de los "open space", se logran charlas muy interesantes y todos aportan su conocimiento, si nunca fueron a un evento de este tipo, les aconsejo por lo menos ir una vez para ver cómo se realiza.
Respecto de la parte técnica del evento, saqué un par de conclusiones que quería compartir:
1) Me llamó la atención la confusión que existe entre TDD y test. Vi que hay muchas personas que creen que TDD es la única solución de test y lo quiren usar para resolver todos los problemas como la generación de UI, configuración de sistemas, etc. Sin embargo TDD implica desarrollo de software y no solo eso, implica escribir el test primero, por lo tanto testear la UI no es hacer TDD porque para poder hacerlo es necesario tener la UI por lo que no se escribe el test primero. Testear la configuración de un sistema no es TDD puesto que no se está desarrollando nada, etc. En conclusión TDD es una técnica más que entre otras cosas ayuda a testear, pero no es la única técnica de testing.
2) Me sorprende cómo cuando se habla de buen diseño la gente relativiza tanto el término "buen", hasta el punto donde puede ser "mal" y no hay problema. Esto es algo que me ha pasado en otros ámbitos y la facultad también, pareciera que el diseño de una aplicación puede ser cualquier cosa y hablar de "buen diseño" no tiene sentido. Yo soy completamente contrario a esa opinión. Para mi existen buenos y malos diseños y se pueden determinar en base a un conjunto de criterios bien establecidos que tienen que ver con aquellos que atacan la esencia del software y su desarrollo. Cuestiones como mantenibilidad, representabilidad, semántica, etc. son características esenciales del software que definen que tan bien o no está diseñado. Por último existe un conjunto de características no esenciales en la cual el diseño puede diferir fuertemente, como performance, usabilidad, etc. y donde creo que si se puede relativizar un poco más que es bueno o malo puesto que son características más contextuales que esenciales
3) Cada vez me lamento más que Kent Beck haya llamado a SUnit así. En realidad me lamento la parte de Unit puesto que a partir de esto se relaciona TDD únicamente con test unitarios y hay mucho más que test unitarios en tdd. Los test pueden ser bien funcionales, pueden ser user stories, se puede usar xUnit para escribir test de programación o diseño que nada tienen que ver con que sean "unitarios"... en fin, una lástima la confusión que se genera por este nombre.