Into the void.

Siguiendo con lo del post anterior, el desarrollo de “mi producto de prueba” entra oficialmente en la etapa de autobombo. Voy a tratar de no ponerme monotemático, así que el siguiente link es lo único que voy a poner explícitamente al respecto por ahora:

“Pasen y vean, qué lindas chucherías” (el que no entienda la referencia que busque la frase, vale la pena).

De alguna manera subestimé (para variar) el efecto psicológico del “lanzamiento”.

No había tenido que dar la cara hasta ahora. En mis trabajos anteriores picaba código que luego se testeaba e iba a producción donde fallaba miserablemente. Así fue siempre, igual que ahora. Pero la responsabilidad era compartida. La verdad sea dicha: las consecuencias inmediatas (llamados a media noche, apuros, gritos e insultos) solían recaer más en las áreas de soporte, testing y calidad (cuando había) que en mi escurridiza persona. No se puede hacer bugfixing con 20 monos desesperados gritándote alrededor y otros 20 por teléfono / skype / email / twitter / señales de humo avisándote de que el sitio no anda. Así que mientras yo arreglaba la cosa otros atajaban los sopapos.

Personalmente, esa división de tareas siempre me pareció (y me sigue pareciendo) bien. Pero ahora no hay con quién dividir el trabajo y, lo que es peor, nadie se desespera. Ojalá hubiese alguien tan necesitado de esta humilde herramienta (que feo suena eso) como para llegar al extremo del reclamo. Lo que sucede es algo peor: la nada misma. El vacío, fardos rodando, grillos a la luz de la luna.

Si te fuiste a dormir, tu sitio puede estar en llamas escupiendo 500 para todos lados que no te vas a enterar. ¿Los usuarios? Si te he visto no me acuerdo. Un amigo, un conocido o un familiar manda un mail con un “che, no anda” y con suerte te enterás a la mañana siguiente. Cada uno de esos desconocidos arrastrados a pulso, sangre, sudor y lágrimas (qué exagerado) ahora están viendo (si es que no se fueron ya) la aplicación retorcerse lastimosamente en medio de un infarto de javascript, con el pulgar en el Alt y el índice a punto de dar el Tab definitivo. Por lo menos en el corto plazo.

Por eso, si va a explotar (y al principio va a explotar), mejor que sea entre amigos dispuestos a dar una mano, avisar: probar de vuelta más adelate. Pero eventualmente hay que sacar la red y seguir haciendo piruetas. No es para tanto… si pinchó es que anduvo por un rato, ¿no?

Curados de espanto.

No son todos malos hábitos los que adquirimos los programadores en el transcurso de nuestra vida profesional. Para nivelar un poco quiero traer a cuento varias características que casi todos compartimos, y que de seguro estarán presentes en un buen programador… tienen que estar presentes en un buen programador, ya que todas giran alrededor de un tema que es central en el desarrollo de software: los errores.

Todo software no trivial tiene errores (y como siempre digo, la mayoría de los triviales también). Y si por buena ventura un software en particular no los tiene seguro que los requerimientos que le dieron origen sí. Y si por alguna de esas casualidades cósmicas los requerimientos (y por tanto el software) son consistentes en los papeles, seguro que el usuario o el analista o el redactor o el programador se ha equivocado en su interpretación u omitido alguno de ellos con tal mala suerte que el resultado es consistente aunque, por supuesto, erróneo… y en el imposible caso de que todo esté bien… serán las necesidades del cliente las que cambien o las que cambiarán en breve.

Y hay que tener en cuenta que los innumerables errores detectados (ya sea durante el desarrollo o como defectos en el producto) son apenas una pequeña fracción de los que cometemos todos los días… y sin embargo aquí estamos.

Aunque a veces sucede, no es usual que ante un problema un programador se rasgue las vestiduras, se deprima, paralice o caiga presa de delirios apocalípticos. Esto es, básicamente, porque nuestra vida laboral es una eterna sucesión de problemas y soluciones… que generan más problemas.

¿Qué es lo que –al menos creo yo que- he aprendido?

El camino para estar a salvo de los problemas no es evitar que se produzcan (son inevitables) sino tener alternativas.  Para eso existen los resguardos, los procedimientos alternativos, las salidas de emergencia. Prevenir no es sólo prevenir el problema, sino también sus consecuencias.

Los manotazos de ahogado no sirven. La suerte existe, pero es escasa y no se puede confiar en ella. Hay que medir el costo de un intento a ciegas. ¿Podemos hacer una prueba rápida, a ver si funciona? ¿No romperemos algo más en el intento? Bueno, hagámosla. Pero no podemos perder tiempo tirando tiros al aire, la magia no existe y hay que pensar, buscar, investigar, rastrear, no queda otra.

Identificar precisamente el problema es siempre el primer esfuerzo. Tratar de arreglar “algo” que no se sabe qué es es sencillamente imposible. Trabajar sobre las consecuencias es una opción para ganar tiempo, pero nunca una solución a mediano o largo plazo.

No se puede resolver un problema de fondo sobre la emergencia. Cuando se presenta una emergencia hay que resolverla (en lo posible rápidamente) para aliviar la presión y poder pensar y resolver el problema de fondo con tranquilidad… Creo que en esto todos fallamos más de una vez, tal vez no tanto en la resolución rápida, sino en la disolución de la causa subyacente. ¿Cuántas veces dejamos parches provisorios como soluciones “definitivas” que no tardan en crear más y más graves apuros?

Presionando no se resuelve nada, por lo menos en sistemas. No es de mucha ayuda gritarle lo obvio al administrador de la red –que todas las terminales están fuera de servicio o que el mundo va a explotar-. Si encuentra la solución en un tiempo razonable será a pesar de ello y no gracias a ello. Ya habrá tiempo de repartir responsabilidades y amenazas luego, hay que concentrarse en buscar una solución.

Hay que dejar trabajar. Si nos es posible paliar las consecuencias o aliviar la presión, ésa es la forma de ayudar. Y si no está entre nuestras posibilidades hacerlo… mucho ayuda el que no estorba, dice el refrán.

Aprender por prueba y error implica resolver, aunque sea parcialmente, problemas de fondo. De cada problema, de cada situación, tenemos que quedarnos con alguna mejora. Puede ser pequeña, tal vez no una solución completa, tal vez apenas una alerta temprana para la próxima vez, algo, lo que sea. Si vivimos en un interminable devenir de emergencias, la única forma de salir de ello es de a poco, aprovechando el poco tiempo que nos queda para ganar más tiempo.

Proyecto de software típico.

Me acordé de esta secuencia, y estuve un buen rato buscándola por internet. No hay mucho mas que decir.