Tuve el gran placer de entrevistar a Carlos Blé quien habló desde la Islas Canarias en España.
Carlos es artesano de software con casi dos décadas de experiencia desarrollando software y ha estado involucrado con la comunidad de Artesanía de Software por más de una década. Carlos es también un consultor y mentor de software que tiene su propia empresa desde la cual se ha especializado en ayudar a otros a aprender cómo crear código limpio. Carlos ha sido un orador internacional frecuente y un miembro muy activo de la comunidad Agil en España.
Carlos comenzó la entrevista mencionando como eXtreme Programming había marcado un antes y un después en su carrera como desarrollador, esto debido a que antes de descubrir XP él programaba sin un proceso o modelo mental definido. Carlos mencionó que XP provee un método que lleva a resultados homogéneos reduciendo las largas noches de pizza y el estrés antes de un lanzamiento. Además, XP en su opinión le ayudó a tener predictibilidad, mantener un ritmo sostenible, y crear software de buena calidad.
En la experiencia de Carlos las pruebas automatizadas son sin lugar a duda una gran contribución para la calidad general del producto. En su opinión los humanos somos muy buenos introduciendo defectos en el código, es parte de nuestra naturaleza, pero prácticas de XP como Test Driven Development (TDD) ayudan a crear pruebas que detecten esos defectos. Carlos también mencionó que no necesitamos solo un tipo de prueba, en lugar de esto debemos apuntar a tener una buena combinación de pruebas unitarias, de integración, y de extremo a extremo. Un común denominador para todas estas pruebas es que deben estar automatizadas y proveer retroalimentación rápida.
Cuando Carlos codifica el no utiliza el depurador según dijo, en lugar de esto él introduce pruebas unitarias que le dan una alerta cuando algo no esta funcionando. Las pruebas unitarias le permiten a Carlos probar secciones del producto de manera parcial, efectiva y rápida.
Carlos mencionó que para el TDD es una práctica para elaborar código en pequeños incrementos. Carlos ve en TDD un protocolo que cuando es seguido disciplinadamente, calidad puede ser esperada en forma de código limpio acompañado de buenas pruebas automatizadas. En su opinión TDD no es la única forma para crear código con buena cobertura de pruebas, pues él ha visto equipos que produjeron buenas pruebas con excelente cobertura y que no utilizaron TDD para este propósito.
TDD de acuerdo con Carlos puede ayudar con requerimientos funcionales, pero para los requerimientos no funcionales necesitaremos buscar alguna otra alternativa. TDD como método de diseño emergente si se usa en solitario se quedará corto pues no toca cosas como atributos de calidad de software, dijo Carlos. A pesar de esto, usar TDD es mucho mejor que codificar sin protocolo alguno.
Hablando de Programación en Pareja, Carlos sostuvo que nunca vio un producto que sufra en tiempo o en presupuesto porque dos desarrolladores hayan codificado en parejas. En realidad, él dijo, la Programación en Pareja no produce ningún cuello de botella. En lugar de esto, la Programación en Pareja reduce la complejidad accidental del software que se produce por pensamiento sobredimensionado. Más aun, desarrolladores codificando en parejas acaban escribiendo menos código y más limpio.
En su opinion las empresas que no miran con buenos ojos la Programación en Pareja tienen una vision muy corta, quizás porque carecen de desarrolladores que sepan cómo realizar efectivamente esta práctica. Para reforzar este punto, Carlos mencionó que los desarrolladores gastan una tremenda cantidad de tiempo leyendo código que no entienden. En las palabras de Carlos, el problema en el desarrollo de software nunca ha sido que tan rápido pueden escribir los desarrolladores, sino más bien como podrían reducir la complejidad accidental.
Para cerrar la entrevista Carlos hizo una importante reflexión: el dogmatismo dentro de la comunidad de artesanos de software puede perjudicar a los proyectos de software si la obsesión por la calidad se impone por encima del pragmatismo. Carlos hizo un llamado para regresar a los orígenes del movimiento de artesanía de software que buscaba reducir la brecha entre los desarrolladores y el negocio, de manera que productos de buena cabalidad puedan ser creados por artesanos de software que se sientas orgullosos de su trabajo.
Sobre el Autor: Juan Banda
Juan se especializa en entrenar, mentorear y hacer coaching de equipos Agiles para que en corto tiempo puedan alcanzar resultados asombrosos. Juan es también un agente de cambio que ayuda a que empresas completas vuelquen sus prácticas hacia formas más humanas de trabajo. Juan es un Certified Scrum Trainer (CST) y LeSS Friendly Scrum Trainer. Su formación universitaria incluye un grado de Magister en Administración de Sistemas de Información conferido por The University of Illinois at Chicago.
