No recuerdo dónde, así que no puedo poner el enlace, pero hace unos días leí en un foro a una persona que comentaba haber hecho un proyecto/programa de software y que ahora le pedían hacer la documentación del mismo. Dicha persona preguntaba por herramientas que hicieran algo de ingeniería inversa y le facilitaran el proceso de generar dicha documentación.
Ese post tenía algo así como tres mil respuestas y alguna más. Todas ellas, sin excepción y hasta donde alcancé a leer, criticaban a la persona diciendo cosas como "primero se hace la documentación y luego el código", "hay que pensar antes de codificar", "te pones a codificar a lo loco y así te va".
Bien, esa es la idea generalizada de todo el mundo. Todos "sabemos" que hay que hacer el diseño y la documentación antes que el código. Y lo hacemos porque "sabemos" que hay que hacerlo … pero ¿realmente hay que hacerlo?
La persona del foro no daba detalles en absoluto de su proyecto, pero por cosas como "he hecho" y "ahora me piden" podía perfectamente ser un trabajo de clase. No sé la envergadura de dicho programa, pero si es un trabajo de clase y no un proyecto fin de carrera, posiblemente sea un pequeño software de prácticas que se hace en unas semanas a ratos perdidos (cuando no estás en clase o estás estudiando otras asignaturas y no tienes la resaca del día anterior).
¿Por qué hay entonces que hacerle antes la documentación? ¿Por qué hay que plasmar en un papel lo que vas a hacer antes de hacerlo?
Este señor, posiblemente si pensó antes en lo que iba a hacer. Es más, ante un programa cuyo esfuerzo no se mide en hombres/mes, sino en persona/ratos libres, es perfectamente posible pensar sólo un poco la idea general antes y dejar para mientras se programa el pensar los detalles. Al ser sólo una persona y un programa pequeño, no necesita en absoluto dejar un documento oficial con su "declaración de intenciones", diseño preliminar, detallado, trazabilidad de requisitos, plan de proyecto, protocolos de pruebas…. Si lo hace, nadie nunca va a leerlo o usarlo y además se le pasará el curso. Es posible que esta persona mientras lo programa necesite consultar algo que haya apuntado previamente, pero lo había hecho en una hojilla guarra de papel, que le sirve perfectamente.
Si suponemos que el programa es para una práctica. Es decir, una vez que apruebe, nunca nadie jamás de los jamases va a volver a mirar ese programa. Posiblemente, incluso se pierda. Tampoco es necesaria en absoluto una documentación para su mantenimiento. Es más, salvo que sea con fines académicos, posiblemente el código ni siquiera necesite comentarios, que nunca nadie jamás va a leer.
Me da la impresión, sobre todo en gente con poca experiencia, que se cogen las cosas como "dogma de fé" sin pararse a pensar el por qué. Las cosas hay que hacerlas "así" porque se hacen "así".
Casi con seguridad al 100%, toda la necesidad y buenas costumbres de documentar antes de empezar el proyecto, partió de grandes empresas con grandes proyectos, plazos largos y muchos, muchos programadores involucrados. Ahí sí es imprescindible hacer una documentación seria al principio, de forma que todo el mundo tenga claro como encajan las cosas y que tiene que hacer o no hacer. Pero eso no hace en absoluto que documentar antes sea una buena práctica en TODAS las demás situaciones. Un claro ejemplo es el programa de prácticas de nuestro amigo, que posiblemente le "han pedido" la documentación como parte de su trabajo de clase, pero que no tiene ni tendrá nunca utilidad ninguna.
Y de hecho, para proyectos no demasiado grandes y con un grupo reducido de programadores, posiblemente también sea excesiva e inútil una documentación excesivamente oficial. Cuatro o cinco programadores pueden pensar en reuniones lo que van a hacer, plasmar si hace falta en papel los bloques principales de su proyecto, cómo se relacionan, y ponerse a codificar, con reuniones y pruebas de integración frecuentes. ¿no os suena de algo? Pues sí, justo lo que dicen la mayoría de las metodologías ágiles.
