Jueguitos de viernes: Chain of Fire

Chain Of Fire es un juego un tanto… un tanto… macabro, diría. Se trata de prender fuego (literalmente) a determinados integrantes de la multitud para provocar una reacción en cadena que aniquile a la mayor cantidad de gente posible. Todo muy esquemático, por supuesto.

Calidad y consultoras, software factories y demás.

Hoy leí por un lado Welcome to the machine en Oh My Blog! I Can’t Believe It!, que nos relata la experiencia del desarrollo de software desde las trincheras de los grandes ejércitos:

[…] Pongamos que trabajas en un proyecto en el que participa un consorcio de diecisiete empresas, y estás subcontratado por parte de una de esas empresas […]

[…] Y entonces el alucinómetro estalla cuando te dicen que no hay diseño ni especificaciones hechas. Que tu vayas tirando código, que ya ellos haran ingeniería inversa para sacar la especificación y diagramas de clases y demás en base a lo que tu hagas […]

Más tarde me crucé con Burro (o consultor) grande, ande o no en Diario de un director de sistemas:

[…] Como otras veces, el debate sobre el precio y el valor de las consultoras grandes. […] Yo estuve siete u ocho años en una de esas consultoras. […] No cabe duda de que en el coste hora de un consultor de estas compañías estás pagando una parte de la oficina de Picasso o La Moraleja, la esponsorización de una estrella del golf o un equipo de Fórmula 1, y los salarios "indecentes" (es una forma de hablar, yo no los considero así) de los socios o partner o principals, según como se llamen en cada casa. Todo esto es verdad. No creo que nadie lo discuta.

[…] tampoco ofrece dudas que un documento bien preparado por gente de estas compañías suele significar un cuidado en la presentación y en el contenido bastante mayor del que te presentan otras empresas más pequeñas. Y lo mismo que hablamos del documento podemos aplicarlo al desarrollo y ejecución de los proyectos, siempre y cuando estemos hablando de proyectos de cierta magnitud/dificultad […]

¿Qué imagen es más cercana a la realidad? ¿La de la consultora de renombre y proyectos desastrosos que de alguna manera terminan funcionando o la de la experta en la ejecución de proyectos a gran escala bajo estrictos estándares de calidad? Tal vez no haya una única respuesta, sino dos caras de la misma moneda.

Hablando de imágenes, de percepciones, es deber aclarar primero fuentes y preconceptos. Mi visión es la del programador, del desarrollador que conoce un poco tras bambalinas e intuye otro tanto. Aunque nunca he trabajado en una gran consultora o en una empresa con un área de desarrollo gigantesca como las que se mencionan, conozco y he compartido proyectos con programadores y analistas que sí y con los que he comentado muchas veces los contrapuntos entre éstas y los equipos pequeños o medianos.

A partir de esa muestra de experiencias (y juzgando contra mis propios estándares), yo me formé la idea de que:

• La irracionalidad de la metodología empleada (no la enunciada, sino la de todos los días), ya sea etiquetada como ágil o tradicional, llega a extremos insospechados transformándose en un conjunto de rituales vacíos.

• La conveniencia de las herramientas y lenguajes que se utilizan con respecto a los requerimientos de cada proyecto es -por lo menos- cuestionable en la mayoría de los casos. Se utiliza un martillo y todos los proyectos son clavos. Si el cliente pide tornillos se le entregan clavos en cajas de tornillos.

• La robustez de la arquitectura de los proyectos es similar a la del queso gruyere. De todas maneras su utilización (es decir, cuánto se respeta en la práctica esa estructura enunciada) es prácticamente nula.

• La calidad del código suele ubicarse entre mediocre y WTF.

• Los documentos de análisis internos (no los bonitos que se presentan a los clientes sino los que se terminan utilizando, si es que existen) no sirven más que de punto de partida para que los desarrolladores hagan volar su imaginación.

• Y por supuesto, las modificaciones y el mantenimiento son un infierno para ellos…

• que de todas maneras es raro que tengan que soportar por más que un par de años (la rotación es vertiginosa).

Ya sé, ya sé, hay proyectos y proyectos. La misma firma de pobre desempeño en uno desenvolverse bien en otro, y mucho tendrá que ver con ello el control y la seriedad del otro lado del mostrador. Pero sigamos.

El cliente de “Pelota Plus Consulting” no es “Megaempresa S.A” que necesita un ERP. El cliente es el gerente-de-lo-que-sea de “Megaempresa” que contrata a “Pelota Plus” sabiendo que toma una decisión irreprochable más allá del resultado del proyecto, y eso es lo que compra: cierta (mas no absoluta) seguridad para sí más allá de los resultados. ¿Para qué arriesgarse? “Megaempresa” tiene mucho dinero para gastar y el precio está consolidado por el mercado.

La atención que brinda la consultora a su cliente (el gerente-de-lo-que-sea) es inigualable: un contrato importante con muchos ceros a la derecha, presentaciones, carpetas, folletos, aulas para capacitación, equipos, gente de traje con una tarjetita a la altura de la solapa y toda la parafernalia necesaria para hacer de él alguien importante dentro de “Megaempresa”.

Todos los puntos oscuros que mencioné al principio son invisibles tanto para el cliente como para “Megaempresa”. Conforman una deuda técnica que la consultora adquiere (resultado inevitable de la industrialización del desarrollo) pero que luego transfiere a “Megaempresa” al facturarle capital e intereses (más su propio margen de beneficio) en forma de horas de mantenimiento. El cliente no sabe -ni le interesa- por qué se tardan 8 horas en correr un botón de un formulario.

¿Que se podría hacer mejor? No tiene que ser perfecto, sólo funcionar. ¿Que podría ser más barato? La pequeña consultora o equipo de desarrollo implica más riesgo y el cliente ya está asumiendo mucho… si la cosa se complica él puede terminar viendo el partido desde la tribuna.

Por lo menos así lo veo yo.

15 grandes mentiras alrededor del desarrollo de software.

De tanto mencionar a Dilbert y sus principios (y por cierto que la tira de hoy nos pega de cerca) se me ocurrió intentar algo parecido a las mentiras acerca del management, pero apuntando más específicamente a lo nuestro, el desarrollo de software.

1. Cualquiera (hablando de cualquier cosa): “Esto es fácil” (se dice mucho por aquí: No digas "programita").

2. Comerciales: “Tenemos ya desarrollado un producto que cubrirá exactamente su necesidad” (nunca se sabe si la mentira es que ya está desarrollado o que cubrirá la necesidad requerida… o ambas cosas).

3. Cualquier cifra que figure en un papel impreso y firmado.

4. Cualquier fecha que figure en un papel impreso y firmado (así sea la del cumpleaños del cadete que reparte la correspondencia).

5. El cliente: “Esta funcionalidad es vital para nosotros” (receta para el panqueque system).

6. Líder de proyecto: “Necesitamos esto para ayer” (y termina pasando lo que describía en Pedrito -el líder de proyecto- y el lobo).

7. Programadores: “Sí, lo probamos bien”.

8. Infraestructura (segundos después de que se cuelgue el servidor): “No, no estaba tocando nada”.

9. Usuario: “Ya revisé todo varias veces, tiene que haber un error en el sistema”.

10. Programadores: “Ya revisé todo varias veces, tiene que haber un error en el framework” (btw… ¿Un error?).

11. Cualquier cosa acerca de los manuales para el usuario final: su necesidad, su uso, su utilidad, su contenido.

12. Consultores, académicos, programadores estrella, grandes empresas: “Esta… (metodología, herramienta, framework) aumentará la productividad del equipo”.

13. Cualquier certificación de lo que sea (algo de eso se hablaba aquí y aquí).

14. Lo que sea que alguien diga que es importante.

15. Las listas numeradas.

Obviamente no estoy a la altura, pero a base de sugerencias se puede armar una lista más decente.

Jueguitos de Viernes: Dodge

Dodge es un juego simple, ideal para distenderse un rato con una o dos partidas cortas cada tanto (más es adicción). Naves enemigas disparan misiles rastreadores que deberemos volver en su contra para avanzar de nivel. Rápidamente comienzan a aparecer variantes cada vez más complicadas.

Frases: El principio de Dilbert.

La cosa está muy mala (Yoriento) recuerda como al pasar El principio de Dilbert. De ahí a una búsqueda rápida en Google y desempolvar un viejo post de Mundo Geek hubo un solo paso.

Un par de citas (tres, para más exactitud y desconcierto):

La premisa básica del principio de Dilbert es que los trabajadores más ineptos pasan sistemáticamente a ocupar cargos donde pueden causar el menor daño: la dirección de la empresa. Esta estrategia no ha resultado ser tan exitosa como cabría esperar.

---

El departamento de Marketing utiliza muchas técnicas avanzadas para juntar producto y comprador de una forma que eleve al máximo los beneficios. Por ejemplo, regalan llaveros.

---

Puede usted cortocircuitar las dos o tres neuronas que usa la gente a modo de sentido común, apelando a su avaricia. Nada define mejor al ser humano que su voluntad para hacer cosas irracionales en la persecución de recompensas fenomenalmente improbables. Es el principio en el que se basan las loterías, las citas a ciegas y la religión.

Hay algunas más en Mundo Geek para entretenerse hasta que compremos el libro.

1984

Puede que George Orwell (antes de empezar permítanme decirles que si no han leído 1984 han aprendido a leer para nada) haya cometido apenas un pequeño (en proporción) error con las fechas, después de todo. Digamos unos 30 años. O menos.

Pensaba en eso después de leer esta nota en público.es, de la que transcribo (qué viejo suena eso. Corto y pego, digamos) el primer párrafo:

Hace 24 años, Ivana P. cometió un delito por el que fue condenada y posteriormente indultada. Sin embargo, esta madrileña aún está pagando aquella deuda. Los detalles de los hechos por los que la condenaron aparecen relatados en la web del BOE, y después han sido clasificados en Google, el buscador que utiliza más del 90% de los internautas españoles. Aunque esta mujer ha presentado varias reclamaciones, la web sigue trayendo al presente aquella historia de hace casi un cuarto de siglo.

Orwell imaginó un Gran Hermano omnipresente y controlador. Puede que el ¿futuro? sea apenas sutilmente diferente.

Si bien es cierto que la red nos ofrece anonimato no es menos cierto que la línea entre el espacio público y el privado es, en algunos casos, confusa (claro ejemplo: Facebook), y en otros difusa.

Dejemos por un momento de lado los casos en los que los problemas puedan adjudicarse a la torpeza o ignorancia del propio navegante afectado. Son cada vez más los registros públicos por naturaleza -tales como las sentencias de los jueces- fácilmente rastreables vía buscadores. Se va conformando, con el paso del tiempo, el avance de la digitalización de la información y su anexión a la red, un gran repositorio (internet, no Google) que todo lo recuerda y todo lo publica.

Somos (y seremos cada vez más) conscientes de que teniendo disponible una memoria tan poderosa se nos cobra caro hasta el más pequeño desliz. Podría ser en el fondo de una foto inocente tomada durante una salida y publicada en el perfil de una amistad donde la señora (futura ex) encuentre por casualidad al marido peligrosamente cerca de la (futura ex) mejor amiga… un par de años después del incidente inmortalizado en unos y ceros (que, imaginemos, no pasó de una indiscreción inducida por el alcohol).

Lo que hacemos en público es público. El marido de la historia anterior poco tiene que reclamarle a Facebook sobre la desgracia de su matrimonio. Poco -creo yo- tiene que reclamarle Ivana P. a Google o al BOE la distribución de información absolutamente correcta (y pública por naturaleza), por más que afecte su vida cotidiana.

Una línea difusa… ¿y lo que hacemos en privado y es ventilado por algún torpe, indiscreto o vengativo observador? Pregúntenle si no a… (no voy a volver a cometer la torpeza de escribir otra vez ese nombre, por más visitas que genere).

El hecho objetivo es que, en público o en privado, cada vez hay más ojos alrededor nuestro, inocentes o no. Ojos que no sólo ven sino que también recuerdan. El hecho objetivo es que esa información, una vez liberada, es muy difícil de destruir.

¿Llegaremos al punto en el que la amenaza de una exposición descontrolada pese lo suficiente como para reprimir hasta el más mínimo atisbo de cualquier conducta que pudiese calificarse negativamente en el presente o el futuro? ¿Llegaremos al punto de sentirnos siempre observados y continuamente juzgados por lo que hacemos y decimos y por lo que hicimos o dijimos? ¿Presos de por vida en nuestras propias palabras y acciones pasadas?

Orwell imaginó un Gran Hermano, pero parece ser que nadie puede controlar, encauzar o reprimir el flujo de información en la red. El archivo afecta tanto a gobernantes y empresarios poderosos como a ilustres desconocidos.

Así, Gran Hermano, el gran represor, lo conformamos todos al juzgar socialmente y tomar decisiones basadas en esa información. ¿Sufre Ivana P. las consecuencias de la publicación de una condena o el hecho -innegable- de que pocos avalan con hechos la opinión expresada de que quien ha cometido un crimen puede (y merece) pagar sus deudas y vivir una vida honrosa de allí en más? ¿El marido porque la mujer ha descubierto esa foto o la imposibilidad -de ambos- de reconstruir la relación luego de eso? ¿Sufre el joven por la aparición de una foto que lo muestra pasado de copas o por el prejuicio del empleador que infiere de ella que es una persona poco seria (y que opina que la competencia va de la mano de la seriedad)?

Si, como decía antes, errare humanum est, tal vez deberíamos preocuparnos menos por la disponibilidad de la información histórica acerca de grandes y pequeños errores y momentos poco afortunados que por la interpretación y el uso que cada quien hace de ella.

Si encontrar cierta información sobre una persona en la red nos parece escandaloso deberíamos pensar por qué, qué esperábamos encontrar, y qué nos dice el hecho de que la estemos buscando (y las decisiones que tomemos en base a ella) sobre nosotros mismos y nuestros propios prejuicios.

WolframAlpha

No sé qué tan útil sea el chiche nuevo de Stephen Wolfram, WolframAlpha, habrá que usarlo más que probarlo. Mientras tanto algunas primeras ideas alrededor de él:

• No es un buscador. Llámenlo como quieran, pero no es un buscador.

• Más bien pretende ser el sistema experto definitivo.

• Tampoco creo que esté para o vaya a revolucionar nada.

• De todas maneras la idea es estupenda y muy bien ejecutada.

• Sí compite con Google aunque no directamente. Yo utilizo mucho a Google para buscar datos concretos y supongo que muchos harán lo mismo. WolframAlpha brinda respuestas directas (cuando las tiene) de una manera mucho más sencilla y categórica, está específicamente diseñado para eso. Google también cubre muy bien la misma necesidad aunque haya que buscar entre los resultados e interpretarlos. Si WolframAlpha se desempeña bien se quedará con esa tajada del tráfico (que no tengo idea de qué tan grande será, pero supongo que bastante).

• Se ha desarrollado una gran campaña previa y generado mucha expectativa. Es un arma de doble filo, pero creo que en este caso la herramienta supera la primera impresión… bueh, depende (de si el usuario es argentino o español, por ejemplo), pero en general lo hace. De todas maneras hay que chequear los resultados.

• Se ve que el equipo tiene muy en claro a qué público debe conquistar primero (ver imagen):

• Y hay más ejemplos…

• Para empezar me bajé el desktop gadget, que es una buena manera de tenerlo a mano, veremos cómo va.

• ¿Qué les ha parecido a uds.?

Actualización: acabo de leer un muy buen comentario, Wolfram's Black Box: a biologist's take on Wolfram|Alpha, por John Timmer.

1 año.

La primera entrada de este blog es del 17 de Mayo de 2008. Esto implica que hoy es su primer cumpleaños, ocasión que según la costumbre merece unas palabras. Me es muy difícil evitar lugares comunes, así que seré breve.

Más valioso que cualquier aporte que cualquiera (incluyéndome) haya podido hacer son las referencias y vínculos que se han construido. Así que simplemente quiero agradecerles a todos los que han leído y comentado, a favor y en contra, en serio o en joda con humor, dentro y fuera de este blog.

Yo sé quiénes son, pero ¿uds. saben quiénes son? Los invito a presentarse, a dejar sus links y a visitar los de los demás.

Nos leemos.

Cómo microsupervisar como un verdadero ...

Saltando desde lboisset's Ruminations hacia Amalgama de letras llegamos hasta esta vieja entrada en el blog de Santi Garcia que presenta este corto sobre micromanagement.

Se titula “How to micromanage like a real asshole ass****”. Está en inglés pero es bastante sencillo de entender y Santi se ha tomado el trabajo de transcribir y traducir los puntos básicos en su entrada. Copio aquí sólo los encabezados como un servicio a aquellos para los que seguir un link representa un desafío supremo:

Paso 1: Controle, critique, asfixie.

Paso 2: Documente el tiempo que se pierde.

Paso 3: Explique todos los detalles.

Paso 4: Controle.

Paso 5: Machaque a los disidentes.

Paso 6: Interrumpa.

Paso 7: Encuentre errores insignificantes.

Paso 8: Corrija los errores.

Y por fin, el video:

Jueguitos de viernes: Magic Pen.

¿Se acuerdan de Gravity Master? Bueno, Magic Pen parte de la misma idea: hay que hacer pasar una bolita por las banderas dibujando formas que deberán impulsarla actuando según las leyes físicas. Agrega un par de variaciones interesantes como ejes y puntos de apoyo.

Es el segundo muy buen juego al hilo (el anterior fue FWG Bridge) que se publica en la serie “Productivity Killer” que Punto Geek publica los lunes y viernes. Ahí están los links para que se suscriban a este festival de procrastinación.

Stop motion with wolf and pig.

1300 fotografías impresas le ha llevado a dokugyunyu producir este genial corto de casi cuatro minutos. La técnica es (por lo menos para mí) muy original y el final imperdible.

Visto en kirai y compartido por Cerebrado en su reader.

De salón.

Si te hace gracia necesitas conseguirte una vida:

- ¿Por qué los programadores americanos confunden el día de Navidad con Halloween?

- Porque DEC 25 = OCT 31

A mí me hizo gracia :-(

Lo reencontré en The Fucking Shit (lindo nombre).

---

Actualización: @Cerebrado (que también necesita una vida) manda un par más del mismo estilo:

- Mamá, mamá, en el colegio me llaman friki.

- ¿Y tú qué haces, hijo?

- Me bajo 2 puntos de carisma.

---

- ¿Qué es un niño complejo?

- Un niño con la madre real y el padre imaginario.

---

-Oye, ¿cuántos eran los dálmatas?

- 101

- Por el cu.. te la hinco.

---

Qué es un oso polar?

Es un oso rectangular después de una transformación de coordenadas.

¿Cuál fue el error más difícil de encontrar?

Muy buena pregunta en Stackoverflow. Me robo la primer respuesta (al momento) para que empiecen a sufrir:

A jpeg parser, running on a surveillance camera, which crashed every time the company's CEO came into the room.

100% reproducible error.

I kid you not!

This is why:

For you who doesn't know much about JPEG compression - the image is kind of broken down into a matrix of small blocks which then are encoded using magic etc.

The parser choked when the CEO came into the room, because he always had a shirt with a square pattern on it, which triggered some special case of contrast and block boundary algorithms.

Truly classic.

Visto (y compartido) por Cerebrado en Pons Asinorum.

La amansadora .Net

Allá lejos y hace tiempo, creo que por el año 2001 (tiro de memoria) Microsoft lanzaba la séptima versión mayor del Visual Studio (el primer “puntonet”) y con ella prometía llevar a los desarrolladores “de aplicaciones de escritorio” al mundo de las “aplicaciones web”.

Yo (supongo que junto a muchos otros), que venía desarrollando “aplicaciones web” de gestión en ASP 3.0, me sorprendí gratamente con el chiche nuevo que me permitía (entre otras cosas) separar fácilmente el código de la presentación (aunque nada me lo impedía antes) y crear clientes en HTML “como si fueran formularios de Windows”, con controles, eventos y todo eso.

Lleno de entusiasmo, empecé a tirar controles sobre el diseñador y a escribir código para los eventos. Casi lloro al apretar F5 y ver a la aplicación levantarse mágicamente en un servidor local lista para depurar paso a paso, “como si fuera un formulario” (también se podía antes, pero había toda una burocracia previa). Todo parecía fácil y natural.

Pero el sueño dorado se convirtió en una terrible pesadilla cuando, apenas superadas las primeras pruebas triviales, conocí a dos horrendas criaturas, dos verdaderos abortos de la naturaleza: Postback y su deforme hermano siamés, Viewstate.

Postback envía toda la información contenida en la página al servidor, obligándola a recrearse constantemente una y otra vez para acometer desde la más compleja a la más trivial de las tareas: cambiar el color de una etiqueta, mostrar un mensaje de error de validación, lo que sea. Para eso necesita a su inseparable hermano Viewstate, que almacena… muchas cosas, un montón de cosas, todas las cosas. Creo que en el Viewstate de una página ASP.Net “creada como un formulario de Windows” se encuentra el sentido de la vida, el universo y todo lo demás, pero que es inhallable.

Metiéndome un poco más en la cosa, empecé a darme cuenta de lo que Microsoft había hecho para “facilitar las cosas” en el desarrollo web. No había magia detrás de todo ello sino un conjunto de complicadísimos y muy poco elegantes hacks que hacían de aquello tan fácil y divertido llamado HTML+Javascript un verdadero infierno.

XMLHttpRequest y esa gran bolsa de gatos llamada Ajax ya era utilizada por los sitios más modernosos dando origen a las RIA's y se perfilaba como el estándar que un usuario final más o menos exigente esperaría de allí en más. Yo lo había utilizado bastante, de una manera muy rudimentaria pero con muy buenos resultados (visuales, que por adentro, ¡madre mía!). Al querer combinarlo con el modelo propuesto por ASP.NET me metí en verdadero laberinto. Si antes las cosas me parecían desprolijas ahora se me hacían imposibles.

Un (largo) tiempo después apareció Atlas… baste decir que me cuesta (y desisto de) encontrar una referencia a esas primeras versiones de… lo que sea que haya querido ser (¿herramienta? ¿plantilla? ¿paradigma? ¿framework? ¿manotón de ahogado?). Lo que es seguro es que resultó otro conjunto de engendros mutantes a los que Microsoft les dio temprana y prolija sepultura (cambiándole el nombre, como suele hacer). Pero puedo resumirlo fácilmente: no era otra cosa que Postback y Viewstate (y otro ejército de hacks berretas) actuando en las sombras para no asustar al desarrollador con su horrible refrescado en cámara lenta.

Creo que me gané el derecho a adjetivar a esa visión del desarrollo de una aplicación web (tirar controles a un diseñador y codificar eventos) como “un verdadero desastre”, una obra maestra en hacer difícil lo fácil e imposible lo (no muy) complejo. Derecho que me gané (y ahora ejerzo) por haberlo intentado seriamente. Realmente intenté (Rick Hunter es testigo) desarrollar una aplicación web razonable siguiendo ese modelo. Y fracasé, una y otra vez. Tal vez soy yo, tal vez no le encontré la vuelta, pero así fue.

Fue hora de separar los tantos: el Framework .Net, desde su primera versión, fue y es una herramienta fabulosa que mejora en cada versión, eso que quede claro. Pero esa no era la forma de utilizarla, por más que su creador la fomentara.

Una vez alejado del camino oficial marcado por una visión que pretende que desarrollar una aplicación web es lo mismo que desarrollar una de escritorio^* (y guiado por Rick Hunter, que ya se había apartado de ella hacía tiempo), todo fue “casi” sencillo (eso fue irónico, pero de todas maneras valió la pena).

Primero hubo que encerrar a Viewstate (suprimiéndolo) en una página base de la que derivan todas las demás y en las que utilizamos controles controles propios que producen HTML sencillo y como Dios manda. Luego combinar con un framework de Javascript (puede ser propio o alguno de los tantos que circulan por allí) para enviar sólo lo necesario de vuelta al servidor e incrustar los datos (o el HTML, o las dos cosas, ¿por qué no?) elegantemente en la página, sin generarla nuevamente.

Es decir que terminé haciendo lo de antes, lo mismo que hacía (desprolijamente) en ASP 3.0: producir el HTML una sola vez y luego ingresar, validar, actualizar y modificar la página con Javascript (validar en Javascript es opcional –aunque muy recomendable-, que las validaciones tienen que estar del lado del servidor sí o sí, por supuesto).

Lo de antes, sí, pero ahora con herramientas (el Framework .Net) que permiten hacer más fácilmente una implementación rápida y prolija y con mucha reutilización. Después de haber superado, claro, la amansadora .NET.

---

^* Acerca de eso de “desarrollar una aplicación web no es lo mismo que desarrollar una de escritorio”… puede ser que con XAML y Silverlight Microsoft haya encontrado un camino para unificar las herramientas de desarrollo, aunque todavía le falte mucho. Por otro lado, está más que demostrado que con Javascript también se pueden crear interfaces complejas sin perder agilidad (en cualquier navegador que no sea el Internet Explorer, claro) y sin la molestia adicional de instalar algo en el cliente, con lo que… ¿podríamos decir que en algún punto compite con Silverlight…?

Soft Cero: Un proyecto en tiempo real.

Cerebrado anda muy movedizo en estos días, mucha novedad, mucho cambio, por suerte con buenas perspectivas a futuro.

Soft Cero es su nuevo blog, en el que está relatando el devenir de uno de sus proyectos actuales, haciendo nuevo equipo con JUNIOR y NERD (?). El blog comenzó con el proyecto y todo esto es bastante reciente, así que les recomiendo ponerse al día desde la primera entrada.

Es realmente interesante ver cómo se van desarrollando las cosas desde la etapa de las grandes definiciones hasta los detalles (a los que todavía no han llegado), ojalá tenga final feliz. No dejen de participar, quién sabe, tal vez un pequeño comentario tenga gran influencia en el resultado final.

Una breve, incompleta y casi completamente inexacta historia de los lenguajes de programación.

Tal es el título (traducido, el original está en inglés) de este post en One Div Zero con el que me encuentro en este domingo de procrastinación. Algunos pasajes son increíbles, por ejemplo el que menciona la creación de Perl:

1987 - Larry Wall falls asleep and hits Larry Wall's forehead on the keyboard. Upon waking Larry Wall decides that the string of characters on Larry Wall's monitor isn't random but an example program in a programming language that God wants His prophet, Larry Wall, to design. Perl is born.

O el nacimiento de Java y C# (no, no me equivoqué con los links):

1996 - James Gosling invents Java. Java is a relatively verbose, garbage collected, class based, statically typed, single dispatch, object oriented language with single implementation inheritance and multiple interface inheritance. Sun loudly heralds Java's novelty.

2001 - Anders Hejlsberg invents C#. C# is a relatively verbose, garbage collected, class based, statically typed, single dispatch, object oriented language with single implementation inheritance and multiple interface inheritance. Microsoft loudly heralds C#'s novelty.

No se pierdan la historia completa. Vía Menéame.

Actualización: Pirx se ha tomado el trabajo de traducir la entrada al español en su bitácora de Barrapunto.

Lenguajes de programación delirantes.

10 Most Bizarre Programming Languages Ever Created (en nettuts+) es una lista de 10 lenguajes de programación simplemente delirantes. Un par de muestras:

Whitespace es un lenguaje formado exclusivamente por combinaciones de [Espacio – ASCII 32], [Tab – ASCII 9], [LF – ASCII 10]… er…. es mejor presentar un ejemplo:

En la línea anterior está mi primer programa en Whitespace, un Hello World… en realidad no, mentira, no hay nada, ¿pero quién se hubiese dado cuenta de todas maneras?

Whenever es un lenguaje en el que cada línea de código es interpretada como un ítem en una lista de tareas. El compilador selecciona una al azar y la ejecuta… whenever, es decir, cuando se le dé la gana.

Por suerte podemos indicar que para la ejecución de una línea es necesaria la ejecución previa de otra, obligando al compilador a diferirla hasta más tarde (ya adivinaron: cuando se le dé la gana). Va el ejemplo:

defer (4 || N(1)
defer (4 || N(1)==N(2)) print("Take one down and pass it around,");
defer (4 || N(2)==N(3)) print(N(1)+" bottles of beer on the wall.");
1#98,2#98,3#98;

No está en la lista (se menciona en uno de los comentarios) pero sí en Wikipedia: Brainfuck está diseñado para que pueda compilarse con un compilador realmente pequeño. Los programas resultan sumamente legibles… para el compilador, claro:

++++++++++[>++++++++++<-]>++++.---.+++++++..+++.
>++++[>+++++++++++<-]>.------------.[-]<<
++++++++.--------.+++.------.--------.[-]
<+[>++++++++++<-]>.[-]<

No tengo idea de qué hace eso (supongo que será un “Hola Mundo”), pero parece razonable.

Entrada: 10 Most Bizarre Programming Languages Ever Created.

Vía identidad geek.

Y aunque no siempre tiene que ser así…

…a veces lo es. Diferencia entre ir a casa un viernes e ir al trabajo un lunes:

Visto en Pelotón 69 (y compartido por Cerebrado).

Jueguitos de Viernes: FWG Bridge 2

Este sí que es peligroso, de esos que pueden volverse una obsesión que no deja de atormentar hasta que se supera… completando el juego.

En cada nivel tenemos que armar un puente a partir de un par de puntos de apoyo, hierro (más caro y resistente) y madera (más débil pero barata). Si no tienen nada importante que hacer, digamos en los próximos dos o tres días… hagan click aquí.

Visto en Punto Geek.

Sobre la importancia del interlocutor.

Creo que la propia experiencia nos condiciona más fuertemente que cualquier otro factor y que, si bien eso tiene su razón de ser, puede llevar fácilmente al dogmatismo.  Veo algo de esto reflejado en cada discusión en torno de alguna de las dualidades de moda: Windows vs. Linux, Software Libre vs. Software Privativo, Código Abierto vs. Código Cerrado, Java vs. .Net, Oracle vs. MS-SQL y ambos vs. MySql y PostgreSQL… uf, podría rellenar varios párrafos más (se ve que nos gusta hacer polémica). Si rascamos un poco en busca de la experiencia profesional de los polemistas veremos que abunda de un lado de la frontera y escasea (o ha sido traumática) del otro.

Un pequeño ejemplo: ASP 3.0 me produce urticaria (sobre todo si lo mezclamos con una buena dosis de xml). Pero reconozco que mucho tiene que ver el hecho de que la primera y única aplicación más o menos compleja que hice terminó como la imagen de aquí a la izquierda (extraída de este viejo post). Si hubiese tenido una segunda oportunidad desde cero podría haberme amigado con el lenguaje y hoy estaría defendiéndolo acaloradamente contra PHP (ya no sucederá, ha muerto en manos de él, y merecido se lo tiene). Pero me han comentado casos en los que mediante diversas técnicas se ha podido mantener el orden y construir aplicaciones realmente complejas sin perder la cordura en el intento.

Pero volvamos al hilo. Decía que el peso de la experiencia tiene su razón de ser, y pensaba en lo siguiente: un joven padawan está deseoso de adiestrarse en el manejo de nuevas armas, mientras que Yoda se preocupa más por eliminar al oponente (aunque no de cualquier manera, siempre mantiene las formas y sobre todo la estética). Si el padawan es criterioso no se pondrá a innovar antes de (o en medio de) una batalla… bueno, hasta aquí llego, supongo que se entiende la idea.

Volviendo ahora al desarrollo de software (del que no debería haberme apartado), repasando mi propia experiencia, veo que he cometido errores empujando la balanza hacia uno u otro lado: algunas veces he utilizado herramientas más allá de lo razonable porque las conocía (y mi experticia en ellas me permitía forzarlas) y porque los tiempos apuraban (y un largo etcétera que podemos resumir como “aversión al riesgo”). Por el otro he elegido algunos malos momentos para experimentar.

Por suerte fui aprendiendo y hoy por hoy puedo decir que acerté más de lo que pifié (por lo menos hasta ahora)… ¿por suerte? Un factor común en los errores fue que (llevado por el apuro o el entusiasmo) no tenía y no busqué un referente con alguna experiencia (por más mínima que fuese) en la “herramienta nueva”. Estoy casi seguro de que éste factor explica tanto los fracasos como los éxitos, ya que siempre que la decisión que tomé terminó mostrándose acertada sí lo tenía.

Por supuesto que no tiene por qué ser alguien del equipo (tal vez hasta sea mejor que no lo sea). Puede ser un amigo, un conocido, un allegado. O ni siquiera una persona. Podría ser un caso de éxito (o fracaso) bien documentado, un foro o comunidad en la que se tenga alguna confianza y participación activa. Tampoco es tan importante que sea un experto en la herramienta o un relato de fuente confiable. Basta que nos cuestione o nos apruebe de alguna manera, y que nos fuerce a plantear las preguntas correctas, ésas especialmente incómodas y sin respuesta precisa, en las que encontramos puntos a favor y en contra de cada posible solución, en las que prima la opinión sobre el dato y en cuya respuesta podemos incluso discernir con respecto a ese referente.

Como me señalaba hace apenas un par de días Cerebrado, cualquier programador con un par de logros y moretones encima valorará enormemente tener con quién o en dónde discutir, polemizar o pelear. Lo valora porque (sobre todo si tiene moretones) desconfía de las decisiones en solitario o tomadas por una sola persona a puertas cerradas y sin una discusión previa, así sean las propias.

Al discutir, polemizar o pelear, puede que no se llegue a un acuerdo sobre la posible superación de determinados problemas, pero por lo menos se habrán planteado y tenido en cuenta o descartados conscientemente.

Recalco: no critico el hecho de que decida una sola persona (que al fin y al cabo un equipo no es una democracia… en la que de todas maneras tampoco se decide por unanimidad) sino la falta de un intercambio de ideas previo.

Hace no mucho tiempo (aunque usted no lo crea) programábamos sin internet. En ese tiempo la experiencia era difícil de encontrar y un interlocutor válido mucho más todavía. Hoy no hay excusas, no existe ningún lenguaje o herramienta o sistema o librería o framework del que no podamos encontrar opiniones a favor o en contra. No prestar atención a esas discusiones u opiniones antes de tomar una decisión es… suicida.

Errare humanum est.

Es irónico que el camino de la mejora continua esté tan cerca del camino del estancamiento, del que lo separa apenas un cambio de perspectiva, cierta tendencia a asignar responsabilidad sobre problemas concretos a personas concretas con la vana esperanza de que desaparezcan unos con otros.

Si asumimos que inevitablemente y en toda actividad humana (no sólo en la programación) se cometen errores, produciéndose defectos en los productos resultantes, no nos extrañaría tanto encontrarlos ni en las tareas más simples ni en los productos de más alta calidad.

Cuando es necesario que un producto adquiera cierta calidad, deberíamos controlar el proceso y el resultado en busca de problemas más que esperar a que no se produzcan mágicamente -o por la simple respuesta a un reclamo más o menos imperativo-.

Y al momento de controlar, tendríamos que tener muy en claro que estamos controlando en busca de errores y no para calificar o evaluar la calidad del trabajo de una persona o de un equipo.

Esto es porque, dada la primera premisa, no tendría sentido preocuparse por quién comete un error o por qué ya que la respuesta es obvia: porque es un ser humano o producto de un ser humano. Deberíamos focalizarnos en dónde y cuándo y por qué no se ha detectado antes en caso de que hubiese sido posible.

Siguiendo esa línea llegaríamos a la conclusión de que la cuantía de los errores no tiene relación directa con la idoneidad (“el que hace se equivoca, y el que no, se calla la boca”) por lo que, consecuentemente, no se deberían tomar ni admitir represalias por ellos (aunque muchas veces es deber tolerarlas).

Una postura opuesta, por ejemplo la medición del desempeño a través de la cantidad de errores cometidos y registrados “con nombre y apellido” lleva a las personas a actuar a la defensiva, al temor a cometerlos o a ocultarlos una vez cometidos. Pero como son inevitables -y esto es un hecho- la única forma de no tener errores es no haciendo nada. Es decir que esta actitud nos lleva, inevitablemente, a la parálisis.