Hace algún tiempo leí por separado dos artículos que parecían tener poco en común: David beats Goliath y No to SQL.
En el primero, se hablaba de una serie de historias interesantes, donde el desconocimiento de las reglas implícitas en ciertas áreas permitía a ciertos individuos (es decir, novatos sin experiencia) desarrollar soluciones mejores que las de los expertos en el campo. De esta manera un entrenador con un equipo de baloncesto femenino clasificado como malo (en técnica y altura) conseguía aplastar a contrincantes más experimentados una y otra vez durante unos campeonatos tomando como principio básico un juego agresivo y de pura fuerza bruta (resistencia y tenacidad) pero sin ninguna técnica o habilidad adicionales, en vez de intentar ganar jugando con mejor técnica a rivales superiores. Algo parecido al caso del concurso de batallas navales simuladas que ganaba un ordenador con estrategias nada común como hundir sus propios barcos para ganar velocidad o dejarlos completamente desprotegidos para centrarse en la potencia de fuego. Es decir, este primer artículo hablaba de la ventaja que representa determinada ignorancia a la hora de resolver problemas tenidos por irresolubles.
El segundo artículo, habla de una iniciativa denominada NoSQL que aboga por no usar sistemas gestores de bases de datos (SGBD) relacionales. Como muchos sabréis un SGBD relacional, es una base de datos corriente y moliente (SQL Server, Oracle, MySQL…) que en la informática actual es algo considerado indispensable para tratar con volúmenes medios y grandes de información, es decir, están en todas partes. La gente de NoSQL decidió que quizá un SGBD relacional, no es algo tan indispensable al fin y al cabo, y se han dedicado a implementar de manera independiente sistemas masivos de almacenamiento de información no basados en bases de datos relacionales ni en el tradicional SQL. Con ello han conseguido (como pretendían) no solo tratar volúmenes de información muy difíciles para las bases de datos más potentes, sino hacerlo de una manera más barata. Todo un logro cuyo exponente más famoso sea probablemente Facebook con Cassandra una empresa bien conocida por tratar con una brutalidad de datos impensable hace tan solo unos años.
Y es releyendo por accidente el segundo artículo debido a tema relacionado en el trabajo cuando he recordado a Gerd Gigerenzer en Inteligencia Intuitiva y el caso de los comportamientos y respuestas automáticos inconscientes y el caso del fiasco de Accenture en la Bolsa de Londres por valor de 40 millones de libras y he pensado dos cosas:
La primera es que actualmente quizá el mayor error de un informático y que nunca nadie menciona es dar por hecho algo. La informática es algo MUY complejo y volátil por mucho que algunos se empeñen en no reciclarse y hacer las cosas "como siempre", y existen problemas inherentes como las abstracciones con fugas a nivel técnico o los wicked problems a nivel de proyecto, cuya única solución efectiva es “no jugar” que diría la computadora de Juegos de Guerra ("a strange game. The only winning move is not to play").
Mi segundo pensamiento ha sido que hay espacio para innovar en muchos campos. “Mucho espacio al fondo” citando a Feynman. Y para darse un paseo por ese espacio solo es necesario hacer algo que siempre nos recomiendan los teóricos y que a la vez suelen tratar de impedir muchos jefes de proyecto (como extensión del cliente) así como muchos clientes en su búsqueda de lo barato y rápido. Es necesario pensar mucho y bien (usando la razón y no la memoria para lanzar respuestas automáticas) antes de ponerse manos a la obra con casi cualquier cosa, hasta lo más básico.
Toda esta cháchara no tiene por objeto revolucionar, ni aleccionar, ni siquiera generar visitas o mantener vivo el blog sino simplemente recordarme un par de cosas que ya había comentado informalmente a nivel laboral, pero nunca por escrito:
- No des nada por sentado. Las respuestas de memoria pueden no ser fiables en un campo (o mundo) que avanza cada semana y que trata proyectos a medida. Esta regla la solía enunciar como una pregunta sin segundas intenciones en mi antiguo grupo de desarrollo: ¿lo crees o lo sabes?
- Dedica más tiempo a pensar, que a programar. Y piensa con cuidado. Son ya muchos años y desarrollos a las espaldas como para que piense que poner a la gente a aporrear el teclado a toda máquina va a servir para corregir una mala gestión del proyecto o un análisis deficiente. Si esos dos elementos (gestión y análisis) fallan, aporrear teclados solo sirve para empeorar el producto final.
No hay comentarios:
Publicar un comentario