El nivel 256 de Pacman (o cómo morir irradiado por una línea de código)

Sucede que, además de los videojuegos, los códigos controlan aviones, trenes, semáforos, redes de electricidad, cuentas bancarias, centrales nucleares, robots, telecomunicaciones, inversiones en bolsa… Así que los fallos de software pueden acabar costando mucho dinero (suponen un gasto del 0.6% del producto interior bruto en Estados Unidos) y, a veces, también vidas.

[#2 pip]

Bueno, los bugs suelen ser de una línea o muy pocas líneas de código.

Cuando es mucho código el que está mal, más que un bug es un error de diseño propio de un software que está mal hecho.

[#4 Aokromes]

#2 incluso un solo caracter puede ser un bug.

[#5 insulabarataria]

#4 ;

[#6 Aokromes]

#5 o > en lugar de < o = en lugar de => etc o != etc

[#24 mcfgdbbn3]

#6: O mejor = en lugar de ==, aunque ahora los compiladores ya lo suelen ir avisando para no acabar autopwneados.

[#10 Fernando_x]

Un fallo parecido ocurrió con un acelerador en un hospital de Zaragoza. Murieron varios pacientes que recuerde.
https://es.m.wikipedia.org/wiki/Siniestro_radiol%C3%B3gico_del_Hospital_Cl%C3%ADnico_de_Zaragoza

[#18 DDJ]

#10 "El aparato de radioterapia fue reparado sin seguir las instrucciones establecidas para ello"

Dramatización
- Échate pa-llá que eso te lo arreglo en un plis plas

[#19 Fayer]

#10 En la parte que habla de que los bugs afectan a nuestras vidas, podían haber hablado directamente del 737-800 MAX en vez de las chorradas que comenta

[#1 LeDYoM]

Esto sale en "Player one Ready".
En el libro. La película es "mainstream".
Pero lo otro no lo sabía.

[#7 Diphen]

#1 Sip, en "Ready player one" es una escena bastante bastante importante en el libro, en la peli uff...

[#12 sacaelwhisky]

#7 Está el libro Harry Player y el ready one de fuego. Sale Espinete haciendo de él mismo.

[#8 borre]

#1 Hay más vida aparte de ese libro de frikis (que me encantó)

[#11 hrundil]

La verdad es que hace tiempo que no me encuentro con bugs propiamente de código. No recuerdo ninguno en los últimos años. Hoy en día los propios IDEs y las pruebas unitarias ayudan mucho en ese sentido por suerte.
Lo que sí me encuentro mucho son errores causados por la interacción entre componentes que por separado no tienen ningún problema. Como dicen más arriba pueden ser problemas de diseño y que los componentes evolucionan por separado y en algún momento dejan de funcionar bien juntos.

Ejemplo de esta misma mañana: mi servicio A llama a un servicio B que a su vez llama a C. Nosotros en caso de error repetíamos la petición a B hasta 3 veces. Los desarrolladores de B vieron en sus métricas que a veces C fallaba así que decidieron poner 3 reintentos también. Eso ha causado que algunas peticiones se lleguen a repetir hasta 9 veces y han causado que C se sature y caiga. Causando una reacción en cadena.

[#14 azad]

#11 Los errores en interfases son los más difíciles de indentificar. Por eso que hay que empezar con todos los servicios ya existentes, que como que no están escritos hay que poner un stub. Aunque realmente no hagan nada, estás ya ejecutando la interfase.

[#15 Meneanauta]

#11 El concepto es el concepto

[#28 daphoene]

#11 "interfaz" es una palabra castellana preciosa.

Sin acritud ninguna

[#13 Desactivado]

La he votado duplicada por error, y no puedo deshacer el voto. En fin, una "feature" a implementar a futuros.

[#25 vaiano]

Yo venía buscando comentarios de cyberpunk y no encontré ni estaño !
Esto ya no es lo que era.

[#26 KimDeal]

Uno de mis errores informáticos favoritos es el que provocó el accidente informático de la Mars Climate Orbiter por una confusión entre kilómetros y millas:
https://elpais.com/diario/1999/10/02/sociedad/938815207_850215.html

[#3 balaurdrakon91]

Mucho clicbait en el titulo. Sensacionalista.

Pd: Es coña, meneo. La de vicios que me echaba en la versión flash cuando estaba en clase de matemáticas.

[#9 uno_ke_va]

#3 en realidad el artículo explica bastante bien el titular, y poco tiene que ver con el juego...

[#17 mudit0]

#3 En realidad se nota que no has leído el artículo y que sólo querías colar por aquí que sabes lo que es el Pacman.

[#16 j-light]

Seguramente alguien lo sabia. Quizas estaba escrito en algun procedimiento que nadie leyo.

[#29 daphoene]

#16 Es un error muy tonto como para simplemente dejarlo anotado en algún sitio, y más si de ello dependen vidas de personas.

Me tranquiliza muy poco que pasen errores tan tontos en las pruebas de maquinaria tan crítica. Entiendo que habla de los 80, pero el concepto es igual ahora mismo.

Un valor de "todo está correcto" no debería poderse establecer nunca con un contador. Siempre es más seguro establecerlo a "incorrecto" por defecto, y pasarlo a "correcto" si todos los tests se han pasado.

[#30 j-light]

#29 si coincido. Hay maquinas que tienen su proceso de uso y sw sigue al pie de la letra, todo sale bien. Pero es mucho confiar. Siempre es mejor pensar que nadie leera bien el manual. Pero esas lecciones se aprenden asi.

[#31 daphoene]

#30 Me parece terrorífico en casos como este.

Edito: En este caso no tiene nada que ver con el manual, ya que siempre que se irradiaba con alta frecuencia la plaquita tenía que estar delante del proyector, el caso de alta frecuencia y "sin protector" nunca debería haberse dado.

[#20 MoñecoTeDrapo]

Actualmente podéis encontrar en las stores el pacman256 que homenajea esto: los "bugs" nos persiguen desde un lado de la pantalla, convirtiendo el juego de facto en uno de carrera infinita, tan de moda en los últimos años.

[#27 Punisher92]

Que gran juego, muy divertido...

[#21 xnash]

poco Product Owner veo que no defiendan esto como una nueva Feature a vender...

[#22 LeDYoM]

#21 Creo que confundes Product Owner con Product Manager.

[#23 xnash]

#22 posiblemente y al igual que ellos confunden Producto con lo que creen que el cliente quiere