Recently in Desarrollo Category

Imagen via Wikipedia

Auto servicio a demanda. Un consumidor puede unilateralmente provisionar capacidades computacionales, tales como tiempo de servidor y almacenamiento en red, de acuerdo a la necesidad y en forma automática sin requerir de una interacción humana con cada proveedor de servicio.

Amplio acceso a través de la red. Las capacidades están disponibles  a través de la red y se accesan a través de mecanismos estándares que promueven el uso desde plataformas clientes diversasa (por ejemplo, teléfonos móviles, laptops, PDAs).

Disponibilidad de recursos. Los recursos computacionales del proveedor se agrupan para servir a múltiples consumidores usando un modelo de arriendo múltiple, con diferentes recursos físicos y virutales asignados dinámicamente y reasignados de acuerdo a la demanda del consumidor. Hay un sentido de independencia de la localización en que el consumidor generalmente no tiene control o conocimiento de la localización exacta de los recursos provistos, pero puede  especificar la localización a un nivel más alto de abstracción (por ejemplo, un país, estado o datacenter). Ejemplos de estos recursos incluyen el almacenamiento, procesadores, memoria, ancho de banda y máquinas virtuales.

Rápida Elasticidad. Las capacidades pueden ser rápida y elasticamente provisionadas, en algunos casos automáticamente, para escalar rápidamente y ser liberadas rápidamente para reducir la escala de operación. Para el consumidor, las capacidades disponibles para el provisionamient a menudo parecen ser ilimitadas y pueden ser compradas en cualquier cantidad en cualquier momento.

Servicio Medido. Los sistemas en nube automáticamente controlan y optimizan el uso de recursos al aprovechar las capacidades de medición en cierto nivel de abstracción apropiado para el tipo de servicio (p.ej. almacenamiento usado, procesamiento, ancho de banda, cuentas de usuario activas). El uso de recursos puede ser monitoreado, controlado y reportado, proveyendo transparencia para ambos, el proveedor y el consumidor del servicio utilizado.

Nube tipo Software como un Servicio(SaaS). La capacidad provista para el consumidor es usar las aplicaciones del proveedor corriendo en una infraestructura en la nube. Las aplicaciones son accesibles desde varios dispositivos clientes a través de una interfaz de cliente "delgada" como un navegador web (p.ej. correo electrónico en la web). El consumidor no administra o controla la infraestructura de nube subyacente que incluye redes, servidores, sistemas operativos, almacenamiento o incluso las capacidades individuales de la aplicación, con la posible excepción de ciertas configuraciones específicas para el usuario en la aplicación.

Nube tipo Plataforma como un Servivio (PaaS). La capacidad que se le provee al consumidor es la de desplegar en la infraestructura en la nube las aplicaciones, propias o adquiridas, creadas usando lenguajes de programación y herramientes soportadas por el proveedor. El consumidor no administra o controla la infraestructura de nube subyacente, incluyendo redes, servidores, sistemas operativos o almacenamiento, pero tiene control sobre las aplicaciones desplegadas y posiblemente sobre las configuraciones del entorno de alojamiento.

Nube tipo Infraestructura como un Servicio (IaaS). La capacidad provista al consumidor es provisionar procesamiento, almacenamiento, y otros recursos computacionales fundamentales donde el consumidor es capaz de desplegar y ejecutar software arbitrario, el que puede incluir sistemas operativos y aplicaciones. El consumidor no administra o controla la infraestructura de nube subyacente pero tiene control sobre los sistemas operativos, almacenamiento, aplicaciones desplegadas y posiblemente un control limitado sobre componentes selectas de las redes (p.ej. los firewalls de sus hosts).

Nube Privada. La infraestructura de nube es operada solamente por una organización. Puede ser manejadas por la organización o una tercera parte y puede existir siempre, o ante una situación específica.

Nube Comunitaria. La infraestructura es compartida por varias organizaciones  y soporta a una comunidad específica que tiene preocupaciones compartidas (p.ej. misión, requerimientos de seguridad, políticas, y consideraciones de conformidad). Puede ser administradas por las organizaciones o una tercera parte y puede existir permanentemente o ante situaciones específicas.

Nube Pública. La infraestructura es provista al público general o a un grupo de industria grande y es propiedad de una organización que vende servicios en nube.

Nube Híbrida. La infraestructura de nube es la composición de dos o más nubes (privadas, comunitarias o públicas) que permanecen como entidades únicas pero están enlazadas juntas por una tecnología estandarizada o propietaria que permite la portabilidad de datos y aplicaciones. (ej. cloud bursting (ruptura de nubes) para permitir el balanceo de carga entre nubes).

En 1989 Richard P. Gabriel introdujo el concepto de Peor es Mejor (Worse is better), o el estilo New Jersey, que
corresponde a una filosofía de diseño del software en que la simplicidad de la interfaz, y sobretodo de la implementación
es más importante que cualquier otra propiedad (incluyendo la correción, consistencia y completitud).

Este concepto fue introducido como un capítulo de una presentación que Gabriel hizo aen una coferencia de Lisp, y pueden
leerlo en la siguiente dirección: The Rise of Worse is Better

En el ensayo Richard Gabriel plantea que existe un estilo de diseño de software que el denomina el estilo MIT/Stanford
(es decir, un estilo académico) que básicamente tiene las siguientes características:

• Simplicidad: el diseño debe ser simple, tanto en implementación como interfaz. Es más importante que la interfaz sea simple que la implementación.
• Correctitud: el diseño debe ser correcto en todos los aspectos observables. La incorrectitud simplemente no está permitida.
• Consistencia: el diseño no puede ser inconsistente. Se permite que un diseño sea ligeramente menos simple y menos completo para evitar incosistencia. La consistencia es tan importante como la correctitud.
• Completitud: el diseñ debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubiertos. A la simplicidad no se permite reducir excesivamente la completitud.

Como ven estas son características que se consideran buenas y positivas.

Por otro lado, la filosofía Worse Is Better, Peor es mejor, o estilo New Jersey, en referencia a los Bell Labs, la cuna de C y Unix es ligeramente diferente en los siguientes aspectos:

• Simplicidad: el diseño debe ser simple,tanto en implementación como interfaz. Es más importante que la implementación sea simplea que la interfaz. La simpliciddad es la consideración más importante en el diseño.
• Correctitud: el diseño debe ser correcto en todos los aspectos observables. Es ligeramente mejor ser simple que correcto.
• Consistencia: el diseño no debe ser demasiado incosistente. La consistencia puede ser sacrificada por la simplicidad en algunos casos, pero es mejor eliminar partes del diseño que tienen que ver con circunstancias menos comunes que introducir complejidad en la implementación o inconsistencias.
• Completitud: el diseño debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubierntos. La completitud puede ser sacrificad en favor de cualquier otra cualidad.
  De hecho, la completitud puede ser sacrificada siempre que la simplicidad de implementación esté amenazada. La consistencia puede ser sacrificada para alcanzar completitud si se mantiene la simplicidad, especialmente la inconsistencia de la interfaz no tiene valor.

Según Gabriel el enfoque "peor es mejor" produce software más exitoso, porque permite una difusión viral.

Si uno desarrolla con este principio parte por una base que es básicamente buena, que quizás implementa entre un 50% a un 80% de las funcionalidades requeridas, no tiene que tener todo implementado. Lo importante es liberar el producto como si fuera n virus, de modo que cuando este "virus" se difunde se generan presiones para mejorar y llevar la funcionalidad al 90%,
pero por otro lado los usuarios han sido condicionados a aceptar algo que no cumple todo lo esperado ("lo correcto").

Con el software peor-es-mejor ocurre que "primero gana aceptación, luego condiciona a los usuarios es esperar menos, y finalmente será mejorado al punto que es casí lo correcto". Hay un beneficio adicional del estilo New Jersey, y es que al no ser piezas de software complejas y monolíticas, los sistemas más grandes deben ser diseñados de modo que reusen componentes, lo que genera una tradición de integración.

Ustedes pueden optar por no seguir el camino de "peor es mejor", pero se van a encontrar con 2 escenarios desagradables y frustrantes, en que tienen que definir un "gran sistema complejo", que requiere elaborados diseños, complejas implementaciones, y probablemente una infraestructura especial para poder operar, o un escenario en que el diseño es eterno, los avances de implementación son siempre pequeños pasos en yna serie infinita que no termina nunca, y donde es imposible implementar "lo correcto".

La lección es que a menudo no es deseable ir por "lo correcto". Es mejor tener primero la mitad de lo que se necesita de modo que se difunda como un virus. Una vez que la gente se ha enganchado, tomarse el tiempo para mejorar y llegar al 90% de "lo correcto".

Yo lo he hecho, he implementado servicios en que hemos partido con la mitad del desarrollo completado (o menos), pero el servicio ha ganado aceptación, y ha crecido y evolucionado con el uso y la retroalimentación de los usuarios. Al principio todo parece caótico, pero finalmente, llega un día en que el sol brilla y sin darte cuenta estás dando un servicio mucho mejor
de lo que pensaste, completamente automatizado y funcionando al 90% de lo que se suponía, pero te has dado cuenta que era eso o que necesitabas.

También he ido por el camino contrario, en que nos hemos tomado todo el tiempo del mundo para construir algo perfecto, un producto ideal, pero sin lograr nada, ni siquiera una venta.

En mi experiencia esta aproximación es mejor, y funciona, aunque, como todo en la vida, debe usarse con moderación.

¿Se imaginan tener que agregarle un nuevo dormitorio, y un jacuzzi al baño,  a cada departamento de un edificio de 24 pisos, todo durante un fin de semana, y con los inquilinos dentro?

Hace unos meses atrás hablé con ex profesor auxiliar de ingeniería de software, en una universidad tradicional. En esa ocasión me mostró un examen, donde se les pedía a los alumnos comentar la afirmación del Chaos Report sobre la alta tasa de fracaso de los proyectos de software. ¿Qué leseras les enseñabas a tus alumnos?! fue mi comentario sarcástico. 

Me acordé de esa discusión por un post reciente de Alejandro Barros, que parte provocándonos con la frase:

¿Se imaginan que sólo el 32% de los proyectos inmobiliarios o de infraestructura fueran exitosos?

Y lo titula: Comportamiento de proyectos TI: Están en deuda!

¡En Deuda! por supuesto no estoy de acuerdo, y tengo varios argumentos, y voy a exponerlos en este y varios post más.

El post de Alejandro parte mencionando el famoso Chaos Report, del que algo hemos hablado en el pasado, pero va más allá, porque aporta otras interesantes cifras, como esta encuesta y  artículo en Dr Dobbs Journal. Vamos a ir por parte, a ver si le encontramos sentido y si debemos reconocer esta deuda o no (ya tengo muchas deudas para tener que asumir una más).

El tema es polémico, por cierto, porque da para todo tipo de cifras, y abusos. Por ejemplo, Oracle dice que el 90% de sus proyectos son exitosos (toma!). Bueno, ya saben lo que dice House, todos mienten! 

En este post nos preocuparemos del Chaos Report, y dejaremos para otros artículos el seguir analizando las otras fuentes interesantes que aporta Alejandro, para terminar con una reflexión sobre la naturaleza del software, y porque creo que no es aplicable esta supuesta deuda.

El Reporte del Caos

Desde 1994 el reporte del Standish Group, el famoso Chaos Report,  se ha vuelto en el patrón dorado sobre la calidad de los proyecto TI, la conclusión lapidaria es: sólo el 15% de los proyectos TI tienen éxito. y nos muestra este bonito gráfico:

¡Pero que desastre! Por qué no me dedico a otra cosa mejor...

Hay varias cosas que decir sobre este reporte: ¿cuál es la definición de éxito o fracaso? ¿qué tipos de proyectos se analizan? ¿de que envergadura? 

Robert Glass se hace las mismas preguntas que me hago yo con respecto a este reporte, en su artículo de agosto de 2006 de la Communications of ACM: "The Standish Report: Does It. Really Describe a Software Crisis?"

"Ha habido mucha discusión en las últimas décadas sobre algo llamado  "la crisis del software". Aquellos que hablan de tal crisis alegan que los proyectos de software están siempre sobre el presupuesto, con retraso, y son poco fiables.

Esta manera de pensar sobre una crisis del software representa una condena de la práctica del software. La imagen que se pinta es la de un campo del cual no se pueden esperar productos válidos.

...

Pero es importante retroceder y hacer algunas preguntas sobre este pensamiento de crisis:

• ¿Representa a la realidad?
• ¿Está soportado por los resultados de la investigación?

[...] La realidad es, puedo afirmar, que estamos en medio de lo que los sociólogos llaman la era de la información, una era que sería simplemente imposible sin una plenitud de proyectos de software exitosos. ¿Acaso esto sugiere que el campo del software está realmente en crisis? No de acuerdo a mi manera de pensar.

,,, A primera vista, hay una gran cantidad de publicaciones que concluyen que realmente existe esta crisis.Muchos estudios académicos aseguran  que la crisis del software es la razón detrás del estudio particular sobre el que están abogando, un concepto cuya intención es hacer frente y quizás solucionar esta supuesta crisis.

Los gurús del software a menudo se enfrascan en esta misma defensa, y con esta enmarcan su tópico favorito como solución a la crisis.

Pero hay un problema subyacente aquí. Muchos de estos artículos académicos y reportes de gurú citan la misma fuente para esta preocupación por la crisis, un estudio  publicado por el Standish Group más de una década atrás, un estudio que reporta altas tasas de falla, del 70% o más, y minúsculas tasas de éxito, un estudio que condenaba la práctica del software por el título que emplearon para la versión publicada de su estudio: El Reporte del Caos.

Así que el reporte de Standish podría ser considerado fundamental para muchas de las reclamaciones sobre la crisis. ¿Qué sabemos realmente de este estudio?

Esa pregunta es de una creciente preocupación en el campo. Varios investigadores, interesados en encontrar los orígenes de esta información clave, han contactado a Standish y les han pedido una descripción de su proceso de investigación, un resumen de sus últimos descubrimientos, y en general una discusión erudita de la validez de sus descubrimientos. Ellos han planteado estas cuestiones porque muchos estudios de investigación conducidos por académicos e investigadores de la industria llegan a datos largamente inconsistentes con los resultados de Standish.

Dejenme decirlo de nuevo. Los resultados de estudios objetivos no soportan, en general, las conclusiones de Standish.

Repetidamente estos investigadores que han preguntado a Standish han sido rechazados. Es aparente que Standish no ha intentado, al menos en el pasado, compartir mucho sobre de donde vienen los datos usados para el Reporte del Caos.

Y esto, por supuesto, plantea un cuestionamiento a la validez de sus conclusiones.

Pero ahora hay una nueva noción acerca de estos resultados de Standish. Un par de investigadores, peinando cuidadosamente el reporte original de Standish, descubrieron una descripción clave de donde podrían venir estos resultados. El reporte dice, en palabras propias de Standish, "Nosotros entonces llamamos y enviamos por correo un número confidencial de encuestas a una muestra aleatoria de altos ejecutivos IT, preguntándoles que compartieran historias de fracasos."

Noten las palabras al final de la oración: "..compartieran histoias de fracasos." Si esta es, de hecho, la base de contactos que Standish hizo con sus participantes en las encuestas, entonces los resultados del estudio están obviamente sesgados hacia los reportes de fracasos. ¿Y que importancia tiene si el 70% de los proyectos que son sujetos de historias de fracasos eventualmente fallan? No mucha.

Hay un dramático caso de deja vu acá. En los 1980s era popular citar la noción de la crisis del software citando el Estudio GAO, un reporte de la Accounting Office del gobierno norteamericano que reportaba una terrible tasa de de fracasos entre los proyectos de software estudiados. Pero en este caso, después de haber ido demasiado lejos, un investigador alerta re leyó el Estudio GAO y encontró que  este admitía, bastante abiertamente, que este era un estudio de proyectos conocidos por estar fracasando en el momento en que los datos eran recolectados. Una vez que este problema fue identificado el Estudio GAO fue rápidamente desechado como cita para soporta la noción de crisis del software. Es interesante que el primer estudio de Standish apareció no mucho después.

Glass termina preguntándose si será cierto que el estudio de Standish adolece del mismo problema que el Estudio GAO, y la verdad es que no sabemos. A pesar de que le han solicitado muchas veces la información al grupo Standish no ha sido posible obtenerla.

Hay una entrevista en InfoQ a Jim Johnson, de Standish, donde se le pregunta directamente sobre las críticas de Glass a su trabajo, les dejo el enlace,  para que juzguen por si mismos, personalmente creo que elude el tema.

En lo personal creo que el Chaos Report debe dejar de ser considerado serio hasta que las legitimas dudas de Glass y otros hayan sido resueltas.