La excesiva simplicidad

Una creencia muy arraigada en todas las metodologías (XP, SCRUM, RUP, etc..) es pensar que al SIMPLIFICAR una tarea siempre se obtiene valor y se minimizan riesgos. Es decir, si hay que hacer una tarea entonces mejor hacer dos más sencillas o si hay que hacer un algoritmo mejor dividirlo en trozos.
Es obvio que es mejor hacer dos tareas que cuesten “20” que una que cueste “40” si tengo dos miembros de mi equipo que pueden llevar a cabo una tarea, además que es mejor asumir el riesgo de dos procesos que de uno ya que si tengo dos procesos y falla uno entonces el proceso total esta al 50% pero si solo tengo una tarea y ha fallado entonces el proceso total esta al 0%. Pero al pensar en la simplificación de una tarea, en dividirla, siempre se olvidan dos cosas o no se les da el impacto real que tienen:

• Integración: Si divides una tarea en subtareas luego hay que integrarlas para obtener la funcionalidad deseada y en muchos casos los costes de integración superan con creces la mejora que se consiguió al dividir la tarea.


• Penalización en rendimiento: La integración puede ser sencilla debido a que las fronteras entre subtareas esta clara y es muy flexible pero en cualquier aplicación medio compleja tanta modularidad y flexibilidad de comunicación suele traducir en que a la hora de probar la aplicación esta tiene un rendimiento pésimo.