En el desarrollo actual de aplicaciones informáticas nos encontramos con una gran complejidad. Es difícil y costoso hacer un desarrollo de software. Es necesario dominar al menos un lenguaje, varias APIs y especificaciones, herramientas, procedimientos de compilación, empaquetado, despliegue… literalmente miles de páginas de documentación…
En una de las primeras entradas de este blog, ya traté el tema de la «industrialización del software«, o mejor dicho, la falta de «industrialización». En esta entrada, exponía las que a mi juicio son las causas más importantes para que esto ocurra:
1.- la relativamente joven disciplina de Ingenieria del Software
2.- el alto porcentaje de demanda de software a medida
3.- el bajo grado de reutilización del software
Además de estas causas, o tal vez a consecuencia de ellas, en la construcción de una aplicación de software actual nos damos cuenta de lo tremendamente complicado que es el uso de las herramientas y APIs de desarrollo. Un desarrollador con conocimientos suficientes para programar una aplicación con rapidez y calidad necesita varios años de formación, o mas bien, un continuo aprendizaje diario para poder realizar su trabajo. Evidentemente para que un programador pueda dedicar este tiempo y esfuerzo a su formación se necesita que su sueldo sea acorde a esta cualificación. Sin embargo en países como España se suele menospreciar este perfil considerándolo una especie de de aprendiz, obligado a seguir una carrera profesional en la que pasara con suerte por analista técnico, analista funcional para pasar seguidamente al mundo de la «gestión» como jefe de proyecto o incluso gerente.En este sentido, es clarificador la entrada publicada en en Barrapunto ¿por qué el programador no es la estrella?
Esta es la situación que nos encontramos a diario en las compañías de desarrollo de software. Tenemos una cantidad importante de programadores júniors, mal pagados y seguramente mal formados, que forman la mano de obra que construye estos proyectos «industriales» que son las aplicaciones informáticas.
Si no somos capaces de estandarizar los procesos de fabricación del software, y no fomentamos de verdad la reutilización de los componen, seguiremos ante un «arte» en lugar de una industria. Y no se podrá desarrollar aplicaciones de maner eficiente.
Estamos pues en una situación que esta lejos de ser la deseable, por una parte el desarrollo de aplicaciones informáticas es muy complejo, sin procedimientos estandarizados, y por otro no se tienen profesionales cualificados y con experiencia para realizar estos desarrollos (con frecuencia mal pagados)
¿cual es la solución?
En estos momentos la solución pasa por simplificar el desarrollo, bajando los skills necesarios de los programadores, y aumentando de paso la velocidad de desarrollo (mejorar el time to market). Claro que ¿cómo se consigue esto? En las grandes empresas al menos, esto pasa por que el Área de Arquitectura defina una capa de abstracción por encima de los numerosos y complejos APIs de programación simplificando drásticamente el desarrollo. Por supuesto, debe haber una solución de compromiso entre los componentes propietarios que crea una empresa para poner a disposición del programador y disminuir la complejidad y los estándares imperante sen el mercado. Cuando más cerca de los estándares más complejo será el desarrollo, cuanto más cerca de los componentes propietarios (o esta capa de software que te abstrae de la complejidad) más simple será el desarrollo pero menos personal formado podremos encontrar en el mercado.
Nos guste o no, de la misma manera que en una cadena de montaje de automóviles, no es necesario que sus operarios sean ingenieros industriales, no debe ser necesario que los desarrolladores de software sean ingenieros informáticos. Aunque de la misma manera, si el equipo técnico que diseña los coches son ingenieros industriales ¿no deberían ser ingenieros informáticos los que diseñan las aplicaciones?
Blog de Andrés Hevia 
12/07/2010 at 13:45
simplificar lo complejo? creo haber estudiado que eso no se puede hacer, pero sí puedes atacar la complejidad.
No creo que pueda simplificarse el desarrollo de software, ya que no existe la construcción en serie como tal.
No fabricamos coches en una línea de montaje, sino que diseñamos los conceptos que se presentan en el salón de Ginebra… algunos presentan un Porsche, otros un BMW, otros un Daewoo y otros un DACIA.
12/07/2010 at 17:30
Cuando digo «simplificar lo complejo» me refiero por ejemplo, a tener un servicio técnico que envíe email. Si este servicio se expone mediante un web service con un WSDL conocido, el desarrollador de una funcionalidad de negocio no tendrá que remangarse y estudiar el API SMTP o WebDAV para envío de email de un lenguaje en concreto. Simplemente tendrá que hacer un cliente capaz de enviar un mensaje SOAP que se corresponda con el WSDL.
De esta manera, se reducen los conocimientos necesarios que debe tener un programador, ya que hemos simplificado (se invoca a un web services) lo que era complejo (conocer el API de SMTP o WebDAV).
24/08/2010 at 15:07
Pero es ese ejemplo, no estas «acomplejando lo simple»?.
Estas armando todo un servicio web, WSDL, SOAP para la simple tarea de enviar un correo.
Le pides a un «tecnico» que sepa «enviar un mensaje SOAP que se corresponda con el WSDL» pero que no sepa enviar un correo por SMTP.
No me quedo muy claro, me quedo con la frase del comentario anterior: «sí puedes atacar la complejidad»
24/08/2010 at 15:34
El envió de un email, por ejemplo en Java con el API de JavaMail, no es una cosa trivial. Lo más común es que los programadores de un proyecto nunca lo hayan usado y tengan problemas para usarlo.
En un principio la invocación de un servicio web podría ser mas complejo, sin embargo tenemos herramientas gratuitas que construyen un proxy cliente del servicio sin necesidad e programar.
Sin embargo la ventaja del uso de los web services es que todos tienen un API común y una vez sepas invocar a uno sabrás invocar a cualquiera. Por ejemplo en una empresa tendremos un servicio para enviar email (con SMTP pero también es posible con WebDav a través de Exchange, tenemos un servicio de envió de SMS a través de Movistar y de otro broker distinto con un API distinto, tenemos un servicio que manda fax, otro de impresión que genera un PDF con un informe con dos motores de impresión… Por citar algunos. Yo cuento 7 APIs diferentes, por el contario si son todos servicios web únicamente habrá que saber como generar el proxy (se hace igual en todos los casos).
Por otra parte desde el punto de vista arquitectónico no es conveniente dejar en manos del programador el uso de API que pueden afectar al rendimiento, por ejemplo, para el envío de fax se trabaja con un pool de conexiones por lo es mejor que haya un servicio de arquitectura que envíe fax y se encargue de gestionar estas conexiones ocultando esta complejidad al usuario del servicio.
Saludos