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
enviado por sergio montoro
http://www.lapastillaroja.net/archives/001153.html
http://antitella.blogspot.com/ Jose Manuel Tella Llop
http://antitella.blogspot.com/ Jose Manuel Tella Llop
http://antitella.blogspot.com/ Jose Manuel Tella Llop
Leer las respuestas