En los ultimos años hemos visto grandes avances en la industria del software, esto puede verse como una maduracion de la forma de producir software. De las viejas tecnicas empleadas anteriormente solo quedan las malas experiencias, y avanza el uso de metodologias cada vez mas cercanas a otras disciplinas de Ingenieria. El software, que comenzo como una construccion artesanal, y como una tarea de investigacion, muy vinculada a la matematica, hoy en dia se ha convertido en una industria que mueve millones de dolares alrededor del mundo, y que no puede darse el lujo de seguir cometiendo los mismos errores que hace años. Paradigmas como la programacion estructurada (en los ’80) parecia que iba a dominar la industria del software por siempre. La solucion que hemos escuchado desde hace un tiempo es que nuevos niveles de abstraccion iban a permitirnos la liberacion de las tediosas tareas de programacion que no estan exclusivamente vinculadas al dominio del problema que estamos abordando. Asi es como nacio el paradigma de orientacion a objetos, y mas tarde, el concepto de maquinas virtuales, administracion de memoria automatica (con garbage collectors por ejemplo) y otros. Asi hemos descubierto que una de las claves de la alta productividad de ciertos lenguajes de produccion tiene mas que ver con la administracion automatica de memoria (que libera a los programadores de tener que estar solicitando y liberando diferentes areas de memoria) que con la “abstraccion de la plataforma”. Dos ejemplos exitosos de este principio son Visual Basic y Java. En los ultimos dos años, con la aparicion de .NET tambien vemos esta ventaja extendida con nuevos lenguajes como C# y VB.NET. Si bien la orientacion a objetos es una gran ventaja, creo que la posibilidad de no tener que estar preocupandose por temas tecnologicos que no tienen que ver con las “reglas” de negocios que queremos implementar, es inmensa. Habiendo llegado a un nivel de madurez en este flanco, es que aparecen nuevos desafios que permitan la madurez del software como Ingenieria. Parte de esto es la existencia de frameworks (conjuntos de librerias) que no solo estandarizan el codigo y la posibilidad de utilizar multiples funcionalidades que aparecen una y otra vez en los proyectos, sino en la velocidad de utilizar codigo ya probado por otros. Es lo que la ciencia llama ‘pararse en los hombros del gigante’: utilizar lo que otros han construido para seguir adelante con nuestro problema especifico.
MSDN Smart Client Developer Center: Rebooted
El MSDN Smart Client Developer Centerfue actualizado recientemente… Chris Sells ahora sera ahora co-editor con Jonathan Wells del nuevo y mejorado sitio. El objetivo del sitio es ayudar a comprender los smart clients, que son, cuando son lo mas apropiado, y lo mas importante, la mejor y mas eficiente forma de construirlos. Realmente vale la pena consultar el sitio, esta lleno de recursos para los desarrolladores.
Software Factories
Como vengo diciendo en mis ultimos posts, y reflexionando acerca de la complejidad de la construccion del software, es que pienso que es cada vez mas necesario que una compañía de software tenga su propio framework para la construccion de aplicaciones. Tuve la experiencia de trabajar hasta julio de 2004 en una consultora en la que estuve involucrado en el equipo de desarrollo del framework interno y puedo decir que fue uno de los desafios mas interesantes que tuve que abordar en mi vida profesional: dejar de pensar en una determinada funcionalidad y comenzar a pensar en bloques constructivos (pequeños ladrillos) para una aplicacion mucho mas grande, documentar todo, ejecutar tareas de ingenieria, pensar para el mantenimiento, pensar en lo que vamos a estar haciendo de aca a dos o tres años, etc.
En este espiritu es que Microsoft penso el .NET Framework y ahora elabora la estrategia de las Software Factories, pensando en automatizar toda tarea que sea posible. Esta automatizacion (principalmente manejada con generadores de codigo) apunta a reducir los tiempos de produccion del software y relevar a los programadores de las tareas repetitivas, esto ultimo por dos razones: primero, las tareas repetitivas son facilmente reproducibles por un generador de codigo, y ademas, son las que mayor cantidad de errores generan a la hora de programar.
En los proximos años veremos cada vez mas esta clase de asistentes, y esto sera parte de nuestra tarea cotidiana de programacion. Despues de todo, no fue hace tanto que nos maravillabamos con las ‘VBX’ primero, y luego con las ‘OCX’, y con la construccion de software basado en componentes …