En el artículo What Gartner Is Telling Your Boss, Esther Schindler informa en DevSource sobre la presentación de Dale Veccio y Matt Hoyle en Gartner’s Application Development Summit 2006. Centrada en 4 puntos:
• El nuevo ciclo de desarrollo de aplicaciones, en el cual el énfasis se pone en entregar aplicaciones mejor y más rápido.
• Gestión del portfolio de aplicaciones.
• Aplicaciones de tecnología punta relacionadas con Web 2.0
• Gestión de Proyectos y Gobierno Corporativo.
La opinión de Hoyle es que es deseable desarrollar más rápido, pero desarrollar mejor es lo más importante.
Según los analistas de Gartner, en el pasado había programadores de software a medida por un lado y desarrolladores de paquetes prefabricados por otro. Pero en el futuro próximo, la reutilización de código será lacle.
El futuro del desarrollo de aplicaciones no gira alrededor de la productividad personal de los programadores, sino alrededor de ensamblar funcionalidades con componentes.
Mi opinión personal
No sé cuantas veces he visto/oído en los últimos 10 años promesas para el desarrollo de aplicaciones sin escribir código.
Una cosa es usar librerías estándar (incluso si no terriblemente populares como ACE en el que está basado el proyecto Osmius de Peopleware) y otra cosa es el milagro nunca realizado del desarrollo de aplicaciones sin programación.
Voy a compartir dos cosas que he experimentado de primera mano:
1ª) Nuestra experiencia en la reútilización de código que no era de primera división ha sido desastrosa. Si coges una librería muy madura y estable todo va bien. Pero si te vas a SourceForge y coges un proyecto que no esté extensivamente testeado, la cosa puede ir terriblemente mal. Y esto te puede pasar no sólo con aplicaciones desarrolladas por 4 colegas, sino con paquetes de empresas grandes como Sun o IBM a los que los gigantes no prestan excesiva atención.
2ª) Estos entornos RAD que te ensamblan una aplicación en dos patadas clickando y arrastrando pueden ser pan para hoy y hambre para mañana. Están bien para hacer una prueba de concepto. Pero tienden a producir engendros de varias toneladas de peso en código que a la hora de mantener dan muchos problemas. A todos nos gustaría coger las especificaciones, hacer 4 clicks e irnos a tomar unas cervezas, pero existe una complejidad inherente a algunos problemas que no puede eliminarse. A lo más los entornos RAD ocultan parte de esta complejidad, pero cuando llega la hora de la verdad los problemas que intentamos soslayar chapuceramente acaban aflorando, a veces de forma inesperada y en el momento más inoportuno del proyecto.
Últimamente es frecuente oir cosas como «eso te coges cuatro librerías PHP y lo tienes hecho en dos patadas». Es la programación del «mantente mientras cobro».
Lo que necesitamos es que haya el mínimo de librerías distintas posibles, pero que estén muy bien testeadas para que sean fiables, rápidas y escalables; a la par que bien documentadas.
Artículos relacionados en VersiónCerø:
Prioridades al escribir código
El modelo de desarrollo reactivo
-
Entradas por RSS -
Entradas Populares