Cuestionando las metaforas en el desarrollo de software
Una adaptación del articulo MetaphoricQuestioning de Martin Fowler
Si alguna vez te haz topado con los terminos Fabricas de software, Arquitectura de software, Ingeniería de software...son metaforas que en pudieran estar haciendo daño a nuestra area.
Por ejemplo la métafora de "ingeniería" de software, como indica Martin Fowler, ha hecho mucho daño a nuestra profesión, al incentivar la separación entre el diseño y la contrucción, una metafora relacionada a la ingenieria civil. De hecho esta es la razon, por la cual el término estudio de software (como un cuarto de diseños) es más adecuado que el término "fábricas" de software.
De similar forma, podemos razonar con el enfoque lean, traído del proceso de manufacturación lean.
Sin embargo, el concepto de métafora en realidad no es malo, puede traer muchos peligros aplicarlos (como los ejemplos que mencione antes), pero puede ser muy útil para hacernos razonar, repensar y formularnos preguntas.
Por ejemplo, uno de los principios del lean manufacturing es la eliminación del inventario. Esto nos hace preguntarnos: Analogamente, en el desarrollo de software, existe algo muy parecido al inventario?. De hecho, muchas personas siente que la documentación es ese analogo. No produce ningun valor, solo cuando el software en sí es entregado.
Aquí la metafora es buena, porque nos ayuda a formularnos esas preguntas, a ver el desarrollo de software desde otro punto de vista.
Sin embargo, las metaforas son malas cuando las usamos para justificar nuestras respuestas. Por ejemplo decir: "dado que en lean manufacturing eliminamos el inventario, y como en el mundo del software, la documentación es el inventario, debemos eliminar la documentación", es justificar nuestra respuesta simplemente por seguir la analogia lo cual es malo. Más bien, debemos ver si esta encaja dentro de nuestro contexto, el desarrollo de software, no simplemente seguir la analogia. En este caso sabemos que debemos intentar reducir la documentación, pero al adaptarlo a nuestro contexto, debemos saber que tipo de documentación en realidad es la que debemos reducir y cual no.