En software, hay veces que en la teoría hay unas pequeñas ideas que son muy sencillas, pero que luego, a la hora de la realidad y del trabajo día a día son realmente complejas. Ya me he topado en varias ocasiones con ellas y he visto como caigo una y otra vez en los mismos problemas que teóricamente sé y no debería caer en ellos. Pongo unos cuantos ejemplos.
El primero y más tonto, es a la hora de hacer componentes reutilizables. Tienes, por ejemplo, que hacer un gráfico que en el eje de las x pinte el tiempo y en el eje de las y el número de veces que te llega un mensaje por un socket. Cuando te pones a codificar ves que es un simple histograma, o un gráfico x/y en el que hay una función, y decides hacerlo general. Te haces un proyecto separado de gráfico-histograma, lo codificas y lo haces general. Es capaz de dibujar cualquier función por puntos o histograma. Curiosamente para pasarle las x has llamado al método setFechaHora() y setNumeroMesajes().
Sin embargo, hacer ese ejemplo bien, también es complejo. En cierta ocasión quise hacer una especie de traductor de palabras de inglés a español. Hice un fichero de propiedades con palabra_español=palabra_ingles. Me empece a hacer la clase que leía el fichero de propiedades y ponerle método getEnInglés(), getEnEspañol(), etc. Al final me doy cuenta que es más general que todo eso, puede servir para cualquier pareja de idiomas. Así que getEnIdioma1() y getEnIdioma2(). Pero claro, es más general todavía, sirve para cualquier pareja clave-valor. Vuelvo a cambiar los métodos… y al final tengo una copia hecha por mi mismo de la clase Properties de java.
Es difícil saber hasta dónde generalizar y hasta dónde dejar como específico.
Segundo ejemplo de cosa sencilla compleja. Actualmente estoy usando XPlanner, un poco para jugar, pero tratando de tomármelo un poco en serio. Tengo muy clara la idea que hay que pensar una historia de usuario -alguna funcionalidad concreta- y ponerle tareas concretas con tiempos y demás. El problema que tengo es que siempre acabo poniendo tareas generales que no son de una funcionalidad concreta. Por ejemplo, las historias deberían ser "dar de alta usuario nuevo", "borrar usuario existente", "modificar datos de usuario", etc. Las tareas deberían ser "hacer la gui de pedir usuario nuevo"; "hacer la inserción de usuario nuevo en bd", etc. Sin embargo, tiendo a poner "gestión de usuarios de la bd", en la que incluyo alta, baja y modificación de usuario con la base de datos. Supongo que el mal es excusable en el sentido de que tratas de hacer todo lo relativo a base de datos de una sola vez. Sin embargo, aunque quieras aprovechar a hacerlo todo de golpe, eso no quita que pongas TRES tareas separadas: alta, baja y modificación de usuario. Esto, además, debe ser así, porque obliga a pensar qué es exactamente eso de "gestión de usuarios en la bd". Independientemente de que se use o no XPlanner, este es un problema demasiado habitual en cualquier tipo de planificación: no definir claramente cual es la tarea exacta que se quiere hacer.
Es difícil concretar lo suficiente las tareas a hacer.
En cuanto al tercer ejemplo, el consabido Scrum que ya he comentado varias veces. Lees la teoría y es algo muy sencillo. Sin embargo, la práctica es bastante compleja. Requiere mucha, mucha disciplina, para hacer las reuniones diarias. Se junta con el problema que comenté antes de XPlanner/planificación: los sprint deberían ser concretos y no cosas como "gestionar usuarios en la bd". Y lo que yo veo más complejo, requiere gente que colabore y con buen rollo. Hace falta motivar a la gente, que vayan a priori convencidos de que el método es útil e intenten sacarlo adelante. De nada sirve que creas tú solo en él, andes todos los días tirando de la gente para las reuniones y el día que faltas nadie mueva un dedo por seguir con el tema.
Es dificil organizar a más de uno -incluso yo conmigo mismo tengo mis problemas-.
