Cuando comenzamos en la programación, es normal que nos frustremos cuando algo no funciona o cuando tenemos un error. Y en nuestra experiencia, tendemos a creer que nos seniors y los programadores que admiramos no cometen errores. No puedes estar más equivocado.
Los errores son parte de la programación, por eso parte del desarrollo de software es el testing, el control de calidad, el flujo de devops y el control de versiones. Todas estas practicas buscan reducir los errores porque no importa que tan experimentado seas, los errores siguen ahí. Sin embargo, que sean parte, no significa que estén bien porque los errores son costosos.
Un solo error en el código puede costar millones, o incluso vidas humanas, porque el software controla el mundo y cualquier error puede generar un efecto dominó. En este blog conocerás los peores errores de la historia de toda la programación, para que comprendas por qué es importante detectarlos a tiempo.
1. Bill Gates y la pantalla azul
¿Alguna vez has tenido un momento embarazoso en público y querías que te tragara la tierra? Eso ni siquiera se compara a lo que le pasó a Bill Gates en abril de 1998, en la COMDEX de Chicago.
En ese evento estaba presentando el nuevo sistema operativo Windows 98, que como novedad, tenía soporte para USB y Plug and Play. Es decir: conectar un dispositivo al puerto USB y ya funciona. Así que Chris Capossela, que acompañaba a Bill Gates en la presentación, conectó un escáner a la computadora para la presentación y pum: pantalla Azul frente a cientos de personas.
No quiero imaginar como se habrá sentido Chris en ese momento, debió estar cagado en los pantalones. Sin embargo, Bill Gates, como el gran líder de negocio que es, se mantuvo imperturbable, sonrió y calmó a la audiencia con una broma: Esa debe ser la razón por la que todavía no vendemos Windows 98, porque todavía se iba a empezar a vender unos meses después.
Y por si te lo preguntas, nadie fue despedido en Microsoft. O bueno, al menos sabemos que Chris Capossela no lo fue y hasta el día de hoy sigue trabajando en Microsoft como Director de Marketing.
2. El desastre de Apple Maps
¿Crees que lo de Bill Gates fue vergonzoso? No es nada comparado con lo que pasó con Apple en 2012. Y es que hay muchas personas que creen que los productos de Apple están libres de errores, pero al contrario, su lista de bugs es enorme. Sin embargo, el más vergonzoso ocurrió con el iPhone 5, en 2012, cuando se lanzó Apple Maps.
Hasta entonces, el iPhone usaba los mapas de Google pero Apple quería independizarse y crearon sus propios mapas con mucha prisa, comprando datos de empresas como Yelp o Waze. El resultado fue desastroso: sitios deformados en la vista 3D, puentes que parecían derretidos, ubicaciones erróneas (como poner a Londres en Estados Unidos o a Hong Kong dentro de China) e incluso, indicaciones peligrosas para llegar a tu destino (como conducir por la pista de aterrizaje de un aeropuerto).
Bill Gates la llevó fácil, no pasó más allá de una vergüenza. En esta historia, el New York Time aseguró que era el peor producto en la historia de Apple, rodó la cabeza del director del producto e, incluso, Tim Cook tuvo que pedir disculpas públicas por el desastre.
3. El hombre más rico del mundo por dos minutos
¿Quién no ha soñado qué, por un error del banco, haya más dinero en tu cuenta? ¿o qué tus deudas se queden en cero? Acéptalo, tú también lo has pensado. Eso le pasó a Chris Reynolds en 2013, cuando se convirtió en el hombre más rico del mundo por unos minutos.
Reynolds abrió su cuenta de Paypal y se quedó sorprendido al ver que su saldo era 92,233,720,368,547,800 (o 92 billones de dólares). Más o menos 460 mil veces más dinero del que posee Elon Musk.
Sin embargo, Paypal rápidamente se comunicó con él y le explicó que se trataba de un error y le ofreció una cantidad secreta de dinero por las molestias. Cuando le preguntaron que pensó hacer con tanto dinero, bromeó con que habría pagado la deuda externa.
Afortunadamente, Chris Reynolds entendió que fue un error y se lo tomó con humor, en lugar de exigir sus 92 mil billones o como esos tipos que ven un televisor a 1 dólar, que obviamente es un typo, y hacen un escándalo para comprarlo por un dólar.
Paypal no ha hablado públicamente de cuál fue el bug que originó este problema.
4. La nave que se estrelló en Marte
En diciembre de 1998, la NASA lanzó la nave Mars Climate Orbiter, que debía llegar a Marte para estudiar la atmósfera y la superficie del planeta rojo por un año marciano (el equivalente a dos años en la tierra). El viaje desde la tierra hasta su destino, duraría entre 10 a 11 meses.
Pero, ¿Cómo se envía una nave a Marte? Se usan propulsores que van empujando la nave en una dirección determinada y señales de radio que permiten saber la ubicación, de esa manera, se puede saber con qué fuerza y en qué dirección empujar esos propulsores. Y eso se hace, ¡adivinaste! con un lenguaje de programación.
El Mars Climate Orbiter siguió su ruta hacia el planeta rojo hasta el 23 de septiembre de 1999, 10 meses después de su lanzamiento, cuando la NASA perdió contacto con la nave y no supo más de ella. Se presume que se estrelló contra marte.
Luego de la vergüenza de haber perdido 125 millones de dólares, la NASA inició una investigación y las conclusiones fueron de lo más vergonzosas: la construcción de la nave fue delegada a un contratista externo y privado llamado Lockheed Martin Astronautics mientras que la NASA se encargaba de programar los sistemas de navegación. Por lo tanto, la nave fue construida por dos equipos que no se comunicaron correctamente.
Estados Unidos es uno de los pocos países en el mundo que todavía utilizan el sistema británico de medición (pulgadas, pies, millas, libras) mientras que el resto del mundo, y la Nasa, utilizan el sistema internacional (centímetros, metros, kilómetros, kilogramos). ¿Entonces qué pasó? La NASA usaba el sistema internacional mientras que la empresa contratista usaba el sistema británico. Sin embargo, nadie escribió un programa para hacer la conversión. De hecho, nadie sabía que las dos partes usaban unidades distintas y simplemente asumieron que todo estaba bien.
Así que, con la nave ya en el espacio, el sistema de navegación sabía con cuánta fuerza y en qué dirección empujar los propulsores con los datos que la nave le enviaba. Pero mientras la nave enviaba mil millas, el sistema de navegación asumía que era mil kilómetros porque no había un sistema de conversión. Entonces, cada vez los propulsores empujaban en una dirección diferente a la nave, de tal forma que perdió su rumbo, y terminó estrellándose en Marte.
Moraleja: no asumas, pregunta, comunícate con tu equipo. Y si algo te parece raro, pregunta. El aislamiento de los equipos puede hacer perder cientos de millones de dólares, como en este caso.
5. El guion que costó 150 millones de dólares
Era 1962 y la NASA iba a enviar la primera nave no tripulada a dar la vuelta a la órbita de otro planeta: Venus. La nave despegó desde Cabo Cañaveral, pero a solo 5 minutos después, el centro de control emitió la orden de autodestrucción y la nave explotó en el aire. ¿Por qué? Alguien metió la pata en el código.
Para entender esto, tenemos que retroceder 60 años en el tiempo y entender que la programación de aquellas épocas no era ni remotamente como la actual. Apenas había un puñado de lenguajes de programación porque la programación era completamente nueva y las instrucciones se traducían a tarjetas perforadas manualmente que se introducían en paquetes a las computadoras para ser procesadas. Si había un error, tenías que volver a escribir todas las tarjetas porque no había sistemas de detección de errores ni interfaces gráficas para programar con coloreado de sintaxis, autocompletado y las otras cosas maravillosas que tenemos hoy en día. En aquellas épocas, ser un buen programador no se trataba de lógica, sino de paciencia.
El código de programación para el Mariner 1 (así se llamaba la nave), fue escrito con el lenguaje Fortran y luego traducido a tarjetas perforadas. ¿Y entonces que sucedió? En el código se había omitido un guion. El guion más caro de la historia de la programación, porque costó 150 millones de dólares.
Luego que despegó, el Mariner 1 empezó a tener un comportamiento errático porque sus alegorismos estaban entrando en conflicto. Por lo tanto, en el centro de control, tuvieron temor de que cayera en un lugar habitado y matara personas, por lo que tuvieron que destruirla en el aire.
Así que la próxima vez que estés programando y te salte un error, en vez de frustrarte, agradece que tienes herramientas que te lo dicen, que no existían antes. Y que también tienes plataformas como EDteam donde puedes aprender las mejores prácticas de programación. Entra en ed.team/cursos y comienza tu carrera en la programación completamente gratis, o actualiza tus conocimientos con todos nuestros cursos, talleres y carreras.
6. ¿Cómo perder 450 millones de dólares por una mala salida a producción?
¿Te imaginas perder 450 millones de dólares en 45 minutos por malas prácticas en el desarrollo de software? Es aterrador, no solo por el dinero perdido, sino por todos los errores que se cometieron no solo en el código, sino en la gestión del proyecto.
Para entender esto, primero debemos comprender cómo funciona la bolsa de valores. Usa un principio muy básico: confianza. Si las personas compran una determinada acción, significa que confían en esa acción, por lo que puede subir el precio, mientras que, si muchas personas comienzan a vender un mismo tipo de acción, significa desconfianza porque quieren deshacerse de esas acciones, por lo que el precio comienza a bajar.
Ahora, en la bolsa de valores, la idea es comprar una acción a un precio, y venderla luego por un precio mayor y te quedas con la diferencia. Hacer todo eso manualmente es super tardado, allí entra el software y las computadoras. El software es capaz de ir analizando rápidamente decenas o cientos de miles de acciones para ver sus precios y como están variando. un software bien programado, es capaz de ver dónde una acción pierde valor para comprarla y esperar el momento especifico para venderla cuando sube de valor. Y en todas esas interacciones, se hacen de manera automática.
Knight Capital, una de las principales firmas de inversión de Wall Street, tenía un software llamado SMARS, que se encargaba de comparar precios en fracciones de segundo y ejecutar órdenes de compras. Esto la llevó a la cima. Sin embargo, el primero de agosto de 2012, el software de Knight Capital hizo millones de transacciones no autorizadas en 45 minutos de forma automática y luego intentó venderlas cuando ya no podía venderlas. Con lo cuál, al empresa se quedó con una gran cantidad de acciones que no quería y que no podía venderlas porque las vendería a un precio más bajo, perdiendo una cantidad enorme de dinero, pero si no las vendía, tenía que hacerse cargo de esos costos. Al final, perdieron 450 millones en una mañana y la empresa estuvo a punto de declararse en bancarrota.
¿Qué pasó? Dentro de la empresa, también existía un componente llamado Power Peg que compraba caro y vendía barato. Es decir, lo contrario a lo que se hace en bolsa, pero que se usaba para probar que su algoritmo principal funcionara correctamente. Power Peg jamás debería usarse en producción. Además, en el 2012, llevaba 9 años sin usarse, era código muerto, pero no se había eliminado del sistema.
Creo que ya habrás adivinado por dónde va la cosa. Llegó a producción algo que no tenía que llegar a producción. El 1 de agosto, la firma lanzó a producción una actualización de software que no se ejecutó correctamente y en uno de los servidores siguió ejecutándose Power Peg en producción. Cuando se dieron cuenta del problema, ya era demasiado tarde.
¿Cuánto tardaría tu equipo de desarrollo en reaccionar ante un problema de esa magnitud? ¿Menos de 45 minutos? No es exagerado decir que estos errores cuestan millones. Además, Knight Capital no tenía sistemas de gestión ni de revisión del código ni de salidas a producción que habrían evitado este problema. Para evitar que te suceda algo así, puedes aprender en EDteam: testing, cloud computing (AWS y GPC) y de Devops. ¡Comienza todos estos cursos completamente gratis!
7. Unos bytes de memoria ¡casi acaban con todo el mundo!
Si creías que un error de casi 500 millones de dólares es lo más extremo, ¿Qué tal un error que podía acabar con todo el mundo? No exagero.
Debes tener al menos 30 años para vivirlo y recordarlo. En el el año 2000, la gente decía que el mundo se iba a acabar. Decían que cuando los relojes dieran el 00:00 del 1 de enero del 2000, los aeropuertos dejarían de funcionar, los bancos perderían todo su dinero, las centrales de energía eléctrica se apagarían, los sistemas de salud estarían apagados, los teléfonos y medios de comunicación no responderían. Era una visión aterradora y que no tenía nada que ver con creencias religiosas o supersticiones, sino con un error de programación.
La memoria en la computación siempre ha sido uno de los recursos más importantes, como te contamos en el video de Youtube: ¿Cuánta RAM necesitas para programar? Todo lo que necesitas saber. Sin embargo, en los primeros años, era un recurso escaso, por lo que se decidió guardar los años en dos cifras para ahorrar memoria. Entonces, en vez de 1960, guardabas 60, en lugar de 1999, guardabas 99. Pero, ¿Cómo guardarías 2000? ¿Cómo 00? No, porque 00 significaba 1900. ¿Te acuerdas el error del Mars Climate Orbiter? Ahora imagina ese error llevado a todas las computadoras del mundo.
Llegamos al extremo, que se vendían computadoras que tenían un sticker que decía “no te olvides de apagarlo antes de la media noche del 31 de diciembre”, como si fuera una advertencia de terror. Pero cuando llegaba el año nuevo del 2000, muchas personas estaban aterrada, al menos los que entendían del problema. Pero llegó el año 2000 y no pasó absolutamente nada. El mundo siguió su curso sin que pasara nada.
¿Qué pasó? ¿Fuimos engañados? ¿Caímos en el cuento del Y2K para comprar aparatos con el sticker de “preparados para el año 2000”?
En realidad no, si no hubo una catástrofe fue porque los gobiernos y las empresas gastaron toneladas de dinero en corregir el error en las computadoras y en el software. Tan solo el gobierno de los Estados Unidos calculó el gasto en 100 mil millones de dólares y se estima que el gasto mundial fue de unos 300 mil millones de dólares. Y todo por ahorrarnos unos bytes de memoria.
Los programadores tenemos el poder para construir cosas que ayuden a la humanidad con nuestros conocimientos o crear perdidas gigantescas de dinero, reputación e incluso, vidas humanas, con nuestros errores. Como decía el Tío Ben: “Un gran poder conlleva una gran responsabilidad”.
Valórala y siéntete orgulloso y de ese poder que tienes. Sin embargo, ten en cuenta que vivimos en una época en la que tenemos muchas herramientas para detectar errores, tenemos el trabajo remoto, tenemos sistemas distribuidos, testing, sistemas de control de versiones, pruebas automatizadas, etc. Todas las cosas que los programadores que estaban antes que nosotros quisieran haber tenido. Y además, una ventaja que tienes, es EDteam, que te permite estudiar en cualquier lugar del mundo, desde cualquier dispositivo y a cualquier hora. Porque en español, nadie explica mejor que EDteam.
Y para que puedas aprender y convertirte en el profesional que deseas ser, muy pronto llegará a EDteam los descuentos más grandes del año. ¡Black Friday 2022 está muy cerca, espéralos!