No sé. A veces siento que algunas personas venden mal todas las excelentes ventajas del Desarrollo Guiado por Pruebas (TDD) y la Programación de a Pares (PP). Es que muchos agilistas exponen este argumento: al hacer TDD y PP se incrementa la calidad, así que aunque la productividad disminuya, tenemos la conciencia tranquila de que fuimos buenos ciudadanos del mundo del software.
¡Mentira!. No sólo no es verdad que se pueda cambiar la calidad interna por más características, sino que es justamente lo contrario: mientrás más productivdad se busca, más alta debe ser la calidad interna.
Es así, como dice GeePaw: Si querés más producción, primero buscá cómo aumentar tu calidad interna. ¿Cómo puede ser?
- Porque la calidad interna y la calidad externa no son la misma cosa.
- Porque el mayor condicionante de la producción de hoy es la calidad en la producción de ayer.
- Porque tipear no es ni fue el cuello de botella para escribir código.
Calidad interna vs. Calidad externa
En el software, hay dos diferentes tipos de calidad: interna y externa. La calidad externa trata sobre las características "vendibles" del software. Si hubiera un número que represente cuántas características tiene el software, o si estas características son las correctas dentro de un rango de posibles entradas, entonces este número sería la calidad externa. La calidad externa puede negociarse con el time-to-market. No se cambia por la productividad per se, pero es una forma perfecta para llegar a la fecha de entrega.
Por otro lado, la calidad interna trata sobre el código. Si querés un número, pensá en la complejidad de McCabe, o algo como Crap4J. La calidad interna es sobre la prolijidad, es hacer refactors continuos, programación de a pares, y usar micropruebas para guiar al código. Para los obtusos, vamos de nuevo: no podés ir más rápido bajando la calidad interna a menos que seas novato.
El ayer determina el hoy
¿Es necesario explicar esto? Todos los días, cada vez que hacemos algo, dependemos del código que ya existe. Cada línea que tenemos que estudiar nos hace ir más lento. Cada dependencia abierta nos hace ir más lento. Cada variable con un nombre malo nos hace ir más lento. Cada mala decisión de diseño, grande o pequeña, nos hace ir más lento.
Si queremos trabajar lo más rápido posible, vamos a tener que trabajar con código limpio. Punto.
El cuello de botella no está en el tipeo
La reacción más común a hacer PP y TDD es sugerir que el equipo va a trabajar más lento. Es obvio, ¿no?. Si dos personas se sientan en la misma máquina, esto quiere decir que tenemos un 50% menos de utilización de hardware, lo cual va a impactar negativamente en la producción. Y ni hablemos de TDD: las pruebas son código. Si sólo podemos producir 100 líneas de código por día, y se espera que el código esté guiado por pruebas, básicamente estás diciendo que hay que escribir 50 líneas de código y 50 líneas de pruebas. Así que es imposible que TDD y PP me ayuden a ser más productivos.
Y sin embargo, este pensamiento "lógico" tiene fallas profundas. Dos personas trabajando juntas pueden escribir igual de rápido que trabajando separadas porque, entiendan esto, la parte dificil de programar no es pegarle a las teclas. Cuando una persona dice que "programó" todo el día, ¿qué quiere decir realmente? Generalmente quiere decir que:
- escribió código
- dibujó algunos diagramas
- ejecutó el debugger
- esperó al debugger
- encontró donde poner el breakpoint para ver el caso que falla
- leyó 20-50 veces más código del que escribió
- consultó a compañeros por algún problema
- lo consultaron compañeros por algún problema
- quedó tildado con la mente en blanco
- le tiró algo a alguien
- navegó por la web buscando respuestas
- y así...
Notemos que escribir código en una máquina ocupa sólo una muy pequeña porción de la lsita. Esto ocurre así porque la parte dificil de programar es pensar, no tipear. Todo el resto de cosas de la lista (excepto eso de tirarle cosas a alguien) se trata sobre pensar, no tipear.
TDD incrementa la producción porque funciona como una ayuda para pensar: limita el tener que buscar causas, el agregar características innecesarias, y reduce el estudio de código y el debug. PP incrementa la producción por los mismos motivos: dos desarrolladores trabajando juntos no tipean tan rápido como por separado, pero eso no nos importa: el cuello de botella es pensar, y PP y TDD mejoran esto.
Conclusión
Si queremos incrementar la productividad en el equipo, necesitamos hacer 3 cosas:
- escribir una microprueba que falle antes de escribir cualquier código,
- adoptar un compromiso de "sólo en parejas",
- crear un acuerdo y comprensión compartida sobre la calidad interna.
