martes, enero 31, 2012

Mejorando los procesos...

 Quiero reunir aquí dos comentarios que leí o releí estos últimos días, que contienen observaciones fruto de la experiencia reflexiva. Y que más veces de las deseables son ignoradas.
En el primer caso, se trata de recomendaciones de Gerald Weinberg acerca del estudio del alcance de los pequeños cambios, aquellos que parecen no tener importancia...hasta que es demasiado tarde. Dice Weinberg (en inglés):
Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In Responding to Significant Software Events, I give five examples that should convince you.

The national bank of Country X issued loans to all the banks in the country. A tiny error in the interest rate calculation added up to more than a billion dollars that the national bank could never recover.

A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program. A slight error in one constant was multiplied by millions of customers, adding up to X dollars that the utility could never recover. The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.

 (...)
The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:

1. There is an existing system in operation, and it is considered reliable and crucial to the operation.
2. A quick change to the system is desired, usually from very high in the organization.
3. The change is labeled "trivial."
4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.
5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.
6. The change is put directly into the normal operations.
7. The individual effect of the change is small, so that nobody notices immediately.
8. This small effect is multiplied by many uses, producing a large consequence.

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management's first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.
10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.
11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]
12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.
13. Higher managers are left untouched. After all, what could they have done?
The First Rule of Failure Prevention
Once you understand the Universal Pattern of Huge Losses, you know what to do whenever you hear someone say things like:

• "This is a trivial change."
• "What can possibly go wrong?"
• "This won't change anything."

When you hear someone express the idea that something is too small to be worth observing, always take a look. That's the First Rule of Failure Prevention:

Nothing is too small to be unworthy of observing.
 La segunda reflexión la hizo hoy el "tendero digital", muy oportuna, sobre los inconvenientes de la especialización en el análisis de procesos, por la pérdida de visión del conjunto del problema. Lo que "el tendero" dice:

Hoy otro tema del que ya he hablado aquí antes. Pero es que me he visto involucrado en un proyecto que cuando lo he entendido… pues eso que no me resisto contarlo y volver a reiterar una gran verdad: “La informatización por si misma, no resuelve problemas”. Y otro que podríamos ver relacionado, es la gran escasez de profesionales más generalistas y menos especialistas. Estamos en una época en la que se necesita a más gente con talentos cruzados. Personas que sean capaces de ver más de una dimensión de un solo problema. Como diría un amigo y lector del blog, necesitamos a más Leonardos y menos especialistas. En el mundo de la gestión informática, siguen faltando arquitectos, visionarios que sean capaces de tener todo el proyecto en la cabeza. No gente que da martillazos, otros que atornillan, los de allí al lado que pintan… y no ven más alla de su pequeña tarea. 
Hace ya muchos años, el Departamento donde yo trabajaba en mi empresa de por las mañanas se llamaba: “Análisis y racionalización de procesos”. Si os fijáis en el nombre, por ningún sitio aparece el nombre de informática, digital o cosas más modernas. Y también destaca en el nombre la palabra procesos. Esa era nuestra tarea y racionalizar un proceso no significaba automáticamente hacer un programa de ordenador, eran muchas más cosas.  Era el tiempo en que todavía trabajábamos con pantallas de fósforo naranja de 9 pulgadasy pico (ostias como una tablet cualquiera, éramos ya visionarios). Con el paso de los años nos fueron cambiando el nombre (y también las funciones) y ahora somos Desarrollo, así sin más. Que por cierto no desarrollamos ya nada, pero eso sería otra historia (jugosa, pero para otro día)
Bueno, me dejo de introducción. Me llaman el otro día para plantearme unas dudas de un proyecto. Les contesto y les digo que puedo preparar unos ejemplos de carga para lo que están haciendo y que lo prueben, pero que se puede hacer y además es sencillo. Mientras prepara los ejemplos, empiezo a no entender algunas cosas (o entenderlas demasiado bien). Así que miro quien ha pedido el proyecto y lo llamo. Después de un buen rato, se confirman mis temores. Y me doy cuenta que después de 20 años, volvemos al principio. En la época de las pantallas de fósforo, teníamos muchos procedimientos, que obligaban a capturar los datos en papel y enviarlos a un centro de grabación de datos. Allí donde si tenían PCs o terminales más grandes que uno de 9”, pues traspasaban la información del papel al sistema informático. Estuvimos casi un lustro hasta que al final pudimos matar ese tipo de procesos. Recuerdo lo felices el día en que por fin pudimos eliminar la toma de datos en papel y conseguir que con la primera captura de datos en el PC, todo el sistema funcionara. Lo que me estaban pidiendo, era volver al sistema anterior con una sola diferencia, los que escribían en papel y cargaban en sus terminales eran empresas externas. Pregunté si alguien se había planteado los costes del proyecto, si alguien sabía porque la primera captura de datos no nos servía… y todo fue encogimiento de hombros. Pregunté si la persona de la empresa externa conocía bien lo que estaba haciendo, si teníamos seguridad con los datos en papel. No supieron que contestarme.
 Nadie piensa en racionalizar los procesos. Entre otras cosas, porque no hay nadie que vea el proceso como un todo. Cada uno ve su parte y la hace sin preguntar. Como en cada paso hay un especialista, pues éste solo resuelve su parte, nadie se plantea el conjunto, el proceso completo y global. Además como todo el mundo tiene formación técnica, pues la solución es impecable desde ese punto de vista, pero es un despropósito desde la racionalización y ahorro de tiempo. Pero esa parte no preocupa, no sale en los seguimientos. Lo que preocupa es que la petición entro el día d, el día d+15, ya teníamos el análisis y el día d+45 tendremos una versión de pruebas. Y luego el día d+60 estará en real. Como hemos cumplido las fechas todo ha sido un éxito. Que lo que hemos creado sea más feo y más dispar que el monstruo de Frankestein,  eso no importa y que sea más difícil de montar y entender que un mueble de Ikea tampoco…
 Todos conocemos incidentes como estos...


lunes, enero 23, 2012

Plex => WebClient => Ipad

Para usuarios de Plex, o interesados en mover un modelo a aplicaciones móviles: una pequeña presentación de WebClient adelanta bastante información acerca del proceso de creación de una aplicación desarrollada para Ipad con Plex. No es posible entrar en detalles sin la documentación esperada para la versión 1.8, pero da una idea de los pasos a seguir, básicamente en la misma vía que lo necesario para construír una aplicación web estándar de Webclient, pero en una Mac: Plex [en una máquina virtual]=> Eclipse [Indigo en este caso] => [PhoneGap] => Código listo. Brevemente se explica también la variante Android.

domingo, enero 22, 2012

Enseñanza, en el camino del libro frente al ebook?

Rebecca J. Rosen, en un artículo de fin de año en The Atlantic, habla de "cinco cosas que tememos que las nuevas tecnologías reemplazarán", en las que incluye libros, diarios, maestros, escuelas, y correo postal. Podríamos decir que estos cinco blancos bienen siendo dados por muertos desde hace ya algún tiempo, y seguirán estando en la lista por varios años más, particularmente para el caso del correo postal, los diarios y los libros, en ese orden. Sin duda, no sólo Rebecca prevé este camino: especialmente en algunos casos (libros y diarios) esto se ha convertido en preocupación y disputa universal, y particularmente entre sus actores (SOPA o Ley Sinde, entre otras manifestaciones).
¿Es esto positivo o no? Sigo a dos especialistas en tecnología cuya actividad se da alrededor de este hecho: Nicholas Carr y Kevin Kelly, y no aportan muy positivas reflexiones sobre el cambio en curso (1, 2). Carr, particularmente, descree crecientemente de las ventajas de las nuevas formas de aproximación al conocimiento, sosteniendo que se empobrece, y que la atención y concentración disminuye. Sus opiniones van dirigidas en general a Internet como instrumento de conocimiento, sosteniendo que el análisis se dispersa, y la atención vuela de un asunto a otro, perdiendo el foco.
Si aplicamos esta opinión a los dos puntos que Rosen incorpora como nuevas áreas que cambiarán (escuelas y maestros), se puede coincidir con Carr completamente: si acaso la escuela y los maestros pasaran a ser un auxiliar remoto, abstracto e impersonal, la calidad de la educación obtenida cambiaría radicalmente para peor. Por supuesto, una mala escuela y un mal maestro también producen una degradación de la educación, pero eso se mejora a la larga, rectificando el trabajo de escuela y maestro. Pero esa mejora no es tan viable (o nada viable) si la educación se obtiene fundamentalmente a través de Internet o cualquier otro mediación remota entre el maestro (si acaso existe y no hablamos de una aplicación "inteligente") y el alumno. Así como estoy seguro de que los programas "un alumno, una computadora" (Argentina, Uruguay, Chile) no lograrían resultados sin el maestro al lado guiando su uso, mucho peor aún sería si el cuerpo mismo de la enseñanza fuera confiado a una aplicación única y remota: no habría inteligencia artificial capaz de resolver lo que un recinto con un maestro y un puñado de alumnos deliberando logra.

domingo, enero 15, 2012

Webclient 1.8 anunciado

CM First ha publicado una presentación que adelanta la salida de su versión 1.8, y programa la 2.0. Debo decir que conozco de primera mano la versión 1.8, y puedo asegurar que en principio la versión agrega confiabilidad y robustez, sin contar cualquier otro cambio que incluyera. La principal novedad es el lanzamiento oficial del soporte de aplicaciones móviles (Ipad, Android) usando patrones de Sencha, HTML5, CSS3. Arrastrar y soltar, exportar a Excel y otros, almacenamiento local, manejo de temas como conjuntos de definiciones de estilo, son aspectos que se agregan. Soporte de servicios web,  portlets y la nube de Amazon son anunciadas, y veremos hasta dónde es aprovechable su extensión. Webclient 1.8 está testeada sobre la próxima nueva versión de Plex (7.0), que está en este momento en pleno beta. Buenas noticias...

Tecnología y educación

Alberto Mordojovich, country manager de Dimension Data Chile, a propósito del porqué del desprestigio del uso de la informática en el sector público, dice en América Economía:
En educación se ha malgastado una fortuna en el proyecto Enlaces, distribuyendo computadores en las escuelas y liceos descuidando su mantención, operación y sin conexiones de calidad mínima a internet. Los resultados son desastrosos: computadores que nunca se usaron, otros que se robaron, profesores que no saben usarlos, sostenedores que no ganan un peso extra por su cuidado y uso, etc.
Apreciaría mucho una evaluación independiente, y mejor incluso más de una, acerca del real destino de esta iniciativa y otras afines en Argentina, Chile y Uruguay. Las observaciones de Mordojovich muy probablemente serían igualmente rotundas en todos los casos: parecería que se invierten los términos, pensando que poniendo un computador en el escritorio de un alumno automáticamente su educación se potenciará. Así como Internet es un medio, también lo es el computador, y no se encuentra en la hojarasca de información sobre el tema, nada sobre el qué, y mucho sobre el con qué. Leer frases como "hay que entrenar en su uso al comunicador, porque las maestras se oponen, pero cuando conocen el tema se encantan" permiten intuír que más allá del medio, no hay más nada.