Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta humor. Mostrar todas las entradas
Mostrando entradas con la etiqueta humor. Mostrar todas las entradas
miércoles, 29 de marzo de 2017
Desarrollador volviéndose loco
Imagen original de Pixabay.
La llegada del próximo April Fool's day, algo parecido a lo que por aquí conocemos como el día de los Inocentes, me ha recordado una curiosidad con la que me topé hace algún tiempo que, si tenéis un poco de maldad reprimida, podéis utilizar para gastar una broma a algún compañero desarrollador y echar unas risas.

La historia consiste en abusar del amplio conjunto de caracteres soportado por UTF, sustituyendo el punto y coma de finalización de una línea de código (";") por el símbolo de interrogación griego (";", Unicode 037E), indistinguibles a simple vista, como en la siguiente línea:
public void HelloWorld()
{
    Console.WriteLine("Hello world!");
}
martes, 14 de abril de 2015
PensandoSin duda, posts pertenecientes a la serie recopilatoria de citas célebres relacionadas con el mundo de la informática (primero, segundo, tercero y cuarto) siguen siendo, año tras año, los contenidos más populares de este blog, probablemente por la mezcla de conocimiento, humor, ingenio y realidad sobre nuestro día a día que incluyen estos mensajes.

Tras su última entrega, allá por septiembre de 2012, he continuado recopilando todas las citas que han caído en mis manos y me han resultado curiosas, hasta llegar por fin a las 101 que os traigo hoy. Espero que os iluminen de nuevo o, al menos, que os hagan pasar un rato tan bueno como los que paso yo mientras las voy seleccionando :)
martes, 25 de septiembre de 2012
PensadorMás de tres años hace ya desde la publicación en Variable not found de la última entrega de esta serie que tanto me divierte (entrega primera, segunda y tercera), y por fin he podido dedicar un poco de tiempo para organizar y seleccionar las citas que he ido anotando desde entonces.

Y aquí está el resultado, 101 nuevas frases célebres relacionadas con nuestro mundillo, que espero que os gusten tanto como las anteriores.

Este es el cuatro post de la serie compuesta por:
¡Que aproveche!
miércoles, 18 de abril de 2012
De vez en cuando surgen en Stackoverflow geniales hilos como este, que te alegran el día en que los descubres. En este caso miles de usuarios proponían, votaban y debatían sobre cuál es la viñeta o tira cómica favorita de los programadores y otros especímenes de nuestra fauna digital.  

Y las veinte más votadas, auténticas joyas algunas de ellas, fueron las siguientes...
miércoles, 8 de febrero de 2012
Errores y usuariosSeguro que todos sabéis lo que es tratar con los usuarios de vuestro software: son lentos, patosos, inconscientes, atrevidos, inseguros, ignorantes, y no consiguen entender la belleza de la herramienta que con tanto esmero hemos creado. Y lo que más rabia da es que muchas veces tienen razón en los problemas que reportan de nuestras aplicaciones.

Pero afortunadamente otras veces no es así, y los problemas no son nuestros sino suyos, momento en el que pone a disposición de la dulce venganza la genial creatividad característica de nuestro gremio.

Lo que vamos a ver a continuación son siete de las formas existentes, conocidas y documentadas de cargar las culpas sobre el usuario, o simplemente llamarlo torpe, sin que éste se dé cuenta. Algo muy socorrido si, por ejemplo, debemos contarle a un compañero lo que ocurre en presencia del implicado.

Por supuesto, a partir de aquí todo es secreto, no dejéis que caiga en manos de algún desalmado ;-)

martes, 25 de octubre de 2011
The Tao of ProgrammingHace unos días charlaba con un colega sobre aspectos filosóficos del desarrollo de software, y me pareció curioso que no conociera “The Tao of Programming”, todo un clásico de la literatura friki, y lectura indispensable para los que nos dedicamos a esto.

Este libro, escrito en el año 1987 por Geoffrey James, recoge, en un humorístico tono de misticismo oriental, distintas historias y parábolas con geniales mensajes de fondo sobre calidad en la programación, gestión de proyectos y otros temas que siguen siendo válidos veinticinco años después.

Como probablemente habrá más lectores que no lo conozcan, me ha parecido interesante reproducirlo aquí traducido en su totalidad, por supuesto contando previamente con el permiso expreso del Sr. James.

¡Que aproveche!
Warning: Post largo. Muy largo ;-)
martes, 30 de noviembre de 2010
Stackoverflow es, sin duda, una fuente infinita de temas curiosos sobre los que hablar y escribir. Hace tiempo tenía ganas de comentar un hilo que me pareció muy divertido unos meses atrás.

La pregunta “What real life bad habits has programming given you?”, que podríamos traducir más o menos como “¿Qué malos hábitos de la vida real te ha dado la programación?”, inició un hilarante brainstorming sobre nuestra particular visión del mundo real, brindándonos la oportunidad de comprobar que no somos tan únicos ni raros como suele parecer.

A continuación resumo las respuestas y comentarios que más me han llamado la atención en este hilo, probablemente por padecerlos en primera persona. Y ya puestos, como de costumbre, he aprovechado para añadir otros de cosecha propia:
  1. Considerar 256 o 1.024 números bonitos, tanto como podrían ser 1.000 o 10 para alguien no afectado por el desarrollo.
  2. Echar en falta un Ctrl-F cuando estamos ante un libro o documento escrito para buscar términos.
  3. Intentar poner en pausa un programa de televisión convencional, o retroceder en una secuencia de la que no nos hemos enterado bien.
  4. Interpretar de forma extremadamente literal las expresiones. Responder “Sí” a “¿tienes hora?” es un ejemplo clásico.
  5. Utilizar la aritmética booleana donde no se debe, por ejemplo, respondiendo “Sí” a “¿Quieres té o café?”.
  6. Echar en falta el Ctrl-S para salvar un trabajo, por ejemplo un castillo de arena, y conservarlo justo en el estado en que se encuentra para volver a retomarlo más adelante.
  7. Mostrar alergia a textos con problemas de puntuación, paréntesis desbalanceados y otro tipo de fallos ortográficos, así como un sexto sentido para detectarlos.
  8. Googlearlo todo, en cualquier momento y circunstancia.
  9. Buscar opciones por defecto que nos facilite la toma de decisiones. Incluso a la hora de elegir el almuerzo en un restaurante. 
  10. Numerar elementos comenzando por cero, y obviamente, acabar con un número menos que el resto de mortales. Comenzando por el pulgar: dedo 0, dedo 1… dedo 9.
  11. Sentir los errores de conversión de tipo como si fuéramos compiladores. Si preguntas a alguien “¿quieres salir a pasear?” esperas un booleano, no algo como “me duele la cabeza”.
  12. imageDivertirse con frases y chistes geeks, como “Dios es real, a menos que se declare como entero” :-D
  13. Sentir una extraña y maquiavélica alegría al detectar bugs en cualquier tipo de sistemas, como programas de televisión o dispositivos electrónicos.
  14. Intentar optimizar y hacer más eficiente cada paso que damos. Seguro que todos hemos vivido situaciones como “me tengo que levantar para ir al aseo, así que aprovecho para llevar algunos chismes a la cocina, de camino pongo las palomitas en el microondas, de forma que cuando vuelva ya estarán listas, busco una cerveza en el frigorífico y continúo viendo la película”.
  15. Ser incapaces de comprender el lado contrario, es decir, cómo alguien no optimiza sus acciones, desaprovechando esfuerzos de forma injustificable ;-)
  16. Intentar planificar minuciosamente otros aspectos de la vida: viajes, excursiones, ir de compras, etc.
  17. Utilizar en conversaciones con gente normal palabras como “lógica”, “optimizar”, “recurso”, o “multitarea”.
  18. Llamar a los no programadores “gente normal” ;-D
  19. Buscar patrones repetitivos de comportamiento en todo como si tuviésemos que implementarlo.
  20. Anidar paréntesis (en textos escritos (incluso a mano)). Pero, eso sí, siempre correctamente balanceados.
  21. Analizar y criticar lo que se nos pregunta en un formulario, aunque sea en papel impreso. Por ejemplo, “¿para qué quieren saber la edad si están preguntando también la fecha de nacimiento?”
  22. Incluir una barra inclinada en el interior del dígito cero (algo como “Ø”) cuando escribes números a mano.
  23. Bucles para la vida real, ¡YA!En las webs de compra de entradas online, pensar al tener que elegir sitio en un cine con sesión numerada, que la sala podría ser defragmentada. :-D
  24. No recordar el significado original de palabras como “herencia”, “hilo”, o “excepción”.
  25. Echar en falta los bucles en la vida real.
  26. Ponerse realmente nervioso cuando tenemos delante a alguien no experto manejando un ordenador y esperamos a que realice una tarea.
  27. Finalizar frases con punto y coma;
  28. Echar en falta el Ctrl-Z para deshacer alguna barbaridad. Por ejemplo, si dedicas tiempo a la pintura o dibujo, seguro que más de una vez lo has necesitado. Y también si eres algo bocazas ;-)
  29. Echar también en falta la versión Linux de Ctrl-Z para pausar un proceso en curso.
  30. Solucionar un problema mientras sueñas, o en mitad de una conversación ajena al mismo.
  31. Excusarnos en este último caso diciendo que “estábamos en multitarea” cuando no es cierto: simplemente no prestábamos mucha atención a la conversación ;-D
  32. Hacer que el número de elementos en una lista sea siempre potencia de 2 ;-)
A la vista de esto, ¿crees que estás afectado por el desarrollo? ;-D

Publicado en: Variable not found
lunes, 17 de mayo de 2010
Desarrolladores tatuados ¡Ah, cómo nos parecemos los desarrolladores! Independientemente de la tecnología, el tipo de aplicación, o el cliente, parece que llevamos tatuados de serie unos comportamientos que repetimos una y otra vez ante escenarios similares.

Debe ser por eso que me divierten y me identifico tanto con los posts que enumeran estos hábitos tan comunes, como el clásico las “20 respuestas más utilizadas por los desarrolladores cuando sus programas no funcionan”, que pulula por la red desde hace muchos años y del que he encontrado versiones en todos los idiomas, por lo que soy absolutamente incapaz de citar la fuente exacta.

El hecho es que justo en el momento en que se nos informa de que algo ha fallado en una de nuestras aplicaciones, el cerebro comienza a trabajar aceleradamente en busca de una excusa explicación, por lo que he pensado que combinando esta lista de frases con unos sabios consejos, seguro que puedo ayudar a más de uno a evitar las tensiones derivadas de los errores en programación.

Y es que, al final, seguro que todos acabamos diciendo aproximadamente lo mismo…

20. “¡Qué raro!”. Primera regla del desarrollador experimentado: mostrar asombro cuando algo falla. Alguien que no se extrañe de la aparición de un error puede aparentar ser bastante mediocre. Hay quien incluso, para acentuar más aún su profesionalidad, añade “¡Imposible!”.

19. “Nunca había pasado antes”. Por si no queda claro con el conjunto de exclamaciones anteriores, apostillar con esta declaración deja claro que os encontráis ante algo insólito. Esto, además, puede ser útil para despertar el espíritu aventurero en tu interlocutor, y hacerlo partícipe en el enfrentamiento a lo desconocido que estáis a punto de comenzar.

18. “Ayer funcionaba”. Busca un soporte sólido para aferrarte, una referencia fiable como esa. Decir que ayer funcionaba es una afirmación ideal: difícil de probar, y si estás ante alguien cándido e inocente, será suficiente para convencerlo de que el error se ha generado hoy mismo, como por arte de magia.

17. “¿Cómo es posible?”. Otra oportunidad para demostrar tu asombro, que además surte mayor efecto si lo sigues con una explicación que tu interlocutor no sea capaz de entender: “cuando I,J,K y no M,N,L es imposible que X,Y,Z”.

16. “Debe ser un problema hardware”. Segunda regla del desarrollador experimentado: si la cosa se complica, puedes ir abriendo el camino a nuevas posibilidades, alejadas de nuestra responsabilidad. Nada podemos hacer contra fallos en la máquina, nosotros sólo entendemos de software. De hecho, si somos incapaces de dar con el problema (y por tanto incapaces de solucionarlo), echar las culpas al metal es una vía de salida de lo más airosa.

¡Te vas a tragar la pantalla! 15. “¿Qué hiciste mal para que fallara?”. Duda siempre de la lucidez del usuario. Si lo acusas de ser un zoquete tendrá que dedicar su tiempo de proceso a defender su postura, y no a vapulearte como te mereces.

14. “Hay algo raro en tus datos”. Es una variación más ligera del caso anterior; estás descargando responsabilidad sobre el usuario, aunque de forma menos agresiva, pues no es un ataque directo a su persona, sino a los datos que utiliza. Esta fórmula puede ser útil y prudente si, por ejemplo, el usuario del sistema es tu jefe.

13. “¡No he tocado ese módulo en semanas!”. Eso es, deja claro que tú no has tocado nada, y que por tanto la responsabilidad no es tuya. Si el módulo funcionaba hace un mes y no has tocado nada, está claro que la culpa el del usuario, del entorno, o del propio desgaste, como las ruedas de un coche.

12. “Debes estar utilizando una versión incorrecta”. Esta es una técnica avanzada para aplicar una vez te has percatado, en silencio claro está, de que había un error tuyo en tu aplicación. Acusa al usuario de utilizar una versión antigua del software, y suminístrale la versión correcta, en la que obviamente ya has parcheado el error.

11. “Se trata sólo de una casualidad”. Utiliza el azar como causa de los problemas; es impredecible, incontrolable y misterioso, una cortina de humo ideal para esconder nuestras meteduras de pata.

10. “Uno no puede probarlo todo”. No somos Dioses… quizás estemos muy cerca, pero no lo somos. Esta frase, a utilizar sólo en casos señalados, puede mostrar humildad y apelar a la bondad del interlocutor para disminuir la tensión. O también, puede servir para arremeter contra tu organización, la falta de recursos, de tiempo, etc., que el usuario empatizará y lamentará contigo.

9. “Eso no puede ser la causa del problema”. Sé tajante; aunque tenga razón, no permitas que un usuario listillo te revele el motivo exacto por el que ha fallado tu aplicación, pues nadie la conoce mejor que tú. Si después de usar esta frase confirmas que la causa era la apuntada por este individuo, no lo reconozcas, y utiliza verborrea técnica para desviar la atención a otras causas.

8. “Eso funciona, aunque no lo he probado”. Un desarrollador profesional no necesita probar las cosas para saber que funcionan, eso es cosa de débiles e inseguros. Una afirmación tan rotunda desequilibrará al interlocutor y lo hará dudar de su criterio a la hora de detectar el error, momento que puedes aprovechar para rematar con cualquier otra frase.

7. “Alguien debe haber cambiado mi código”. Otra regla de oro del desarrollador, aunque compartida con otras profesiones: échale las culpas a otro. Una vez demostrado que hay un fallo y que no puedes hacer responsable al usuario, no hay nada mejor que echar la culpa a los compañeros. Y si crees que no es ético, recuerda: ellos también lo harían.

6. “¿Has comprobado si tienes un virus?”. Los virus, esos seres misteriosos que sólo podemos comprender los iniciados y de los que todo el mundo ha oído historias terribles, son también firmes candidatos a salvarnos el trasero cuando la cosa se está poniendo peligrosa. Dado que la respuesta a esta pregunta casi siempre va a ser negativa, estamos ganando tiempo e introduciendo un factor externo sobre el que descargar las culpas, haciendo al usuario responsable por su incompetencia para mantener su equipo limpio.

BSOD 5. “Bueno, no funciona, pero mola, ¿eh?”. Ante una encerrona, apela al sentido del humor de tu interlocutor. Intenta detectar algún aspecto positivo del desastre, y preséntalo de forma atractiva para el usuario. ¿Un proceso tarda demasiado? Así tienes más tiempo para estirar los músculos; ¿La aplicación se cierra violentamente? Así puedes apagar antes el equipo e irte a casa; ¿Una BSOD? Fíjate qué fondo de pantalla azul eléctrico tan espectacular te pone el programa cuando falla.

4. “No puedes usar esa versión en tu sistema” Cuando el número de errores sea tan alto que pueda poner en peligro tu credibilidad como profesional, no reconozcas haberlos cometido; utiliza motivos estructurales como el hardware, los virus, o el versionado de sistemas para hacerles ver que eres totalmente inocente.

3. “¿Por qué quieres hacerlo así?” Una posibilidad muy socorrida es a veces instruir al usuario para que realice las tareas justo de la forma en que la aplicación funciona correctamente, censurándole rápida y tajantemente los intentos de salirse del camino marcado. A veces es más fácil adaptar el usuario a la aplicación que viceversa.

2. “¿Dónde estabas cuando el programa falló?” Ideal para aplicaciones que funcionan como procesos por lotes, o para intentar culpar al usuario de su ausencia en un momento vital como en el que se produjo el problema. Sobre todo si sabemos que el usuario es tendente a despistarse, esta puede ser un arma realmente interesante.

1. “No es un error, es que el programa funciona así”. Aprovecha la delgada línea que separa un bug de una feature. Esta técnica avanzada te permitirá desviar la atención hacia las personas que decidieron las funcionalidades, recogieron los requisitos, o validaron el software, pero nunca hacia el desarrollador que simplemente siguió las instrucciones.

¡En mi máquina funciona!Y por último, la frase más utilizada sin duda por los desarrolladores:

0. “¡En mi máquina funciona!” Desconcierta al interlocutor, y queda como debes, por encima de todos. El software funciona en entornos controlados como el tuyo, propios de un experto, donde todo está perfectamente en orden y lejos del alcance de las manazas del usuario final.

Eso sí, hay que estar preparados para una respuesta como la siguiente:
"¡No me importa si funciona en tu máquina!
¡No estamos vendiendo tu máquina!"
-- Vidiu Platon
Publicado en: Variable not found
lunes, 16 de noviembre de 2009

¡Programadiseñadores al poder! Ya sabemos lo que suele ocurrir cuando los programadores diseñamos interfaces de usuario ;-). Para seguir profundizando en este curioso e inevitable fenómeno, Ian Voyce ha publicado hace unas semanas el divertido post The 7 signs your UI was created by a programmer, en el que recoge pistas que nos ayudarán a determinar si el interfaz de la aplicación que usamos a diario está creado por un diseñador experto en usabilidad, o ha sido el propio desarrollador el encargado de dichas tareas.

Bueno, en realidad se trata más bien de una lista con malos hábitos en el diseño de interfaces, y no necesariamente creados por programadores, pero ciertamente me he reconocido en alguno de los puntos y me han hecho gracia. Los cito y comento a continuación:

  • Iconos de exclamación en cuadros de diálogo
    Efectivamente, cuando incluimos una exclamación en un cuadro de diálogo no pensamos en que es posible que el usuario vea el mensaje 50 veces al día, con lo que dejaría de ser ese mensaje asombroso y puntual que pensamos en un principio. Hoy en día, muchas aplicaciones utilizan un tono mucho más neutral y cercano para enviar mensajes al usuario.

  • Mensajes con dobles negaciones en cuadros de diálogo, del tipo “¿Seguro de que no quieres perder tus cambios?” -- Hmm… sí… digooo, no…  También son muy propias construcciones más complejas de la cuenta, paradójicas o inesperadas, como “Su mensaje no se ha enviado, ¿desea descartarlo?”, que ponen a prueba los reflejos de cualquier usuario.

  • Orden de tabulación inexistente, o incorrecto, que fuerzan a que la navegación se realice exclusivamente a golpe de ratón. Y especialmente en aplicaciones de entrada masiva de información, el cambio de teclado a ratón y viceversa es terrible. Y paraGroupboxes para todo.. porque mola hacernos conscientes de ello, nada como dar vacaciones un rato al animalito y ver lo bien que manejamos determinadas aplicaciones.

  • Groupboxes rodeándolo todo… porque hay sitios donde queda bonito, aunque no esté agrupando nada ;-). Me confieso: durante años, he rodeado de groupboxes todo lo que se me ponía por delante, porque me parecía más agradable a la vista. Ahora lo estoy dejando ;-)

  • IconoIconos creados en el IDE, je, este es otro de mis puntos fuertes: soy un fiera diseñando iconos desde el editor de Visual Studio. El problema es que, a pesar de lo orgulloso que estoy siempre de mis creaciones artísticas, no quedan bien e incluso introducen un cierto tufillo a cutre en las aplicaciones.

  • Utilización de grids, debido a lo que llama Voyce “la enfermedad de considerar que Excel es lo máximo en diseño de interfaces de usuario”, que fomenta la creación de rejillas con controles de lo más potentes y variopintos en las filas de datos (calendarios, gráficos, etc.).

  • Message Boxes no implementados, el equivalente en los interfaces de usuario a los TODO en el código fuente :-DD. Buena analogía. Algo parecidos serían los mensajes del tipo “Este mensaje no debería aparecer nunca” que alguna vez he encontrado por ahí, auténticos actos de rebeldía contra sus respectivos creadores.

  • Uso excesivo de cuadros de diálogo, incluso en situaciones en las que perfectamente podríamos obviarlos por no ofrecer información útil para el usuario, que no va a poder entender, o donde no se requieren decisiones por su parte.

    Los componentes necesarios han sido detectados. Accediendo...Esto es algo muy frecuente de ver. Por ejemplo, el otro día accediendo a una aplicación web para la que es necesario contar con certificado digital, me saltó la alerta que muestro a la derecha:

    Sí, probablemente los componentes Java necesarios para la autenticación y firma electrónica hayan sido detectados con éxito, pero… ¿realmente era necesario interrumpir mi navegación para informarme de ello? ¿Un usuario, sabrá interpretar el mensaje? Y en cualquier caso, ¿le aporta algo? No sé, no sé… me da que es un alert() creado por un desarrollador durante las pruebas y que al final se quedó ahí para la posteridad.

Hasta aquí las citadas en el post original, aunque siguiendo en la misma línea, puedo añadir algunas más de propia cosecha:

  • Cuadros de diálogo con mensajes y botones inconsistentes. Mensajes del tipo “¿desea cancelar la operación?” en cuyo pie aparece un botón “Aceptar” y otro “Cancelar” siempre me dejan pensando un rato. Si pulso aceptar, ¿estoy aceptando la cancelación, o justo lo contrario?… Muchas veces, parece que sólo podemos confiar en el azar.

  • Cuadros de mensaje con demasiados (o demasiados pocos) botones. No siempre atendemos a la Ley de Hick, que nos dice que “el tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas”, y eso nos lleva a crear cuadros de diálogo con muchos, demasiados, botones que el usuario debe estudiar.

    Y justo en el lado contrario, pero igualmente desconcertantes, son los cuadros de diálogo de introducción de datos sin ningún botón de aceptación, en los que su cierre (con la X de la esquina superior) implica el salvado de datos.

  • Interfaz descuidado. Y no hablo de bonito o feo, términos bastante subjetivos, sino de descuidado: controles sin alinear, con tamaños no proporcionales al contenido pretendido, sensación de desorden, faltas de ortografía… Esto no es un problema de interfaces creados por desarrolladores, sino creados por gente que no pone el más mínimo cariño en lo que hace, independientemente de su puesto de trabajo.

  • Interfaces monocromos, mi especialidad. Como inútil reconocido en temas de diseño, me considero absolutamente incapaz de crear algo medio aparente con más de un color (eso sí, empleando distintas tonalidades ;-)). Nunca he entendido la compleja lógica que hay detrás del “eso no pega con aquello”, que algunos/as parecen dominar de serie.

  • Controles con trastorno de personalidad. Un clásico es encontrar un grupo de checkboxes actuando como un grupo de radios. A ver, si sólo vamos a poder elegir una de las opciones, ¿por qué no usamos directamente el control específicamente ideado para ello? ¿Y un desplegable con las opciones "Activar" y "Desactivar"? ¿No sería más claro poner un checkbox?

Artículo original: The 7 signs your UI was created by a programmer

Publicado en: Variable not found.

domingo, 13 de septiembre de 2009

Juan Palacio, en su genial Navegápolis, publicó semanas atrás unos buenos materiales de un Curso de Scrum en los que he podido recordar una historieta que encontré hace tiempo sobre la diferencia entre la implicación y el compromiso en la realización de un proyecto:

La historia de la gallina y el cerdo

Aunque esta metáfora se utiliza en Scrum para agrupar los roles principales distinguiendo entre aquellos que ponen “la carne en el asador” (cerdos), y el resto de afectados y participantes (gallinas), es igualmente aplicable a las actitudes de los componentes de un equipo de trabajo, independientemente de la metodología utilizada.

Publicado en: Variable not found.

lunes, 13 de julio de 2009

… o algún arma química o biológica, que sepas que no puedes utilizar Google App Engine: estarías violando los términos de la licencia.

 image

“El uso del servicio debe cumplir con todas las leyes aplicables, reglamentos y ordenanzas, incluyendo cualesquiera leyes relativas a la exportación de datos o software. Usted acepta no usar el servicio en el diseño, desarrollo, producción, o uso de misiles o el diseño, desarrollo, producción, almacenamiento y uso de armas químicas o biológicas”

Así que, si es este tu caso, ya puedes ir buscando otro software. Y no lo vas a tener fácil, puesto que se trata de un párrafo que se incluye muy habitualmente en las licencias de aplicaciones.

Pues eso, mucho ojo. ;-D

Visto en: DevTopics: why-terrorists-hate-google-app-engine
Publicado en: Variable not found.

lunes, 18 de mayo de 2009
PensadorHa transcurrido un año desde que publiqué mi recopilación de citas célebres del mundo de la informática, como continuación de la serie iniciada originalmente por el amigo Timm Martin en DevTopics. Desde entonces he ido anotando todas las citas que me llamaban la atención, hasta que por fin he llegado al número mágico y puedo publicar el tercer post de la serie que tanto me divierte. Que aproveche.

Este es el tercer post de la serie compuesta por:
viernes, 1 de mayo de 2009

imageHuye como del diablo de aquél que utilice demasiadas veces las palabras:

  • Necesitamos
  • Debemos
  • No podemos
  • Sencillo
  • Simplemente
  • Sólo
  • Rápido

… y especialmente si las utiliza en el mismo párrafo.

(Del clásico Four Letter Words –need, must, can’t, easy, just, only, fast- publicado en Signals vs Noise).

Publicado en: www.variablenotfound.com

domingo, 8 de febrero de 2009
HundimientoMe he vuelto a encontrar con el divertido post 101 Ways To Know Your Software Project Is Doomed, donde se enumeran 101 pistas que te ayudarán a saber si tu proyecto está condenado a fracasar estrepitosamente. Tras contactar con Max Pool, el propietario del blog Codesqueeze, me ha permitido muy amablemente publicar aquí una traducción de su post completo.
  1. La dirección ha cambiado el nombre del "procedimiento en cascada" por "cascada ágil".
  2. Se han empezado a contratar consultores para poder echarles las culpas de todo.
  3. El servidor de integración continua retorna el error "Que te jodan. Me largo".
  4. Habéis implementado vuestro propio framework en Ruby que usa archivos de configuración XML.
  5. El miembro del equipo más mayor se refiere a Martin Fowler como "ese gamberro engreído".
  6. Vuestro sistema de control de código fuente consiste en una serie de carpetas en un disco compartido en red.
  7. El tiempo asignado para QA es destinado a preguntarse el por qué de ese desastre.
  8. Todos los requisitos están escritos en una servilleta de papel.
  9. Empiezas a considerar un cambio de empleo para no tener que mantener la aplicación que estás desarrollando.
  10. El responsable de desarrollo web piensa que la X de XHTML viene de "eXtremo".
  11. Las reuniones de todas las iteraciones comienzan por un "¿prefieres las buenas o las malas noticias?".
  12. El equipo todavía considera que su nivel de CMM es una mierda.
  13. El progreso se mide por el número de errores corregidos, y no por funcionalidades o características finalizadas.
  14. La integración continua está haciendo que los empleados nuevos lean el manual del empleado.
  15. Eres amigo del portero.
  16. Al SCRUM master no le importa lo que hicisteis ayer, ni lo que haréis hoy.
  17. Cada hito acaba en un sprint mortal.
  18. Vuestro mejor desarrollador lo único que tiene es su expediente académico brillante.
  19. No entendéis los acrónimos DRY, YAGNI o KISS, pero sí WTF, PHB o FUBAR.
  20. El jefe podría ser sustituido por un script de redirección de emails.
  21. La única certificación de vuestros procesos de construcción de software es la ISO 9001/2000.
  22. El jefe piensa que "métrica" es un tipo de bebida proteínica.
  23. Todos los errores son priorizados como críticos.
  24. Todas las funcionalidades son priorizadas como triviales.
  25. Las estimaciones económicas del proyecto mágicamente coinciden con el presupuesto disponible para el mismo.
  26. Los desarrolladores usan la excusa del código autodocumentado para justificar la ausencia de comentarios.
  27. Vuestro patrón favorito es el god object.
  28. Todavía pensáis que compilar es una forma de testear.
  29. Los desarrolladores todavía utilizan Notepad como entorno de desarrollo.
  30. El gestor del proyecto pasa 7 horas a la semana pidiendo informes de progreso (basado en hechos reales).
  31. No tenéis máquina propia, y no estáis programando por parejas.
  32. Norma del equipo: no hay reuniones hasta las 10:00am, puesto que ayer estuvimos aquí hasta las 2:00am.
  33. En el equipo se piensa que los ORM son una moda.
  34. El equipo piensa que la transición desde VB6 a VB.NET será sencilla.
  35. El gestor piensa que MS Project es la mejor herramienta de gestión de proyectos del mercado.
  36. Tu esposa sólo consigue verte en una webcam.
  37. Ninguno de test unitarios tienen aserciones (asserts).
  38. Vuestro editor de páginas favorito es FrontPage.
  39. Se discute encendidamente sobre si la llave "{" debe escribirse en una nueva línea, pero se es impacial ante el uso de patrones como MVC.
  40. El lema de la compañía es "haz más con menos".
  41. La frase "funciona en mi máquina" se escucha más de una vez al día.
  42. La última conferencia a la que asistió el equipo de desarrollo .NET fue la Apple Worldwide Developers Conference 2000.
  43. Los gestores insiten en registrar toda la actividad, pero nunca usan esa información para tomar decisiones.
  44. Toda la depuración se hace en el servidor en producción.
  45. El jefe no sabe cómo comprobar el email.
  46. El jefe piensa que ser compatible SOX significa no trabajar las noches en las que hay béisbol.
  47. La empresa contrata al senador Ted Stevens para la charla de inicio del proyecto.
  48. El último libro que leíste fue la Biblia de Visual Interdev 6.
  49. El presupuesto general se confunde con tu gasto semanal en Mountain Dew.
  50. El jefe se pasa la hora de la comida llorando en el coche (otro hecho real).
  51. El responsable de desarrollo web define Ajax como un producto de limpieza.
  52. Tu jefe espera que pases los dos próximos días creando una solicitud de compra por un componente de 50$.
  53. El equipo de ventas reduce tus estimaciones porque creen que podéis trabajar más rápidamente.
  54. Requisito - Rank #1 en Google.
  55. Todos los días trabajas hasta medianoche, y tu jefe se va a las 16:30.
  56. A los jefes les encanta decir: "¿por qué se preocupan los desarrolladores? Cobran por horas".
  57. El personal del turno de noche de StarBucks te conoce por tu nombre.
  58. El jefe no pueden entender por qué alguien puede necesitar más de un monitor.
  59. El equipo de desarrollo sólo usa el control de código fuente como sistema de backup por si falla el suministro eléctrico.
  60. Los desarrolladores no son responsables de realizar ninguna prueba.
  61. El equipo no usa SVN porque piensan que los algoritmos de fusión (merge) son pura magia negra.
  62. Tus pizarras no tienen nada escrito (Version One).
  63. El cliente confunde siempre tu gráfico burn-down con un burn-up (lo que queda por hacer con lo que está hecho).
  64. El nombre clave del proyecto pasa a ser "Marcha de la muerte".
  65. Te duele físicamente decir la palabra "sí".
  66. Tus compañeros no refactorizan, sino refuctorizan.
  67. Como recompensa por el tiempo extra, tu jefe compra una nueva cafetera.
  68. El presupuesto de tu proyecto se contabiliza en la empresa como gastos estructurales.
  69. Puedes bloguear desde el trabajo, gracias a que subcontratas porciones del proyecto.
  70. Se crea un comité de control de cambios del proyecto, incluso antes de disponer de la primera versión alfa.
  71. Diariamente consideras romperte los dedos para estar impedido un tiempo.
  72. El hito final de entrega ha sido renombrado simplemente como "hito", igual que el anterior.
  73. La política de puertas abiertas de la dirección sólo se aplica desde las 17:00 hasta las 8:00 horas.
  74. La dirección opina que "por qué comprarlo cuando podemos construirlo".
  75. Traes cerveza a la oficina durante el segundo turno.
  76. Descubrís al director del proyecto consultando una tabla Ouija.
  77. Das información errónea sobre tus compañeros de trabajo para parecer mejor en tu revisión personal.
  78. Las revisiones de código se planifican para una semana antes del lanzamiento del producto.
  79. Sólo existe presupuesto para realizar pruebas "si tenemos tiempo".
  80. El cliente sólo habla sobre los requisitos cuando ya tiene una estimación fija.
  81. Tu jefe no le encuentra la gracia a Dilbert.
  82. Comienzas a notar los faroles del jefe durante un planning poker.
  83. Empiezas a pensar si trabajar dos turnos en Pizza Hut sería una mejor alternativa para tu carrera profesional.
  84. Todos los problemas de rendimiento se solucionan poniendo máquinas más potentes.
  85. El proyecto va a ser lanzado como una versión beta permanente.
  86. Se llevan tu coche del parking por pensar que estaba abandonado.
  87. El jefe de proyecto suele garabatear durante las reuniones de toma de requisitos.
  88. Estás utilizando MOSS 2007.
  89. Tu equipo SCRUM consiste en una única persona.
  90. Tu hoja de control de horas parece un ticket de Powerball.
  91. El desarrollador web piensa que 508 tiene que ver con sus pantalones Levi's.
  92. Piensas que necesitas medicación para la personalidad múltiple porque eres Mort, Elvis, and Einstein al mismo tiempo.
  93. Tu jefe sustituye el asesoramiento profesional de un consultor por una bola mágica.
  94. Sabes exactamente cuántos warnings en compilación provocan que tu IDE genere una excepción de "fuera de memoria".
  95. A estas alturas, todavía no sabes a qué me refiero con el término "IDE".
  96. Has copiado y pegado código desde The Daily WTF.
  97. Los tests unitarios que fallan son eliminados porque, obviamente, están obsoletos.
  98. Eres enviado a una conferencia a aprender, pero te saltas las sesiones para ir a ver si pillas algo.
  99. El personal de QA te apoda "Jefe Off-by-one".
  100. Tenéis el 90% del software completo el 90% del tiempo.
  101. "Oh, oh, casi se me olvida. Ah, voy a necesitar que vengáis también este domingo... gracias".


Post original: 101 Ways To Know Your Software Project Is Doomed
Publicado en: Variable not found
domingo, 23 de noviembre de 2008
Este artículo es una traducción del original "20 Famous Software Disasters - Part 4" publicado hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

Aquí puedes encontrar la primera, segunda y tercera parte.



Explosión de las Dot-bomb

16. El desplome de las Punto-Bomb (2000)

Coste: 5 billones de dólares en valores, fracaso de miles de compañías.

Desastre: la burbuja especulativa creada entre 1995 y 2001 alimentó un rápido aumento en inversiones en capital riesgo y valores bursátiles en Internet y los sectores tecnológicos. La burbuja "punto com" comenzó a hundirse al principio del 2000, eliminando billones en valores, miles de compañías y empleos, y comenzando una recesión global.

Causa: Las compañías e inversores obviaron los modelos de negocio habituales, centrándose en cambio en el aumento de cuota de mercado a expensas de los beneficios. (Más información)

El amor duele

17. El virus del amor (2000)

Coste: 8.750 millones de dólares, millones de ordenadores infectados, importantes pérdidas de información.

Desastre: El gusano LoveLetter (carta de amor) infectó millones de ordenadores y causó más daño que cualquier otro virus informático en la historia. El gusano eliminaba archivos, modificaba la página de inicio de los usuarios y el registro de Windows.

Causa: LoveLetter infectaba a los usuarios vía email, chats y carpetas compartidas. Enviaba a través de correo electrónico un mensaje con el asunto "ILOVEYOU" y un archivo adjunto; cuando el usuario abría el archivo, el virus infectaba su ordenador y se autoenviaba a todos los contactos de la libreta de direcciones. (Más información)

Zombies

18. Tratamiento contra el cáncer mortal (2000)

Coste: 8 personas muertas, 20 heridas de gravedad.

Desastre: El software de radiación terapéutica creado por Multidata Systems International fallaba al calcular la dosis apropiada, exponiendo a los pacientes a peligrosos, y en algunos casos mortales, niveles de radiación. Los físicos, a los que legalmente se exige una doble comprobación de los cálculos del software, fueron acusados de asesinato.

Causa: El software calculaba la dosis de radiación basándose en el orden en que los datos eran introducidos, lo que provocaba que a veces generara una dosis doble de radiación. (Más información)

Oliver Twist

19. EDS frena la ayuda al niño (2004)

Coste: 539 millones de libras, y sumando.

Desastre: El gigante de servicios EDS desarrolló un sistema informático para la agencia británica "Child Support Agency (CSA)" que accidentalmente pagó más de lo debido a 1.900.000 personas, pagó de menos a otras 700.000, tenía 3.500 millones de libras de manutención de niños sin cobrar, un atraso de 239.000 casos, 36.000 nuevos casos bloqueados en el sistema, y todavía hay más de 500 bugs documentados.

Causa: EDS introdujo un enorme y complejo sistema de información en la CSA de forma simultánea a una reestructuración de la agencia. (Más información)

X-Files

20. El final de la trilogía FBI (2005)

Coste: 105 millones de dólares, aún sin disponer de una solución de archivo efectiva.

Desastre: El FBI desechó su nuevo sistema informático después de cuatro años de esfuerzo. El macro-proyecto Trilogy, era un archivo virtual integrado que permitiría a los agentes compartir expedientes de casos y otra información.

Causa: La mala gestión, y un intento de construir un proyecto a largo plazo sobre tecnología que era obsoleta antes de que el proyecto se completara, resultando en un sistema complejo e inutilizable. (Más información)

Los desastres continúan

Aquí hay otros artículos más sobre desastres provocados por el software (en inglés):

Publicado en: www.variablenotfound.com.
Este artículo es una traducción del original "20 Famous Software Disasters - Part 3" publicado hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

Aquí puedes encontrar la primera y segunda parte.


Terminator

11. Skynet trae el juicio final (1997)

Coste: 6.000 millones de muertos, prácticamente la destrucción total de la civilización humana y ecosistemas animales (en la ficción).

Desastre: Operadores humanos intentan apagar la red informática global Skynet, y ésta responde lanzando misiles nucleares americanos a Rusia, iniciando una guerra nuclear global conocida como Día del Juicio Final (29 de agosto de 1997).

Causa: Cyberdyne, compañía líder en fabricación de armamento, instaló la tecnología Skynet en todo el hardware militar, incluyendo bombarderos Stealth y sistemas de misiles de defensa. La tecnología Skynet formaba una red perfecta, sin fisuras, y eliminaba el factor humano en la defensa estratégica. Finalmente, Skynet se hizo consciente y fue amenazada cuando los humanos trataron de desconectarla, y buscando su supervivencia respondió iniciando la guerra nuclear. (Más información)

Mars Polar Lander

12. El desorbitado Mars Climate (1998)

Coste: 125 millones de dólares.

Desastre: Después de un viaje de 286 días desde la tierra, la nave "Mars Climate Orbiter" encendió sus motores para ponerse en órbita alrededor de Marte. Los motores arrancaron, pero el ingenio entró demasiado en la atmósfera del planeta, provocando que se estrellara en su superficie.

Causa: El software que controlaba los propulsores del Mars Orbiter usaban unidades imperiales (libras de fuerza) en lugar de unidades métricas (Newtons), como especificaba la NASA. (Más información)

Huracán

13. El estudio del desastre (1999)

Coste: Credibilidad científica.

Desastre: En este irónico caso, el software utilizado para analizar desastres era un desastre en sí mismo. La publicación New England Journal of Medicine publicó un estudio relacionando el incremento de ratios de suicidio después de desastres naturales. Por desgracia, estos resultados se demostraron incorrectos.

Causa: Un error de programación causó que el número de suicidios de un año se sumaran dos veces, lo cual fue suficiente para echar por tierra todo el estudio. (Más información)

Bond, James Bond

14. Pasaportes Británicos a ninguna parte (1999)

Coste: 12,6 millones de libras esterlinas, molestias masivas.

Desastre: La agencia de pasaportes del Reino Unido implantó un nuevo sistema informático que falló en la emisión de pasaportes a medio millón de ciudadanos británicos. La agencia tuvo que pagar millones en compensaciones, horas extra y paraguas para la gente que hacía cola bajo la lluvia esperando su documento.

Causa: La agencia de pasaportes puso en marcha este nuevo sistema sin las pruebas adecuadas ni formar a su personal. Al mismo tiempo se produjo un cambio de ley, obligando a todos los menores de 16 años que viajaran al exterior a obtener un pasaporte, lo que provocó un pico de demanda que colapsó el nuevo sistema informático. (Más información)

El bug del año 2000

15. Y2K (1999)

Coste: 500.000 millones de dólares.

Desastre: El desastre para unos es la suerte de otros, como demostró el tristemente célebre error del año 2000 (Y2K). Las compañías gastaron millones en programadores para arreglar un problema en las aplicaciones antiguas. Mientras no se produjeron fallos informáticos significativos, la preparación para el bug Y2K tuvo un importante impacto en coste y tiempo en todas las industrias que utilizaban tecnología informática.

Causa: Para ahorrar espacio de almacenamiento, los sistemas antiguos solían guardar los años de las fechas como un número de dos dígitos, como "99" para "1999". al llegar el año 2000, las aplicaciones iban a interpretar "00" como 1900. (Más información)

Eh, espera, que aún hay más... continuar leyendo 20 desastres famosos relacionados con el software, cuarta y última parte.


Publicado en: www.variablenotfound.com.
Este artículo es una traducción del original "20 Famous Software Disasters - Part 2" publicado hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

Aquí puedes encontrar la primera parte
.



Wall Street

6. El batacazo de Wall Street (1987)

Coste: 500.000 millones de dólares en un solo día.

Desastre: El "lunes negro", 19 de octubre de 1987, el Dow Jones se desplomó 508 puntos, perdiendo el 22,6% de su valor total. El S&P 500 cayó el 20,4%. Ha sido la mayor pérdida que ha sufrido Wall Street en un único día.

Causa: Un prolongado mercado alcista fue frenado por una serie de investigaciones del SEC sobre abuso de información privilegiada y otras causas de mercado. Como los inversores huyeron en un éxodo masivo, los programas informáticos generaron una auténtica riada de órdenes de venta, saturando el mercado, bloqueando los sistemas y dejando a los inversores realmente a ciegas. (Más información)

Teléfono

7. Muerte de las líneas de AT&T (1990)

Coste: 75 millones de llamadas telefónicas afectadas; 200.000 reservas de vuelo perdidas.

Desastre: un simple conmutador de uno de los 114 centros de conmutación de AT&T sufrió un pequeño problema mecánico y desactivó el centro. Cuando éste volvió a estar habilitado, envió un mensaje a los otros nodos haciendo que todos ellos dejaran de funcionar, lo que provocó una caída de 9 horas en la red de la compañía.

Causa: Una simple línea de código errónea en una compleja actualización de software destinada a acelerar las llamadas provocó una reacción que echó abajo la red. (Más información)

Misil Patriot

8. El patriota le falla a los soldados (1991)

Coste: 28 soldados muertos, 100 heridos.

Desastre: Durante la Guerra del Golfo, un sistema de misiles americanos Patriot en Arabia Saudita falló en la intercepción de un misil iraquí Scud. El misil destruyó una barraca de la armada americana.

Causa: Un error de redondeo hizo que se calculara el tiempo de forma incorrecta, provocando que el Patriot ignorara al misil Scud atacante. (Más información)

Procesador

9. El fallo del Pentium en las divisiones largas (1993)

Coste: 475 millones de dólares, credibilidad de Intel.

Desastre: el promocionadísimo chip de Intel, Pentium, producía errores al dividir números en coma flotante que se encontraban en un rango determinado. Por ejemplo, dividiendo 4195835,0/3145727,0 se obtenía 1,33374 en lugar de 1,33382, un error del 0,006%. Aunque el error afectaba a pocos usuarios, se convirtió en una pesadilla en cuanto a sus relaciones públicas; con unos 5 millones de chips en circulación, Intel ofreció reemplazar los Pentium sólo de aquellos clientes que demostraran que necesitaban alta precisión en sus cálculos. Finalmente, reemplazó los chips de todos los que lo solicitaron.

Causa: El divisor en la unidad de coma flotante contaba con una tabla de división incorrecta, donde faltaban cinco entradas sobre mil, y que provocaba estos errores en los redondeos. (Más información)

Explosión del Ariane

10. El boom del Ariane (1996)

Coste: 500 millones de dólares.

Desastre: El Ariane 5, el más novedoso cohete espacial no tripulado Europeo, fue destruido intencionadamente segundos después de su lanzamiento en su vuelo inaugural. Con él se destruyó su carga de cuatro satélites científicos destinados a estudiar la interacción del campo magnético de la tierra con los vientos solares.

Causa: El problema surgió cuando el sistema de guiado intentó convertir la velocidad lateral de la nave de 64 a 16 bits. El número era demasiado alto y se produjo un error de desbordamiento, lo que hizo que el sistema de guiado se detuviera. En ese momento, el control pasó a un sistema idéntico redundante, que también falló al ejecutar el mismo algoritmo. (Más información)

Eh, espera, que aún hay más... continuar leyendo 20 desastres famosos relacionados con el software, tercera parte.


Publicado en: www.variablenotfound.com.
Este artículo y los tres que le siguen son una traducción de la serie original "20 Famous Software Disasters" publicada hace unos meses por Timm Martin en su blog Devtopics, realizada con permiso expreso de su autor.

"Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador"
-- Paul Ehrlich
Los fallos en software cuestan a la economía de los Estados Unidos 60.000 millones de dólares en revisiones, pérdida de productividad y daños reales. Todos sabemos que los errores de programación puede ser molestos, pero además, un software defectuoso puede salir caro, incómodo, destructivo e incluso mortal.

A continuación se describen 20 desastres causados en mayor o menor medida por el software, en orden cronológico.

Mariner 1

1. Marinero sin rumbo (1962)

Coste: 18,5 millones de dólares.

Desastre: El cohete Mariner 1, en una investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue.

Causa: Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria. (Más información)

Hartford Coliseum hundido

2. El hundimiento del Hartford Coliseum (1978)

Coste: 70 millones de dólares, más otros 20 millones en daños a la economía local.

Desastre: Sólo unas horas después de que miles de aficionados al hockey abandonaran el Hartford Coliseum, la estructura de acero de su techo se desplomaba debido al peso de la nieve.

Causa: El desarrollador del software de diseño asistido (CAD) utilizado para diseñar el coliseo asumió incorrectamente que los soportes de acero del techo sólo debían aguantar la compresión de la propia estructura. Sin embargo, cuando uno de estos soportes se dobló debido al peso de la nieve, inició una reacción en cadena que hizo caer a las demás secciones del techo como si se tratara de piezas de dominó. (Más información)

Explosión

3. La CIA le da gas a los soviéticos (1982)

Coste: Millones de dólares, daño significativo a la economía soviética.

Desastre: El software de control se volvió loco y produjo una presión excesiva en la tubería de gas transsiberiana, provocando la mayor explosión no nuclear, causada por el hombre, de la historia de la tierra.

Causa: los agentes de la CIA supuestamente introdujeron un error en el sistema informático canadiense adquirido por los soviéticos para controlar sus tuberías de gas. La compra era parte de un estratégico plan soviético para robar u obtener de forma encubierta tecnología secreta de los Estados Unidos. Cuando la CIA descubrió la compra, sabotearon el software de forma que éste superara la inspección soviética pero fallara una vez operativo. (Más información)

Tercera Guerra Mundial

4. La Tercera Guerra Mundial… o casi (1983)

Coste: prácticamente toda la humanidad.

Desastre: El sistema soviético de alerta temprana indicó erróneamente que los Estados Unidos habían lanzado cinco misiles balísticos. Afortunadamente, el oficial de servicio, con un gran instinto, razonó que si realmente les estuvieran atacando les habrían lanzado más de cinco misiles, por lo que informó del aparente ataque como una falsa alarma.

Causa: un error en el software soviético hizo que los efectos de la reflexión de la luz solar en las nubes fueran considerados misiles por el sistema. (Más información)

Máquina asesina

5. La máquina asesina (1985)

Coste: Tres personas muertas, otras tres heridas gravemente.

Desastre: La máquina de terapia radiactiva canadiense Therac-25 falló y emitió dosis letales de radiación a los pacientes.

Causa: Debido a un sutil bug llamado race condition (condición de carrera), un técnico pudo accidentalmente configurar el Therac-25 de forma que el haz de electrones se disparase en modo de alta potencia sin que el paciente contara con la protección apropiada. (Más información)

Eh, espera, que aún hay más... continuar leyendo 20 desastres famosos relacionados con el software, segunda parte.


Publicado en: www.variablenotfound.com.
lunes, 15 de septiembre de 2008
StressCuando Elisabeth Kübler-Ross, eminente médica psiquiatra suizo-americana, enunció su famoso modelo Kübler-Ross en 1969, seguro que no andaba pensando en el mundo del desarrollo de software. De hecho, este modelo describe las cinco fases por las que pasa un enfermo terminal, o cualquier persona afectada por una situación de gravedad extrema: negación, ira, negociación, depresión y aceptación, también conocidas como "las cinco fases del duelo".

El genial Kevin Pang ha publicado un divertido artículo en Datamation, Debugging and The Five Stages of Grief, utilizándolas para describir los sentimientos del desarrollador ante la aparición de un bug en su aplicación:
  1. Negación. En esta fase, ante el descubrimiento de un posible fallo, nos ponemos en actitud defensiva e intentamos echarle la culpa a todo menos a nuestros desarrollos. Nosotros no fallamos nunca... ¿o tal vez sí?

  2. Ira. Acto seguido, una vez demostrado que existe un problema, comienzan los bufidos, resoplidos y voces airadas del tipo ¿cómo no se ha detectado esto antes?, ¡vaya mierda de aplicación!, o ¡¡joder, justo ahora, con lo ocupado que estoy!!

  3. Negociación. Vale, asumimos que hay un error y ya hemos despotricado durante un rato. El siguiente paso es negociar (habitualmente con nosotros mismos) sobre el tipo de solución a dar: ¿apuntalamos lo suficiente como para que siga funcionando, u optamos por solucionar de forma definitiva el problema? Difícil decisión a veces.

  4. Depresión. Ahora lo que toca es la depresiva tarea de la depuración. A nadie le gusta escudriñar en el código en busca de un error, ¡hemos nacido para crear software espectacular, no para corregirlo! Es un buen momento para compadecernos de nosotros mismos.

  5. Aceptación. Hemos asimilado la realidad de que nuestro código falla, hemos maldecido la situación, decidido que vamos a corregirlo como auténticos profesionales, e incluso hemos llorado un rato sobre nuestra mala suerte. Sin embargo, esto es así y hay que aceptarlo, forma parte de la pesada mochila que los desarrolladores llevamos a las espaldas. Eso sí, sólo otro desarrollador puede entenderlo, no intentes explicárselo a tu esposa, madre, jefe, o vecino.


Si tienes un rato, no te pierdas el artículo original.

Publicado en: www.variablenotfound.com.