Sobre los errores

"La mayoría de expertos está de acuerdo en que la causa más probable de destrucción del mundo sería por accidente; y aquí es donde entramos nosotros: somos profesionales de la informática, causamos accidentes" -- Nathaniel Borenstein

Ok. Desarrollamos software y cometemos errores. Muchos errores. Creo que el inventó "pato criollo" (cada paso una cag...) estaba pensando en nosotros. Y es verdad.

Desarrollo software profesionalmente desde hace... 10 años. Desarrollo software (por diversión o porque sí) desde hace 16 (saquen sus cuentas). Todavía no puedo decir que le haya puesto el moño a nada. Es decir nada de lo que hice anda 100% bien.

El software es "buggy". Todo software no trivial tiene errores, y algunos triviales también. Cuando digo todo es todo. Por ejemplo... los sistemas de control de las plantas nucleares, los que administran el tráfico aéreo, el de trenes... los que controlan piezas de hardware como ascensores, máquinas utilizadas en medicina, armas nucleares... sí, tienen errores. Yo duermo como un bebé cuando viajo en avión, incluso cuando me subo al ascensor de un rascacielos (a veces termino apoyado en el hombro de un desconocido).

Es obvio que el software sirve y funciona a pesar de los errores. Los sistemas críticos que mencioné arriba funcionan porque su funcionalidad principal ha sido probada y corregida, y también porque son constantemente supervisados. A nadie se le ocurriría dejar que un programa controle un avión sin supervisión. Tenemos pilotos automáticos, pero al lado hay un piloto de carne y hueso. Y si el día de mañana la tecnología permite que ese humano no esté físicamente en la cabina, estoy seguro que su función será cumplida por otro en otro lado.

Cuando el software no es crítico (de vida o muerte, quiero decir) la cosa se pone más complicada. Sobre todo si nos arriesgamos un par de veces y nos sale bien. Nos volvemos temerarios. Algunos ejemplos de los más graves en los que he participado de primera mano:

• Corregir un bug directamente en una página web en producción (con el cliente al teléfono), y después hacerlo en desarrollo.
• Implementar una funcionalidad "a prueba y error". Es decir, introduciendo casos que la rompen y corrigiéndolos.
• Modificar funcionalmente un sistema a partir de requerimientos verbales, sin anotar nada en ningún lado.
• Hacer que un sistema haga algo para lo que no fue pensado, tocando por afuera sus datos de entrada.
• No hacer backups.
• No llevar versiones.
• Dejar algo a medio hacer pero que aparentemente funciona e irme (síndrome de "mañana sigo").
• Implementar código específico para clientes o usuarios en particular.

Por suerte, si bien pocas veces tuve "accidentes" catastróficos, fui merecidamente castigado por el destino, tarde o temprano. Todo vuelve.

Si no probé ese caso delirante porque era muy difícil de reproducir y al fin y al cabo bastante simple, se rompió un sábado.

Si no versioné me tuve que quedar después de hora porque para corregir una tontería hubo que actualizar todo a la última versión.

Si metí un "if usuario=4" después me pasé horas tratando de entender por qué cuando el tipo creó un usuario nuevo porque se le olvidó la password (y no se le ocurrió restablecerla) se rompió todo.

Y así con todo... tarde o temprano.

¿Por qué no aprendemos? Porque somos humanos, nos olvidamos de lo que salió mal y nos acordamos de lo que salió bien. Porque en algún punto, por más que no me guste, la teoría conductista se aplica también a nosotros. Si el estímulo negativo (quedarse hasta tarde) está separado temporalmente de la causa (hace dos meses dejé algo a medio hacer y me fui a comer) el acto reflejo (si me voy a comer dejo una marca o algo para que no compile) tarda en establecerse... como los perritos, yo no tengo pero un amigo me dijo que cuando reta a la perra lo hace en el lugar en el que hizo la macana.

En realidad sí aprendemos. Terminamos aprendiendo, a lo largo de varios años. Pero trabajamos en equipos con gente que está aprendiendo y que todavía no se quemó lo suficiente. O con gente con mucha suerte (que la hay) o con gente extremadamente hábil para sortear algunos problemas (por ejemplo con una memoria extraordinaria) y que no tiene en cuenta al resto.

O... con situaciones "sistémicas" que hacen que convenga hacer las cosas mal. ¿Cómo? Sí, a veces conviene hacer las cosas mal. Y ahí tenemos (o no) un problema. Voy a inventar algo. Lo juro, esto es puro invento.

Trabajo en una consultora, mis requerimientos son de mínimo alcance, cada uno tardará en implementarse a lo más dos semanas. Soy un junior, me interesa más aprender a usar la nueva herramienta que hacer el software. No conozco el "negocio" y no me interesa, creo que es algo que tiene que ver con facturación. Solamente tengo que sacar un reporte, sumar esta columna, dividir por ésta otra. Así que... lo pienso un ratito, prueba y error, veo los ayudantes, las opciones, voy toqueteando... hasta que cumplo con el ejemplo que me pasaron. Listo. Cierro. Grabo. Sale.

Obviamente no pasa las pruebas. Se levanta un incidente que ¿vuelve a nuestro amigo junior? no, no vuelve, le cae a cualquier otro. Más o menos misma situación. Otro programador resuelve exclusivamente el caso reportado en el incidente. Listo. Cierra. Sale.

Y así hasta que luego de un par de meses la cosa sale, funcionando más o menos bien, se producen un par de errores en producción, se solucionan, listo.

El reporte es, por adentro, un asco. Inentendible, intocable. Cada tanto se corrige un error, aparece otro, y otro y otro... ¿Qué está mal? A mi entender, nada. Repasemos. El junior de la historia aprendió a usar la herramienta, se fue de la consultora a trabajar independiente. Bien por él. En la consultora le hacen una fiesta de despedida. Entra otro junior que cobra un poco menos o un poco más. El cliente utiliza el reporte, sabe que de vez en cuando tiene un problema, pero está contento porque en la consultora lo atienden y se lo corrigen. Paga las horas de mantenimiento. La consultora cobra las horas de mantenimiento y destina una milésima de eso al pago de sueldos. Todos tenemos trabajo, todos cobramos, todos contentos.

Volvamos al ex-junior, ahora semi-senior. Tiene sus primeros clientes, trabajos chicos, pero gana más que en la consultora. Tiene más clientes. Se junta con un amigo, y ya somos dos. Hacen su primer sistema completo. Entregan a tiempo y en forma, algunos meses de mantenimiento intensivo, luego baja la carga de trabajo, siguen con otra cosa.

En algún momento el cliente quiere algo más. Parece fácil, presupuestan y el cliente compra. Manos a la obra... y... pum. Toca acá, se rompe allá, ¿de dónde saco este dato...? ¿cómo era esto...? ¿por qué si esta variable está bien no se muestra en...? Che, apurá que tenemos que ir a ver a fulano o mengano... Perá todavía ni empecé con esto... ¿Pero no era fácil?

El final es abierto. Puede que lo "saquen arando", y bien. Puede que todo vaya mal, puede que el cliente termine contento o puede que termine pensando que es algo demasiado grande y complicado para dos programadores independientes. Lo que es seguro es que en algún momento el semi-senior se convierte en senior. ¿Cuándo? Entre otras cosas, cuando se da cuenta de que tiene que diseñar, reutilizar, organizar, encapsular, hacer arquitectura, llevar versiones, backups, documentos. Si le va bien se convierte en un experto. ¿Cuándo? Entre otras cosas, cuando logra ubicarse en cada situación, y hacer las cosas como más convenga, teniendo en cuenta el presente y el futuro. Cuando pueda sacar las cosas arando cuando corresponde y también ser estricto y prolijo con las normas, cuando corresponde. Y será más experto en la medida en que mejor se ubique, porque cada situación será parecida a otras, pero única en si misma, y el éxito nunca estará asegurado.

Puedo dar fe de que es así hasta el punto de que el junior se convierte en senior... luego diría que es algo que he visto pero no experimentado. Ser "experto" en el sentido que le doy a la palabra en este artículo... sólo puedo decir que hacen falta **más** de 10 años de experiencia profesional.