Identificar el verdadero problema a resolver y diseñar el programa atinado, representa el mayor avance en un proyecto de desarrollo, la parte restante se trata de hacer de manera correcta dicho programa. El problema identificado típicamente continúa co-evolucionando junto con su solución[1], en otras palabras, la solución tecnológica y el problema de negocio se influencian mutuamente. Una noción común dice que, el mayor costo y esfuerzo en la aplicación de software para resolver problemas de negocio, sucede en el desarrollo del mismo, y una vez que está en producción, es sólo mantenimiento y operación, por lo que las mentes brillantes sólo se requieren en el desarrollo; en muchos casos esto sucede al revés, la necesidad de un diseño flexible y adaptable[2] a situaciones poco previsibles —sin importar cuánto esfuerzo de análisis se haya hecho— ocurre en la etapa de mantenimiento, donde el negocio de verdad necesita dicha flexibilidad, por lo que en tales casos, más vale transferir una parte significativa del costo de desarrollo a dicha etapa de mantenimiento. En otras palabras, la actividad de diseñar[3] se requiere a lo largo de todo el ciclo de vida del software.Best practices
Para algunos está claro que, cuando se presenta un best practice, en realidad se está hablando de conocimiento tácito, es decir, conocimiento que sólo existe en la cabeza de las personas y que llegó ahí por su experiencia personal, o por observar de primera mano a otro profesional en plana acción; dicho conocimiento es de difícil acceso, y por lo tanto muy valioso. Lo que no está claro para muchos, es que dicho conocimiento tiene contexto, y su transmisión efectiva requiere una interacción extensa así como una amplia confianza entra las personas, y por ende, no es algo que se transmita de forma escrita —por definición deja de ser conocimiento tácito. El riesgo de tomar como best practice el conocimiento obtenido fácilmente en publicaciones o seminarios reside en la frase: “no tienes que pensar, sólo aplica el best practice”—, pues impide lo que precisamente es necesario hacer para adquirir el conocimiento tácito: pensar en contexto.
Adaptación es clave, el mapa no es el terreno
Una vez que tienes experiencia con un buen número de métodos de diseño, sigue el reto de saber cómo y cuándo adaptar un método a una situación en particular. ¿Qué mantener o qué dejar de lado? ¿Qué agregar? Una manera es ignorar esta complejidad esperando que las cosas simplemente pasen, pero en tal caso, sería mejor dedicarnos a otra cosa y dejar esto en manos de alguien que le importe. El panorama de aplicación de software para resolver problemas de negocio, se observa cada vez más demandante, y la necesidad de métodos dinámicos que se adapten al vuelo será cada vez más necesaria. Un balance adecuado de propiedades como las que presenta Alistair Cockburn[4] (Entrega frecuente, comunicación efectiva, mejora reflexiva, etcétera.) puede ayudar para confeccionar el método de diseño para tu próximo proyecto de desarrollo. Otra opción es esperar que alguna figura autoritaria y no practicante, te diga cómo tienes que programar, o simplemente seguir con la inercia de los proyectos en crisis, donde los integrantes ya saben que el proyecto va a fracasar y que sólo hay que hacer como que trabajas, aceptando que “la realidad es así”.
Conclusiones
David West nos presenta algo que llama curiosidades, en la introducción de su libro[5] y que reflejan ciertos comportamientos muy diseminados en nuestra industria, que parecieran ser muy sólidos y muy bien definidos, pero ante la luz de un poco de investigación, resultan ser sólo malos entendidos. Por ejemplo, ante la pregunta: ¿Cuál es el siguiente paso después de orientación a objetos?, Martin Fowler respondió que se necesita entender realmente el paradigma de objetos como primer paso, antes de pensar en lo siguiente, o cómo dice Anders Hejlsberg[6]: “orientación a objetos antes era como religión y que apenas ahora está empezando a ser realmente útil para cada vez más personas”. La respuesta de David Parnas[7] tiene mucho sentido, cuando responde a la pregunta: ¿Cuáles son las ideas más prometedoras de ingeniería de software en el horizonte?, diciendo que las ideas más prometedoras no están en el horizonte, sino aquí mismo y desde ya hace tiempo, solamente que no han sido usadas como se debe. Ha sido un placer escribir este artículo en sus tres partes. Sus comentarios son bienvenidos: mdorante@hotmail.com
Referencias
1. Wicked Problems, Righteous Solutions
blogs.msdn.com/marcod/archive/2004/06/12/154131.aspx
2. Unconscious Design Defined
blogs.msdn.com/marcod/archive/2005/04/03/
UnconsciousDesignDefined.aspx
3. The Engineering in Software Development – Trails of Design Mastery
blogs.msdn.com/marcod/archive/2004/06/23/163358.aspx
4. Just-In-Time Methodology Construction
alistair.cockburn.us/crystal/articles/jmc/
justintimemethodologyconstruction.html
5. David West. Object Thinking.
6. Life and Times of Anders Hejlsberg
channel9.msdn.com/Showpost.aspx?postid=159952
7. ACM Special Interest Group on Software Engineering (SIGSOFT) Software Engineering Notes. ACM Fellow Profile: David Lorge Parnas
www.sigsoft.org/SEN/parnas.html
Marco Antonio Dorantes Martínez es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod
- Log in to post comments