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 PreventionLa 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:
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.
Todos conocemos incidentes como estos...
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…
