Así no se hacen las cosas por Ernesto Kiszkurno

Hay una frase que se repite por todos lados a la hora de caracterizar a los CIOs y es mantener las luces encendidas . Al principio esa tarea ocupaba la mayor parte de su tiempo. Hoy eso es algo necesario pero no suficiente.  ¿No me creen? Fíjense lo que hice. Busqué en Google la frase " cio keep the lights on " y me puse a revisar los títulos que aparecen en la búsqueda. 2009: Two-thirds of CIO time is keeping lights on 2013: IT leaders who (literally) keep the lights on 2014: ‘Keeping the lights on’ stops CIOs from innovating 2015: do more than just keep the lights on 2018: Report: IT is 'keeping the lights on,' but CIOs must be freed up to innovate ,  2018: Biggest Obstacle to Innovation, IT Leaders Say: "Keeping the Lights On" 2018: Practical CIO: Agility, speed, and business alignment Si jugáramos a deducir el pensamiento reinante en función de los títulos de los artículos podríamos decir que en 2009 el rol del CIO era hacer que las

Todos sabemos que las decisiones se toman con la mejor información disponible a ese momento. Con el diario del lunes es fácil decir que alguien se equivocó. Muchas decisiones que parecen obvias a posteriori no lo son a priori. Esto, que es válido en general, es particularmente cierto para los temas relacionados con el software. He visto muchas situaciones donde una mala decisión tecnológica desencadenó retrasos, sobrecostos, etc. Pero el punto de esta entrada no es hablar de aquellos que decidieron sobre algo y luego la realidad mostró que se equivocaron. Aquí quiero hablar de los que acertaron. En los últimos días me tocó formar parte de algunas reuniones donde se discutía la necesidad de hacer cambios profundos en una determinada infraestructura tecnológica, con varios años de funcionamiento exitoso . Fue interesante ver que un común denominador en ellas era evaluar las decisiones tomadas hace tiempo en el contexto actual. Las frases eran algo así como "hicimos mal

Hace muchos años escribí mi tesis de licenciatura sobre Data Testing . En ella definí un modelo de testing para datos, haciendo un paralelo con el de testing de software. En el trabajo se repensaron varios de los conceptos básicos del testing de software, como por ejemplo el de testing funcional, el de testing de caja blanca y hasta los distintos niveles de prueba (de unidad, integración y de sistema). Días atrás, el director de aquella tesis me envió este articulo  en el que se habla del mismo tema, pero 18 años después. Por un lado, reconocí en él varias ideas de aquella época como la de usar consultas sobre los datos para probar condiciones estructurales sobre la información (los llamados supuestos en el artículo) o la de escribir dichas consultas de una forma particular, haciendo que el resultado arroje sólo las tuplas [1] con error. Por otro, encontré nuevas ideas como la de hacer testing continuo sobre ellos, corriendo las consultas todo el tiempo. En aquel ento