Me 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

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.

---

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)

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)

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)

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)

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):

• Software Bugs in the Data Reservoir
• History's Worst Software Bugs
• Top 10 IT Disasters of All Time
• Risks Digest: Forum on Risks to the Public in Computers and Related Systems

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.

---

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)

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)

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)

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)

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)



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.

---

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)

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)

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)

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)

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)



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.

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)

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)

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)

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)

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)



Publicado en: www.variablenotfound.com.

Una prueba más de que los algoritmos de Google son inescrutables...



¡Gracias, Javi!

Publicado en: www.variablenotfound.com.

Siguiendo con el tema que comenzaba hace ya unos meses, hoy os traigo otra demo de otro motor de física, esta vez para desarrollos realizados en C++, Bullet Physics Library. Se trata de un potente motor de física en tres dimensiones para una gran variedad de plataformas, Win32, Linux, Mac, XBox, Wii, e incluso la PS3.

Las demostraciones de este motor son ejecutables, por lo que hay que descargarlas y ejecutarlas en el equipo local. Si utilizáis Windows, os recomiendo echar un vistazo al paquete de demostraciones [~3MB], con el que se puede comprobar la potencia de la librería. No es necesario instalar nada, sólo descomprimir el contenido en una carpeta y ejecutar la demo.

La revisión actual, 2.71 se publicó hace tan sólo unos días. El código fuente del proyecto está alojado en Google Code, y su modelo de licencia (MIT) permite su utilización en proyectos comerciales.

Y por cierto, existe un port para Java, jBullet, cuyas demostraciones pueden descargarse y ejecutarse a través de Java Webstart, por lo que resulta mucho más cómodo. Incluso aunque el rendimiento es muy inferior al real al usar renderizado por software, puede ejecutarse en un applet, que incrusto a continuación.

Debéis elegir una demo en el desplegable (hay cinco disponibles, os recomiendo que comencéis por la primera), en las que podéis usar las teclas "Z" y "X" para acercaros y alejaros de la escena, las flechas de dirección para girar, y con el ratón podéis aplicar impulsos a los cubos (arrastrando con el botón izquierdo) y lanzar cubos (con el bótón derecho).


Como observaréis, dentro del mismo applet aparecen instrucciones de otras teclas, incluso algunas para demos concretas. Especialmente interesante e improductivo es lanzarle piezas al cubo gigante (basic demo), intentar hacer caminar la araña (dynamic control demo), o dedicarse a transportar mesas de un lado a otro con una carretilla (forklift demo).

Que lo disfrutéis.

Publicado en: www.variablenotfound.com.

Cuando 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.

Hace unos días, el nueve de septiembre, se cumplían 61 años desde la primera aparición "documentada" de un bug informático. Y como en todos los cumpleaños, ahí va la foto del protagonista, literalmente:



Se trata de la polilla que provocó problemas de funcionamento en el primitivo ordenador Mark II el martes 9 de septiembre de 1947, al colarse y quedarse atrapada en el relé número 70 del Panel F (que debe venir a ser algo así como la línea X del archivo Y del código fuente de los de ahora). La incidencia fue reflejada en el cuaderno de bitácora (log) del sistema, al que pertenece la fotografía superior, adjuntando el insecto como prueba del delito.

El término "bug" ya se utilizaba entonces como sinónimo de error en otros ámbitos, como en telegrafía, telefonía o sistemas eléctricos, de ahí la frase que registró el operador debajo del animalito, haciendo referencia a que era la primera vez que se encontraba un auténtico bug (=bicho):

"First actual case of bug being found"

Fuente: The first computer bug

Publicado en: www.variablenotfound.com.

Y es que va a ser verdad eso de que en internet hay de todo. No sé que estaba buscando cuando me he topado con FakeNameGenerator, una web en la que indicando el sexo, la nacionalidad y el idioma a utilizar nos genera una ficha personal completa, con datos aleatorios, como la siguiente:

Benicio Romero Santacruz
Padre Caro, 61
13592 Mestanza

Email Address: BenicioRomeroSantacruz@fontdrift.com
This is a real email address. Click here to use it!

Website: Demimba.com
It looks like Demimba.com is available! Click here to register it!

Birthday: June 17, 1980

Visa: 4929 7908 0245 3619
Expires: 6/2011

UPS Tracking Number: 1Z F00 647 14 8092 598 8

Como podéis ver, incluye un nombre, la dirección una cuenta de correo (tipo Mailinator) que podéis usar para recibir mensajes simplemente pulsando el enlace mostrado, fecha de nacimiento, datos de una tarjeta VISA (no válidos, claro), y un código de seguimiento de UPS.

Puedes generar tu identidad española siguiendo este enlace.

En fin, que no es algo especialmente útil, pero curioso lo es un rato...

Publicado en: http://www.variablenotfound.com/.

Ya comenté un día mi fascinación por los motores de física en tiempo real. Siguiendo con este tema, os voy a presentar hoy otro engine con el que me he topado.

Box2DFlashAS3 es un port para ActionScript 3.0 de una librería originalmente escrita para C++, Box2D. Ahí van unas demostraciones de sus posibilidades (pulsad las teclas izquierda y derecha para cambiar la demo, "R" para resetear la vista y también podéis arrastrar objetos con el ratón):

Hace unos meses se publicó su última revisión, la 4.1.3, y se distribuye bajo licencia zlib/libpng, lo que permite su libre utilización incluso con fines comerciales.

Publicado en: www.variablenotfound.com.

Este post es una continuación de 8 curiosidades que quizás no conocías sobre los emoticonos.

4. Emoticonos corporales y otras extensiones

Aunque en su nacimiento los emoticonos sólo intentaban simular gestos faciales, existen una interesante variedad de ellos que simulan cuerpos completos y posturas que, de la misma manera, transmiten contenido de tipo emocional.

Por ejemplo, los siguientes emoticonos representan a una persona arrodillada o haciendo reverencias en esta postura. Siempre la letra "o" aparece como cabeza, le sigue el tronco y un brazo en el suelo y finalmente las piernas flexionadas:

orz, _|￣|○, OTL Or2, Orz, On_, OTZ, O7Z, Sto, Jto, _no

Estos emoticonos suelen representar ideas distintas en función de la cultura. En Japón, se interpreta como fracaso y desesperación; los usuarios Chinos, en cambio, lo usan más frecuentemente para expresar admiración a la consecución de un objetivo. Hay también quien lo utiliza para mostrar una risa extrema ("retorcerse de risa").

Otros de este tipo podrían ser:

O-&-<	Persona con los brazos cruzados
~~~~\0/~~~~	Ahogándose

Pero hay muchos más, y algunos son obras de arte: posturas, retratos de celebridades, objetos... De hecho, algunos de ellos podrían describirse mejor como arte ASCII que como emoticonos, pues no llevan asociadas emociones y se trata simplemente de adornos textuales:

Cuerpos...
(:-))-|-<	Cuerpo completo
X=(;-))-|8-<=	Novia
Celebridades...
( 8^(l)	Homer Simpson
=:o]	Bill Clinton
@:-()	Elvis Presley
Objetos...
@>+-+--	Una rosa
<')))))><<	Un pez
...

En Canonical Smiley List hay 2227 emoticonos de este tipo.

5. Emoticonos zurdos

Aunque lo habitual para leer emoticonos en el mundo occidental es girar la cabeza hacia la izquierda, también circula una variación inversa, es decir, versiones de los iconos que se visualizan girando la cabeza hacia la derecha (-:

No suelen utilizarse demasiado dado que suelen provocar confusión en los lectores, acostumbrados a la orientación habitual.

6. Emoticonos asiáticos

En 1986 surgieron en Japón una nueva familia de emoticonos, que se popularizaron muy rápidamente entre los países de Asia del este. Las dos diferencias principales respecto a los habituales en el mundo occidental son, en primer lugar, que pueden entenderse fácilmente sin necesidad de tumbar la cabeza hacia un lado y, en segundo lugar, que la expresión o emoción suele representarse eligiendo caracteres diversos para los ojos, en lugar de la boca. Algunos ejemplos simples:

(^_^)	Sonrisa
(T_T)	Llorando
(o_#)	Magullado
(O_O)	Sorprendido
(~o~)	Un bostezo

(Puedes encontrar más aquí)

Existen también otros emoticonos que hacen uso de los juegos de caracteres especiales que es necesario tener instalados en el ordenador:

	Lanzando un suriken
	Escribiendo
	¡Salud!

(Aquí hay muchos más, pero para verlos necesitarás instalar el paquete de idioma japonés en tu máquina)

7. Emoticonos... ¿patentados?

En el año 2000, la compañía Despair consiguió registrar el emoticono que solemos utilizar habitualmente para mostrar desacuerdo o enfado, :-(, en la oficina de patentes y marcas de los Estados Unidos.

Poco después, el 2 de enero de 2001, lanzaron una nota de prensa anunciando que emprenderían acciones legales contra los usuarios de Internet que utilizaran este símbolo en sus mensajes de correo electrónico, y que ya habían cursado un total de 7 millones de denuncias individuales.

En realidad, no se trataba más que de una broma, una forma de llamar la atención y dar a conocer su compañía, dedicada a la comercialización de material gráfico con mensajes humorísticos. Incluso el director de la compañía, Edward Lawrence Kersten, indicó que estaba considerando cambiar su propio nombre a :-( pues "le apetecía que su nombre simbolizara la infelicidad".

Sin embargo, no todo el mundo entendió la broma, y se generó un inmenso revuelo a nivel mundial, acusando a la compañía de querer apropiarse de un bien universal. Tanto fue así que un mes más tarde publicaron otra nota de prensa, en la que, también en tono jocoso, la empresa se comprometía con la comunidad global de internet a permitir el uso legal del emoticono en el email, vendiéndolos a través de su propia web bajo el nombre comercial Frownies™ y siempre que los usuarios se comprometieran en el cumplimiento de una desmadrada licencia de usuario final.

Y desde luego, lo que no se puede negar es el sentido del humor de la gente de Despair. Desde la web de venta online de los Frownies es posible, por tiempo limitado, adquirir originales manufacturados de uno de los modelos previstos (el classic edition) por cero dólares, una oferta inmejorable ;-)) Y por cierto, vale la pena leer en su última nota de prensa los problemas de fabricación a los que debían enfrentarse ante este nuevo reto, desde su única copia legal de Microsoft Word hasta la acentuada dislexia del empleado encargado de su fabricación.

También es conocido que los emoticonos :-) y :) están registrados en Finlandia. Igualmente han sido polémicos otros registros y patentes relacionadas, como las efectuadas por Cingular en 2006 relativo a su uso en teléfonos móviles, o la solicitud de patente de Microsoft sobre la forma de crear y trasmitir emoticonos personalizados.

8. Emoticonos y accesibilidad

Desde el punto de vista de la accesibilidad un emoticono es exactamente igual que cualquier otro elemento no textual, por lo que debe prestársele especial atención para asegurar el acceso universal a la información.

Las WCAG 1.0 (Pautas de Accesibilidad al Contenido Web) recoge como prioridad de nivel 1 proporcionar un texto equivalente para todo contenido no textual, incluyendo, expresamente, a los smileys o emoticonos entre ellos, a los que considera como arte ASCII.

Por ejemplo, el test automatizado Web Accessibility Checker incluye como problema el uso excesivo de emoticonos, o el hecho de no rodear éstos entre etiquetas como sigue:

<abbr title="emoticono de sonrisa">:-)</abbr>

Punto extra: ¿y el futuro?

Hoy en día los emoticonos basados en texto están siendo sustituidos por versiones gráficas, con efectos y animaciones e incluso sonidos. Aplicaciones de uso muy común, como procesadores de texto o clientes de mensajería instantánea realizan la conversión al modelo gráfico de forma automática, e incluyen atajos o botones en sus interfaces para incluirlos, por lo que es probable que en unos años los iconos textuales pasen a ser historias de veteranos nostálgicos, como muchas otras.

Lo que sin duda perdudará será el concepto, la necesidad de añadir el contenido emocional a los mensajes escritos, sea cual sea su forma.

¡Larga vida al emoticono!

Fuentes:

• Language Logs, the prehistory of emoticons
• Wikipedia: Emoticons
• Emoticonos en Wikipedia
• El País: 25 años guiñando
• Internet Movie Database (IMDb)
• Web Accessibility Initiative (WAI)

Publicado en: http://www.variablenotfound.com/.

Utilizo los emoticonos muy frecuentemente, desde que los descubrí en aquellos tiempos en los que Fidonet dominaba el mundo de las comunicaciones digitales entre mortales.

Y probablemente debido a su cotidianeidad, hasta ahora no les había prestado demasiada atención. Sin embargo, cuando he buscado un poco de información sobre ellos, he encontrado algunas curiosidades que creo que vale la pena conocer.

1. Sobre el término emoticono

El término emoticono es la traducción del portmanteau inglés "emoticon", fusión de "emotion" + "icon", en clara referencia a que se trata de un icono para representar emociones. Fue introducido por David W. Sanderson en su libro "Smileys" publicado en 1993, años después de la popularización de los mismos.

Aunque se suele utilizar como sinónimo "smiley", estrictamente hablando no es lo mismo. Un smiley es una representación esquemática de una cara sonriente, por lo que sólo algunos emoticonos lo son. Hay muchos que no son caras, o que éstas no presentan precisamente una sonrisa. Eso sí, el típico smiley redondo y amarillo, creado por el diseñador Harvey Ball en 1963, inspiró con su simplista representación los emoticonos gráficos que conocemos hoy.

La 22ª edición del Diccionario de la Real Academia Española, del año 2001, definió el término emoticono como:

"Símbolo gráfico que se utiliza en las comunicaciones a través del correo electrónico y sirve para expresar el estado de ánimo del remitente"

Accediendo a la definición, sin embargo, se puede comprobar que ésta ha sido enmendada y la próxima edición contará con una más acorde con la realidad, donde se deja notar el avance tecnológico producido desde entonces:

"Representación de una expresión facial que se utiliza en mensajes electrónicos para aludir al estado de ánimo del remitente"

De la misma forma, en la actualidad se acepta el término emoticón (con plural emoticones), pero parece ser que puede ser eliminado en futuras ediciones del diccionario.

2. Antecedentes históricos

La necesidad de asociar sentimientos y emociones a textos escritos existía mucho antes de la creación de los emoticonos y de la aparición de las redes de ordenadores. De hecho, se conocen apariciones anteriores de conceptos similares, aunque adaptados al medio del momento.

Está documentado el uso, en abril de 1857, del código numérico "73" como una forma de añadir a un mensaje escrito en código Morse un afectuoso "love and kisses", que más adelante pasó a formalizarse como "best regards". Ya más adelante, a principios del siglo XX, se volvió a añadir este amoroso sentimiento, codificándolo como "88".

Sin embargo, aunque esta técnica permitía incluir una componente emocional en los mensajes, no se había hecho utilizando iconos. En marzo de 1881, Puck, una revista satírica de gran éxito del momento, utilizó por primera vez representaciones gráficas para asociar emociones a los textos.

Algo más adelante, sobre 1912, el jornalista y escritor Ambrose Bierce propuso la mejora de la puntuación utilizando un nuevo signo, parecido a una U aplanada o a un paréntesis tumbado, a modo de labios sonrientes para remarcar cualquier frase jocosa o irónica.

Este mismo signo fue descrito también por Vladimir Nabovok, escritor de origen ruso conocido, sobre todo, por ser el autor de la famosa novela Lolita, en una entrevista realizada por el New York Times en abril de 1969, donde respondía a una cuestión sobre su valoración respecto a otros escritores de la época y anteriores:

I often think there should exist a special typographical sign for a smile -- some sort of concave mark, a supine round bracket which I would now like to trace in reply to your question.
_______________________________________

A menudo pienso que debería existir un símbolo tipográfico especial para una sonrisa -- algo parecido a una marca cóncava, un paréntesis tendido que me gustaría registrar como respuesta a su pregunta.

El 10 de marzo de 1953, el periódico New York Herald Tribune publicó, entre otros medios de la época, un anuncio de la recién estrenada película Lili, en el que aparecen por primera vez dos de los emoticonos más conocidos:

Today You'll laugh :-) You'll cry :-( You'll love <3 'Lili'
_______________________________________

Hoy reirás :-) Llorarás :-( Amarás <3 'Lili'

Ya en el ámbito electrónico, los usuarios del sistema PLATO, considerado una de las primeras comunidades virtuales, comenzaban en la década de los 60 y 70 a diseñar iconos a base de superponer en pantalla varios caracteres estándar. Por ejemplo, como aparece en la ilustración, superponiendo en la misma posición los caracteres V, I, C, T, O, R e Y, era posible obtener una figura donde fácilmente podía reconocerse una cara muy sonriente.

3. El origen de los emoticonos en comunicaciones digitales

En abril de 1979, Kevin MacKenzie sugirió a los suscriptores de MsgGroup, una de las primeras listas de distribución de ARPANET, el origen de la Internet de hoy en día, la utilización de algún mecanismo para indicar emociones en el inexpresivo correo electrónico. Concretamente, se le atribuye el uso del símbolo "-)" para indicar contenidos irónicos en su mensaje:

Perhaps we could extend the set of punctuation we use, i.e.: If I wish to indicate that a particular sentence is meant with tongue-in-cheek, I would write it so:

"Of course you know I agree with all the current administration's policies -)."

The "-)" indicates tongue-in-cheek.
_______________________________________

Quizás deberíamos extender el conjunto de signos de puntuación que utilizamos, por ejemplo: si quiero indicar que una frase en particular debe ser entendida como una ironía, la escribiría así:

"Por supuesto, sabes que estoy de acuerdo con todas las políticas actuales de la administración -)"

El "-)" indica que el mensaje es irónico.

Aunque su propuesta concreta no fue acogida con especial entusiasmo, los pioneros de las redes de comunicación comenzaron a utilizar variantes de estas expresiones en sus mensajes, la mayoría de las cuales no ha trascendido hasta la actualidad.

Más tarde, en septiembre de 1982, Scott Fahlman envió el siguiente mensaje a un tablón de la BBS de la Universidad Carnegie Melon:

19-Sep-82 11:44 Scott E Fahlman :-)
From: Scott E Fahlman

I propose that the following character sequence for joke markers:

:-)

Read it sideways. Actually, it is probably more economical to mark
things that are NOT jokes, given current trends. For this, use

:-(
_______________________________________

Propongo la siguiente secuencia de caracteres para marcar las bromas:

:-)

Leedlo inclinando la cabeza. En realidad, probablemente sea más económico marcar lo que NO sea broma, dada la tendencia actual. En este caso, usad

:-(

En este mensaje, Fahlman proponía la utilización de los emoticonos :-) y :-( para expresar emociones relacionadas con un mensaje escrito, y más concretamente para que el lector pudiera identificar cuándo un texto debía ser entendido como una broma y cuándo no. Es curioso que el mensaje original, al que pertenece el extracto anterior, fue recuperado de viejas cintas de backup de la universidad veinte años después de su publicación por un investigador de Microsoft, Mike Jones.

Estos emoticonos sí fueron aceptados, y a partir de ese momento comenzó su utilización de forma masiva. Por esta razón, se considera a Fahlman como el padre de los emoticonos tal y como hoy los conocemos, aunque no todo el mundo está de acuerdo con ello.

Él mismo afirma en un artículo que es el inventor del emoticono lateral... o al menos uno de ellos. Pero sí está seguro de haber sido el primero en utilizar la secuencia :-) para indicar una broma en el medio digital.

4. Emoticonos corporales y otras extensiones

Continuar leyendo en 8 curiosidades que quizás no conocías sobre los emoticonos, segunda parte.

Desde siempre me han fascinado los motores de física en tiempo real, probablemente debido a mi absoluta ignorancia en el tema. De hecho, cada vez que me topo con alguna demostración de uno de ellos, no puedo evitar pasar un buen rato jugando y observando los efectos que de forma tan asombrosa simulan la realidad.

Fisix, por ejemplo, es un motor de física en 2 dimensiones desarrollado en ActionScript 3.0 para desarrolladores de juegos o simuladores en Flash. Aunque en su web podéis encontrar más demos, incrusto una aquí para que os hagáis a la idea de lo que puede llegar a conseguirse con esta librería (podéis probar a arrastrar la muñeca por la pantalla o interactuar con los objetos).

Actualmente se encuentra en su versión alfa 0.5, y puede ser utilizado sin coste exclusivamente en proyectos no comerciales; para otros usos hay que contactar con el autor. En cualquier caso, por el tiempo que ha pasado desde su última actualización, parece que no está muy al día.

Publicado en: www.variablenotfound.com.

Semanas atrás publicaba el post "101 citas célebres del mundo de la informática", la traducción del post original de Timm Martin en Devtopics, "101 Great computer quotes". El tema me pareció tan divertivo e interesante que he realizado una nueva recopilación de otras tantas frases relacionadas con el mundo de la informática, y con especial énfasis en el desarrollo de software.

Este es el segundo post de la serie compuesta por:

• 101 citas célebres del mundo de la informática
• Otras 101 citas célebres del mundo de la informática (este post)
• Y todavía otras 101 citas célebres del mundo de la informática
• 101 nuevas citas célebres del mundo de la informática (¡y van 404!)

De todos es conocida la afición de Microsoft por poner nombres clave a sus productos durante la etapa de conceptualización y desarrollo, y la verdad es que tiene su gracia. Pero la verdad, a veces es difícil seguirle la pista a posts o conversaciones en foros donde hacen uso intensivo de ellas.

Por ejemplo, ¿recuerdas el nombre en clave de ASP.NET Ajax? ¿Y de Windows 95? ¿Y sabes que tecnología se esconde detrás de Whistler o de Avalon?

Por suerte, en la Wikipedia, que hay de todo, alguien se ha encargado de recoger, si no todos los Codenames, al menos muchos de ellos.

Enlace: List of Microsoft codenames

Publicado en: http://www.variablenotfound.com/.

Después de pasar un buen rato entretenido con la recopilación de frases célebres relacionadas con el mundo de la informática y especialmente el desarrollo de software, "101 Great computer programming quotes", publicado en DevTopics hace unas semanas, no he podido resistir la tentación de traducirlo, previo contacto con su autor, el amabilísimo Timm Martin.

Este es el primer post de la serie compuesta por:

• 101 citas célebres del mundo de la informática (este post)
• Otras 101 citas célebres del mundo de la informática
• Y todavía otras 101 citas célebres del mundo de la informática
• 101 nuevas citas célebres del mundo de la informática (¡y van 404!)

Existen muchos consejos para crear código mantenible, como los que ya cité cuando hablaba sobre comentar el código fuente, pero ninguno iguala a este:

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live"

(Codifica siempre como si la persona que fuera a mantener tu código fuera un asesino en serie maníaco que sabe donde vives)

Al parecer se trata de un leyenda urbana sobre Visual C++ 6.0, pero no deja de tener su razón...

Imagen: My Confined Space

Publicado en: http://www.variablenotfound.com/.

He encontrado una interesante relación de técnicas destinadas a favorecer la creatividad y generar ideas publicada en Neuronilla. En ella se explica, a veces de forma muy detallada, para qué puede ser aplicada cada técnica, el procedimiento a seguir en cada caso, ejemplos y enlaces para ampliar información.

A modo de resumen, encontraremos:

• Mapas mentales, que permite explorar problemas y generar ideas usando una técnica muy gráfica de acceso al potencial del cerebro a través del pensamiento irradiante.


• Arte de preguntar, útil para observar problemas desde distintas perspectivas, utilizando un arsenal de preguntas predefinidas (¿cuándo?¿qué clase de?¿con qué?...)


• Brainstorming, o tormenta de ideas, todo un clásico en las técnicas grupales para generar ideas.


• Relaciones forzadas, técnica que suele usarse complementando al brainstorming en momentos de aparente bloqueo, creando nuevas situaciones a partir de la combinación de hechos conocidos con desconocidos.


• SCAMPER, cuyo nombre está compuesto por las iniciales de las cuestiones a plantearse que estimulan la creación de ideas: ¿Sustituir?¿Combinar?¿Adaptar?¿Modificar?¿Para otros usos? ¿Eliminar o reducir?¿Reordenar o invertir?


• Listado de atributos, técnica considerada ideal para la generación de nuevos productos, o mejorar los existentes, consiste en enumerar atributos del objeto o concepto, e intentar mejorar o solucionar cada uno de ellos.


• Analogías, consistente en la generación de ideas para solucionar un problema dando un rodeo, acudiendo a otras disciplinas no relacionadas; por ejemplo, resolver un problema empresarial observando el comportamiento de un equipo deportivo.


• Biónica, técnica usada en ámbitos tecnológicos, que persigue la creación de aparatos útiles basados en el estudio de los sistemas biológicos. Ejemplos hay muchos: aviones, radares, el velcro...


• Creación en sueños, que aprovecha el poder creativo del sueño y estados de sopor para solucionar un problema, se basa en la interiorización de la cuestión a solventar antes de ir a dormir, y en tener a mano papel y lápiz para anotar las imágenes y asociaciones llegadas en estos momentos.


• Método Delfos, también llamado Delphi, que utiliza expertos en una materia para encontrar soluciones a problemas a través de análisis sucesivos de éste y las respuestas obtenidas en fases iterativas.


• Análisis morfológico, que permite generar gran cantidad de ideas en muy poco tiempo descomponiendo un problema en sus elementos más básicos, creando una matriz que facilita la combinación aleatoria de las distintas posibilidades existentes en cada uno de ellos.


• CPS (Creative Problem Solving) define procedimiento de seis pasos para la solución creativa de problemas: definición de objetivos, captura de información, reformulación del problema, generación de ideas, selección y refuerzo y creación del plan de acción.


• Técnica Clásica, que establece un método de cinco pasos secuenciales a seguir para la generación estructurada de ideas: recogida de materia prima, trabajo con ideas, incubación inconsciente, inspiración y finalización.


• Relajación, como técnica básica para potenciar la imaginación, intuición, concentración y atención.


• Visualización, o pensamiento mediante imágenes, esquiva las limitaciones del lenguaje centrándose exclusivamente en otros aspectos, facilitando la vivencia de experiencias futuras.


• Mitodología, aprendizaje del proceso creativo a través del uso de dramatizaciones basadas en personajes mitológicos.


• Ideart, usa estímulos visuales (pinturas) para la generación de ideas mediante provocación, creando vínculos entre ellos y el foco creativo.


• TRIZ, una metodología creada especialmente para generar ideas ingeniosas en problemas tecnológicos, muy utilizada en ámbitos industriales.


• CRE-IN, conjunto de técnicas destinadas a la búsqueda interna de la paz, la reflexión, relax, etc., con objeto de generar una actitud más imaginativa y desestructurada.


• 4x4x4, técnica de producción de ideas a base de la obtención, primero de forma individual y luego grupal, de ideas, que van compartiendo y seleccionando sucesivamente.


• La técnica DaVinci, que se basa en dejar actuar a la intuición para la generación de ideas de forma visual, dibujando y escribiendo conceptos procedentes del subconsciente.


• Seis sombreros para pensar, una técnica de análisis y resolución de problemas desde distintas perspectivas, representadas como sombreros. Así, los participantes deberán concentrarse en generar ideas según el sombrero que tengan puesto: optimismo, objetividad, creatividad, cautela, etc.


• Provocación, que elimina del pensamiento los patrones establecidos para la resolución de problemas al basarse en ideas deliberadamente absurdas (provocaciones), lo que facilita la generación de ideas diferentes.


• Programación neurolingüística, que ayuda a determinar las estrategias mentales de personas muy creativas para poder replicarlas en otros. Por ejemplo, del estudio de Walt Disney se obtuvo el Modelo de Creatividad Disney, una técnica basada en el comportamiento de este genio.


• DO IT, que además de traducirse como "Hazlo", corresponde a las iniciales de las fases de la técnica, Definir el problema, Open (abrir la mente a múltiples soluciones), Identificar la mejor solución y Transformarla en acción eficazmente.


• Estratal, técnica consistente en la creación de enunciados paralelos en torno al objetivo, que se consideran como una totalidad aún siendo independientes unos de otros.


• Método 635, en el que seis personas escriben tres ideas durante cinco minutos, pasándolas a sus compañeros hasta completar un ciclo. Se considera igual de efectivo que el brainstorming, y más controlable.


• Brainwriting, o lluvia de ideas escritas, utiliza una técnica similar al brainstorming para generar gran cantidad de ideas en grupos remotos, o con problemas con dificultades de comunicación.


• Conexiones morfológicas forzadas, facilita la aparición inicial de ideas sobre aspectos que no se han tenido en cuenta, así como la inspiración basada en analogías.


• Inversión, una interesante técnica que consiste en darle la vuelta al objetivo y hacer que este giro hacia un planteamiento absurdo provoque la aparición de nuevas ideas.


• Empatía, que facilita la percepción desde una perspectiva ajena al individuo.


• Alternative Environment, técnica utilizada para favorecer la aparición de soluciones inusuales a retos usuales.

Como indican al principio, aunque es posible usar muchas de ellas de forma individual, lo óptimo es trabajarlas en grupos de 6 u 8 personas de perfil heterogéneo, sin niveles jerárquicos, clima de confianza y cohesión y manteniendo siempre visibles los objetivos a lograr.

Para más información, visitad la web http://www.neuronilla.com/.

Publicado en: http://www.variablenotfound.com/.