Todo lo demás.

Todavía le falta algo (dos “cositas”, en realidad) para llegar al “MVP corregido” (el “minimum viable product” redefinido después de haber subido lo que yo creía que era el minimum). Nadie me hizo llegar nada al respecto. El uso es la intersección entre la promoción y la necesidad, y uno sólo puede controlar el primer término. Sin necesidad, la gente juega un poco y listo. Si gusta se agenda el link para después. Está muy bien, pero no es “uso”.

¿Qué hubo entre esos dos MVP’s, además de esas “dos cosas”? ¿En qué cosas ni siquiera había pensado?

Le pongo Analytics y listo.

… no. Analytics está muy bien tal cual sale de la caja, pero se queda muy corto. Permite ver el impacto de un post, de facebook, de tweeter, del mail, pero nada más. ¿Y el uso? ¿Se usa el upload de esquemas? ¿El login con google? ¿El preview de datos? ¿La ayuda?

El event tracking no es difícil de implementar. Lo difícil es determinar qué trackear (qué acciones) cuando uno ya tiene todo desarrollado. Lo que no se trackea no se ve. Trackear un par de eventos y dejar por error dos o tres afuera implica tener una visión muy sesgada del uso. Si lo hubiese pensado desde el principio, agregándolo a medida que se desarrolla la funcionalidad, afinándolo desde el momento 0…

No, no es “demasiado para un MVP”. Saber hacia dónde dirigir el segundo paso es tan importante como dar el primero. Pero hay un argumento determinante por el cual no se puede dejar para después: recolectar un volumen de datos relevante lleva –con suerte- semanas.

Try-catch-mail alcanza, y por las dudas logueo todo.

Me mando un mail con la excepción y ya está bien para empezar, con eso ya sé dónde buscar en el log. No, tampoco. Cortísimo.

Ok, hubo un error. ¿Quién? ¿Haciendo qué? ¿Qué datos de entrada? ¿Qué valores de salida? Los errores que pueden corregirse mirando un stack trace se agotan rápidamente. Después… las cosas se vuelven más complicadas. El “log viewer” de la consola de GAE es por lo menos “rústico”. Excederse por más y generar 1Gb de log por día está bien cuando podemos comprimir, descargar el archivo y procesarlo tranquilamente, pero no es el caso. Una posibilidad es recolectar parámetros de entrada y valores de salida de todas las funciones pero loguearlos sólo cuando hay un error. O afinar el log para cada operación, o guardar los errores aparte, en la base… Lo que sea, pero no es tan simple como un try-catch-all.

Cada error es un usuario–casi-perdido, y usuarios no sobran.

Malditos celulares.

¿Para qué miércoles quiero dar soporte a celulares en un data generation tool? Si, que se pueda ver… pero no importa si no es usable, no es una aplicación que tenga sentido en un smartphone. Y en la primera versión ni eso, que se vea como se ve. Total foundation ya ayuda bastante sin que hagamos nada.

Error. La aplicación no se usa en un smartphone… pero el 50% (50% medido, no es un decir) de los usuarios entra por primera vez desde uno. ¿Por qué? Y… si promociono por twitter y facebook… ¿qué esperaba? No esperaba nada - señal de que estoy viejo.

No tiene que ser usable, pero es indispensable que sea “probable”, “jugable” o al menos “agendable”. Como mínimo –muy mínimo- que puedan decir “ok, avisáme después.

Lo ideal sería que se pueda jugar un poco, abrir una cuenta y grabar. Bueno… más trabajo (y esto no está incluido en “las dos cosas”).

Consola de administración.

Paráaaaa… ¿un backoffice para un data generation tool? Si.

Estoy usando objectify. Muy lindo, muy rápido el desarrollo de todo, pero… el acceso a datos desde la consola es incluso más rústico que el log. Lo que objectify graba ya es bastante difícil de leer… Si un error “rompe” la cuenta de un usuario (se graba algo y luego le da error cada vez que entra) estamos al horno: corregir esa especie de “assembler de datos” es demasiado peligroso o directamente imposible (ni lo intenté).

Guste o no hay que hacer una página de administración donde podamos ver la data en forma prolija y modificarla si es necesario. Y no podemos empezar a hacerla sobre el hecho de que ya hay alguien que no puede entrar a su cuenta. Y también va a tener sus errores.

Y todo lo demás.

Y, finalmente, las “dos cosas” de las que hablaba al principio. Esas son las únicas dos funcionalidades propias de la aplicación de toda esta lista. Pero no voy a decir cuáles son. Talvez ni hagan falta.

Una buena

Son cosas simples (aunque no “tan simples”) si se las tiene en cuenta desde el principio. Bueno, para esto era, ¿no?

Jugar en serio.

Desde hace un tiempo vengo jugando con la idea de “desarrollar productos”.

En mi universo de fantasía, mi cabeza bulle con innumerables ideas para SaaS (Software as a Service).

Todos los días (de mi universo de fantasía) se me ocurre una idea, y son todas geniales.

Las voy anotando. Cada tanto elijo una y la desarrollo hasta llegar al MVP (Minimum Viable Product). La implemento (así de fácil y divertido, con una sola palabra, una única acción) como servicio gratuito.

La promociono (otra acción puntual, única, instantánea) utilizando “círculos concéntricos”: empiezo con un grupo reducido de usuarios y, a través de prueba y error voy depurando, limando asperezas, agregando detalles. Una vez agotadas las correcciones (porque se agotan) paso a un círculo de promoción más amplio y vuelvo a empezar.

El desarrollo es incremental, constante, continuo. La base de usuarios se expande. Se genera el feedback suficiente para determinar funcionalidades por las que un subconjunto de ellos estaría dispuesto a pagar (subconjunto que existe y cuyo tamaño es directamente proporcional a la cantidad de funcionalidades, por supuesto). 

Cada usuario paga poco, muy poco. Digamos siempre menos de “10” (dólares, pesos, yenes… no sé, no importa), pero por mes. La cosa “pega” y alcanza un cierto nivel de tráfico, y complemento ingresos con publicidad.

Y ya es hora de dejar este producto estable, tomar otra idea y volver a empezar. La mayoría de los proyectos no llegarán a tanto, pero algunos pegarán, aunque sea mínimamente. Entre todos van dejando un nivel de ingreso que se vuelve razonable en un futuro a mediano plazo.

Me gusta esa sensación de vuelta a lejanas épocas en las que me sentaba en la Atari 800XL y programaba cualquier cosa que se me viniese a la cabeza por el gusto de hacerlo y nada más, plus reconocimiento social (¡los usuarios me adoran!) y monetario.

Eventualmente la pego con algo y vendo algún desarrollo por 7 u 8 cifras. Hago donaciones a proyectos filantrópicos y con el resto me dedico a recorrer el mundo en mi avión privado (con barra). Están invitados.

… y después suena el despertador y tengo que levantarme a trabajar.

Y mientras trabajo pienso que no parece tan fantástico. Parece realizable, incluso fácil.

Por suerte soy bastante escéptico, sobre todo con mis propias fantasías. Otro thread (el pesimista) levanta una interrupción y dice que si fuese tan fácil y divertido todo el mundo lo estaría haciendo (y con éxito). Muchos lo hacen y les va bien (se despierta el primer thread –el optimista-). Son el emergente (responde el pesimista), la punta de un iceberg de proyectos hundidos por los pocos recursos (tiempo, dinero), las malas ideas, las malas ejecuciones, la mala suerte… la puta vida de mierda (y siguen discutiendo en un abrazo mortal).

¿Una fantasía irrealizable o un modelo sustentable? Sólo hay una forma de saber.

Así que me decidí a jugar en serio. Agarré la idea menos prometedora y más divertida y me comprometí a llevarla a través de todo el recorrido, desde el MVP hasta la primera versión hasta la base de usuarios y de ahí hasta donde se pueda.

¿Por qué “la menos”? Para bajar expectativas. Para no desilusionarme ante la falta de éxito inmediato. Y para cometer todos los errores posibles con una idea que ni es original ni vale tanto ni es taaan difícil de implementar, porque (en la vida real) ideas no me sobran y cuando tenga otra (en realidad… no tenía ninguna otra), espero que mejor, no quiero quemarla en un proceso de aprendizaje desde 0.

No es el proyecto en sí lo que importa sino el camino recorrido, los errores cometidos, la experiencia de hacer por uno mismo todo aquello que antes hacían otros miembros de un equipo u organización: la definición, las pruebas, la promoción, el seguimiento, el jiu jitsu comercial y otro montón de cosas que ni siquiera sé que hay que hacer.

En eso estuve estos meses. Algunos de “ustedes” (supongo que somos más o menos  los mismos lectores de siempre) saben de qué la va. La mayoría no y por ahora vamos a dejarlo así, porque estamos en la etapa de los “pequeños círculos concéntricos”.

“Sabía” que la construcción de un sistema es apenas una parte de la cosa. Ahora sé que lo que “sabía” y lo que “sé” va entre comillas.

Una cosa es saber que hay que definir un MVP y que eso es “difícil”, a tratar de hacerlo y darse cuenta de que es MUY difícil.

Una cosa es saber que un proyecto compite con otros y con la necesidad de ingresos, y otra la tentación constante de dejarlo “hasta acá, total para prueba ya está bien” y volver a terreno seguro.

Una cosa es saber que es difícil atraer usuarios y otra estar sentado delante de la pantalla, con el sistema “a disposición de la humanidad toda” y… “¿y ahora qué?” La humanidad está ocupada en sus propias cosas.

Una cosa es saber que hay que hacer networking y otra no tener nada importante para escribir o no tener ganas de sentarse y escribirlo o tomarse el esfuerzo y que no suceda nada (que por otro lado es lo más probable) y juntar los pedazos para probar otra vez.

Y en cada paso hay errores y torpezas y un millón de piedras puntiagudas para pisar.

Termino con lo que quería empezar (se suponía que iba a escribir un solo párrafo de introducción a esto que sigue, pero bueno…): un punteo de lo nuevo que, más que aprender, “sentí en carne propia” durante estos meses.

• “No sabes nada, Jon Snow”.
  
• Uno define un producto en documentos y palabras y bocetos de pantallas y eso está más o menos bien… pero hasta cierto punto. Los documentos iniciales quedan rápidamente en el olvido. No vale la pena dedicarles mucho tiempo ni bajar mucho al detalle: el objetivo principal de la aplicación, un boceto así nomás de “la pantalla importante” y listo. El objetivo no es elaborar el documento sino la idea.
  
• Personalmente, no funciono muy bien con el micromanagement del tiempo. Me entusiasmo por momentos, me desinflo por momentos. Es mejor respetar eso, pero manteniendo un balance: Hay que hacer algo todas las semanas, aunque sea forzado, y no dejar nada colgado mucho tiempo. 
  
• Sí me funciona bien el establecer una meta a corto plazo: “lo próximo que hay que hacer es…”
  
• Un dashboard es imprescindible. No puedo dejar de recomendar Trello.
  
• Medir las horas es imprescindible. No puedo dejar de recomendar Toggl.
  
• Definir y respetar hasta dónde llega el desarrollo para la primera implementación. A rajatabla. Y cumplirlo. A medida que voy armando la pantalla se me ocurren 10.000 formas mejores de hacerlo, sólo por contraposición con los problemas que veo en el armado actual… Pero esas otras formas también van a tener problemas y llevar a otras soluciones y… así no terminamos más. Se define la primera implementación, se hace y después vemos.
  
• Después de un par de meses de desarrollo, la idea original puede parecer una mala idea. ¿No debería empezar de nuevo? No. Así como hay que probar que es una buena idea, también hay que probar que es una mala idea antes de dejarla por el camino. Y para eso hay que implementarla.
  
• Otra vez (y van tres): respetar el MVP a rajatabla. Escribir en el backlog es muy terapéutico para descargar tensiones. 
  
• Pero ojo, el backlog puede convertirse en una bolsa de gatos muy rápidamente. Hay que mantener el orden, priorizar, jerarquizar, descartar, agrupar, dedicarle un poco de tiempo cada vez, pero constantemente. Es un embole, sí.
  
• Con el primer usuario cambia absolutamente todo. Lo que parecía usable es obvio que no, las buenas ideas resultaron malas y la sensación general es, otra vez, la de que esto no va a ningún lado (un pensamiento recurrente). Hay que perseverar, corregir y mejorar sin torcer el rumbo, resistir la tentación de “barajar y dar de vuelta”.
  
• Después de la primera implementación se acabaron las ideas, hay que seguir a los usuarios: se arregla o mejora lo que se usa, se implementa lo que nos reclaman. Primero hay que hacer que funcione, pero después todo se trata de que se entienda y se use, y eso es mucho más difícil.
  
• Y si nadie lo usa y nadie reclama… insistir con el autobombo y la promoción.
  
• Y si nadie lo usa y nadie reclama (después de un tiempo)… bueno, ahí quedó.
  
• … pero meter un feature que nadie quiere de vez en cuando sólo porque es divertido mantiene el entusiasmo.
  
• En resumen: POCO de todo para la primera versión: pocos documentos, poca funcionalidad, poco código, poca complejidad, poco riesgo, poco tiempo perdido.
  
• Salvo paciencia. MUCHA paciencia.

The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

Visibilidad.

Gran Proyecto (con mayúscula), muy “visible” para la gerencia de Megaempresa, vital para la subsistencia de NoTanGranPeroGranConsultoraOSoftwareFactory, y por tanto muy “visible” también para la gerencia de ésta última.

Desde nuestro punto de vista (de sistemas) no es más que otra aplicación de formularios que le pegan una y otra vez a una base de datos, más un sinfín de reportes que vienen a sacar lo que los formularios pusieron.

Otra gran, torpe, enmarañada, traicionera, e incansable generadora de un aburrido caudal de incidentes de fácil solución técnica, y que serían de fácil solución a secas si no fuera por el hecho de que más o menos la mitad de ellos contradice lo que indica la otra mitad.

Así que una horda de programadores armada con papel secante intenta contener ese río, resuelve uno y otro y alterna entre “A” y “no A” en un proceso que arroja tanta agua como recoge.

Hay otro caudal que lo alimenta, un caudal de programadores, analistas, managers y demás sacos de carne “recursos” que van pasando, pasando y pasando a ritmo creciente. Si no fuera por este otro caudal que aporta toda la energía desperdiciada en aquél ida y vuelta inútil el proceso descrito sería el santo grial del movimiento continuo.

Los gerentes, como esto es importante, están en contacto con “el equipo”, los conocen, interactúan con ellos más que con el resto. Es a esto a lo que se le llama “visibilidad” y que consiste en que, de vez en cuando, se abre un espacio en esos cielos y asciende alguno, (probablemente aquél con más habilidad para el alpinismo que para la programación) dejando al proyecto, que es realmente importante, en manos del resto que ahí queda, papel secante en mano (mientras el alpinista saluda desde lo alto).

Así es que, gracias a la “visibilidad” del proyecto los otros reman, reman y reman hasta que, hartos y sin esperanza, abandonan en busca de algún horizonte en donde sus entrenados brazos sean mejor recibidos. Aquellos en los que el entrenamiento no hace efecto y que por lo tanto carecen de otras expectativas (que los hay), esperan pacientemente su turno para el ascenso.

Unos y otros son reemplazados velozmente, así que eso que llamamos “equipo” (y que no es más que un fotograma de una película interminable) apenas puede acumular una muy vaga idea del negocio que el sistema viene a sostener, ya que el escaso conocimiento penosamente adquirido por prueba y error se va tan rápido como se acumula. Del negocio se sabe que es grande y millonario y que no es una verdulería ni un almacén de ramos generales, pero eso no alcanza para dividir las aguas y tomar la mitad de correcciones que corresponde para parar la rueda.

En fin… cualquiera que trabaje en sistemas un tiempo es expuesto a una de las más generosas fuentes de fina ironía que esta vida puede dar: el trabajo y, sobre todo, el trabajo en sistemas y, sobre todo, el trabajo “corporativo”. Si este tiempo es más o menos largo el sistémico, si sobrevive y lo sigue siendo (o mejor dicho, para sobrevivir y seguir siéndolo) habrá desarrollado un fino sentido de la ironía y del humor, o un cinismo a toda prueba, o todo eso junto. Por suerte algunos explotan genialmente esos efectos colaterales esas habilidades, y así tenemos a Dilbert (adivinen de dónde sacó Scott Adams la inspiración para sus personajes), o a Sinergia Sin Control, o al mayor repositorio de esfuerzo sin sentido y desperdicio de inteligencia jamás creado, TDWTF.

Porque lo más irónico de todo es que funciona y que buena parte de nosotros hemos vivido o viviremos de ello, y que es lo que termina financiando los juguetes (lenguajes, metodologías, herramientas, patrones, arquitectura) con los que nos entretenemos mientras, distraídamente, hacemos girar la rueda. En fin…

…que al mundo nada le importa
yira…
yira…

La queja.

Soy quejoso por naturaleza. Siempre le encuentro el pelo al huevo y, a falta de errores o problemas más graves, hago de un charquito una inundación…

A veces exagero un poco. Cuando mis compañeros de trabajo están –razonablemente- ya un poco hartos de mis cancioncitas plañideras les recuerdo, como para equilibrar un poco la balanza, que si bien me quejo

a) estoy en general encargándome activamente o lidiando con el problema, así que eso me da cierto derecho a una breve descarga emocional –a veces no es tan breve como debería-, y

b) estoy constantemente pensando y tratando de proponer soluciones –a veces peores que el problema, pero bueno… prueba y error, y sin error no hay prueba- y que

c) soy el primero en ponerle el hombro a cualquier intento de mejora, incluso cuando no crea que vaya a funcionar –probemos, con un poco de suerte me equivoque-.

Sí, a veces exagero y soy demasiado duro con algún temita en una solución que, en general, funciona bien. Pero bueno, es parte mi forma de motivar –correcta o no, efectiva o no, ésa es- y de motivarme a concentrarse no en lo que salió bien sino en lo que salió mal, que es lo que merece más atención.

Lo que es seguro es que es menos probable –a veces se requiere de más de un golpe- que me vuelva a dar con la misma piedra… aunque luego encuentre otra con la que impactar.

Por otro lado, hay personas en las que la queja es sólo eso, una queja. Una enumeración interminable de problemas, errores y malas decisiones que no las mueve a la acción o al cambio en lo más mínimo.

Estas personas piensan en el pelo antes de hacer el huevo. Como el “pelo a futuro” desmotiva, se quedan en la inacción y la queja se vuelve constante –porque sin acción nada cambia-, autosuficiente e inmortal.

Si es la queja la que lleva a la inacción o si es la excusa para la inacción, es imposible de saber. Pero es en todo caso indiferente, si el resultado es el mismo y es la nada.

Pero ojo, porque el quejoso no es mentiroso y no necesariamente tiene malas intenciones. Normalmente los problemas sobre los que la queja se asienta son reales, la práctica de la observación pasiva lo ha vuelto experto en su detección.

Así que –para mí- tampoco es prudente hacer oídos sordos a su cantinela. Lo que debemos evitar –a veces harto difícil- es quedar atrapados girando en la órbita de su parálisis.

Una solución imperfecta es siempre mejor que nada. Incluso una solución equivocada es mejor que nada, es una posibilidad menos en el camino de la prueba y error. Hacemos sistemas, no estructuras de concreto, y siempre podemos volver atrás y buscar otra salida. El tiempo insumido, al que usualmente calificamos de “perdido”, no será tal hasta que nos demos por vencidos.

¡Feliz año nuevo!

Se termina el año… se terminó. Un año en el que los vientos de cambio han soplado bastante fuerte para mí, tanto en lo personal como en lo profesional, y del que no puedo quejarme.

Espero que la hayan pasado tan bien como yo, y que si no fue así que el 2010 empiece y termine mejor.

Felicidades a todos, ¡nos leemos!

Huerfanitos.

Permítaseme un poco de humor gris tirando a negro.

En todo emprendimiento que venga pariendo software desde algún tiempo podremos encontrar desarrollos en diferentes estadíos de su camino hacia la obsolesencia: los hay desde embrionarios hasta mantenidos con vida artificialmente, pasando por recién nacidos encantadores que prácticamente no hacen nada por sí mismos, infantes con terribles rabietas que reclaman noches en vela, adolescentes indomables pero llenos de energía y posibilidades, adultos productivos e independientes y ancianos, venerables fuentes de sabiduría o mañosos insoportables cuyos achaques reclaman constante atención.

Y los hay huerfanitos, de todas las edades. Ya sea debido a que sus progrenitores hayan pasado a mejor vida o huido en estampida cual vil Frankenstein o desentendido de su cuidado o sido asesinados (o ajusticiados merecidamente), son usualmente víctimas de la indiferencia de los miembros del equipo de desarrollo.

Proliferan –me imagino, no me van a pedir rigor científico justo ahora-, más en consultoras que en empresas dedicadas a un producto o que en software factories. Supongo que porque las segundas cuidan mucho a su único hijo (o a lo sumo a sus pocos hijos) y las últimas son padres espartanos e inmisericordes que no tienen reparos en arrojar al abismo a sus vástagos más débiles, en el mejor de los casos, o madres de alquiler que paren a pedido y si te he visto no me acuerdo.

Pero si definimos como consultora a un emprendimiento que no sólo desarrolla un producto sino que también se hace cargo de su mantenimiento correctivo y mejoras funcionales (que cobra religiosamente), nos encontramos con que en este tipo de organizaciones no es tan sencillo dejar atrás las consecuencias de viejos errores… institucionalmente hablando, claro, porque sus integrantes intentarán hacerlo a toda costa (o serán eventualmente obligados a ello), y de ahí la proliferación de estos huerfanitos.

No es mi intención ser cruel inútilmente, hablo desde la experiencia: son peligrosos, créanme. Carentes y muchas veces necesitados de atención, se nos pueden pegar como garrapatas. Es así como, a través de una inocente tarea de instalación, un pequeño fix o una mejora estética nos encontramos siendo referentes, tutores, encargados, o directamente padres sustitutos de alguna de estas criaturitas de las que conocemos poco y nada.

El entorno no propicia el despegue. Si les toca transitar esta situación verán con horror como, aliviados al ver que a otro se le ha adjudicado el trasto, sus otrora solidarios compañeros de equipos evitan el tema (“y sí, alguien tenía que hacerse cargo”) o intentan naturalizarlo (“che, vos estabas con aquello de… ¿no?”), si no es que literalmente huyen despavoridos. Y no tardarán en aparecer problemas de los cuales, obviamente, nadie sabe nada y nadie nada quiere saber, salvo que tenemos que hacernos cargo.

¿Solución? Es aquí donde con un poco de demagogia podría decir que la única definitiva es adoptarlo, encauzarlo, educarlo, corregirlo, domarlo si es necesario para resolver el problema de una buena vez por todas… pero también es una posibilidad buscar a algún desprevenido, dejarle la canastita cerca, tocarle el hombro, voltear y caminar rápidamente sin mirar atrás, silbando bajito con aires distraídos.

Día del Blog 2009

Un año más, otro día del blog (como si hubiese participado en tantos, este es apenas mi segundo). Aquí van mis recomendaciones (sin un orden en particular):

Yoriento: Yoriento es, para utilizar su propia definición, un blog sobre “orientación profesional, búsqueda de trabajo, empleo 2.0, productividad personal, coaching, psicología en la empresa, networking, recursos humanos en internet”… y se queda corto. Difícil encontrar un tema que Alfonso Alcántara no haya tocado con seriedad pero a la vez con un estilo desenfadado y repleto de buen humor. Alfonso es (muy) adicto a su twitter, y vale la pena seguirlo.

Navegápolis: un blog de lo que me gusta, desarrollo de software, sin más. Mucho Scrum, agilidad, recursos, opinión sobre herramientas, métodos, arquitecturas, patrones, situaciones laborales, mucho humor y trazo grueso, sin bajar al detalle (a veces exasperante) del código puro.

lboisset’s Ruminations: “Ibo” anda un poco disperso últimamente, quejándose de excesos de trabajo y experimentando con su posterous (ay, estos chiches nuevos que me cuesta entender). Sincero y personalísimo como pocos, es el blog del jefe de proyectos que todos quisiéramos tener.

Pons Asinorum: es raro Pons, de nariz respingada y aires un tanto aristocráticos (“El hablar, por su facilidad, puede ser imitado por todo un pueblo; la imitación en el pensar, del inventar, ya es otra cosa.”). Pero atrae. A veces no puedo estar más de acuerdo, a veces sus ideas me resultan brutalmente desagradables, pero siempre interesantes y de irreprochable argumentación. Desafiante.

La hora de la pavada, 3x1 para lo último. No todo es seriedad en la vida, no todo es trabajo, no todo es pensar. Existe el cine shampoo, y existe el blog shampoo, aquellos en los que entramos y de los que no podemos salir, que siempre nos sacan una sonrisa, que nos tienen un par de horitas a la semana pensando en nada: There, I fixed it, Fail Blog, y el increíble Awkward Family Photos.

Seguiría recomendando, pero bueno, hay que ser breve para que sirva. El resto está por aquí, en el blogroll (en la barra de la derecha), referenciados en las entradas, compartidos en twitter, friendfeed o delicious.

Relacionada: mis recomendaciones del año pasado.

500+ entradas.

Hace apenas un par de minutos recordé que estaba cerca de las quinientas entradas, hito que merece algún tipo de comentario (aunque sea para rellenar un sábado de poca inspiración) o algún post especial, de acuerdo con la humana fascinación por los números “redondos”.

Bueno, el hecho es que… se me ha pasado. Ésta es la entrada número 504 desde aquélla que dio el puntapié inicial, el 17 de mayo del año pasado.

Irónica y casualmente la entrada 500 ha sido Frases: pereza y apatía.

Bueno, eso es. Gracias a todos por sus visitas y comentarios, es ese feedback lo que me da la motivación para seguir. Nos leemos.

Curados de espanto.

No son todos malos hábitos los que adquirimos los programadores en el transcurso de nuestra vida profesional. Para nivelar un poco quiero traer a cuento varias características que casi todos compartimos, y que de seguro estarán presentes en un buen programador… tienen que estar presentes en un buen programador, ya que todas giran alrededor de un tema que es central en el desarrollo de software: los errores.

Todo software no trivial tiene errores (y como siempre digo, la mayoría de los triviales también). Y si por buena ventura un software en particular no los tiene seguro que los requerimientos que le dieron origen sí. Y si por alguna de esas casualidades cósmicas los requerimientos (y por tanto el software) son consistentes en los papeles, seguro que el usuario o el analista o el redactor o el programador se ha equivocado en su interpretación u omitido alguno de ellos con tal mala suerte que el resultado es consistente aunque, por supuesto, erróneo… y en el imposible caso de que todo esté bien… serán las necesidades del cliente las que cambien o las que cambiarán en breve.

Y hay que tener en cuenta que los innumerables errores detectados (ya sea durante el desarrollo o como defectos en el producto) son apenas una pequeña fracción de los que cometemos todos los días… y sin embargo aquí estamos.

Aunque a veces sucede, no es usual que ante un problema un programador se rasgue las vestiduras, se deprima, paralice o caiga presa de delirios apocalípticos. Esto es, básicamente, porque nuestra vida laboral es una eterna sucesión de problemas y soluciones… que generan más problemas.

¿Qué es lo que –al menos creo yo que- he aprendido?

El camino para estar a salvo de los problemas no es evitar que se produzcan (son inevitables) sino tener alternativas.  Para eso existen los resguardos, los procedimientos alternativos, las salidas de emergencia. Prevenir no es sólo prevenir el problema, sino también sus consecuencias.

Los manotazos de ahogado no sirven. La suerte existe, pero es escasa y no se puede confiar en ella. Hay que medir el costo de un intento a ciegas. ¿Podemos hacer una prueba rápida, a ver si funciona? ¿No romperemos algo más en el intento? Bueno, hagámosla. Pero no podemos perder tiempo tirando tiros al aire, la magia no existe y hay que pensar, buscar, investigar, rastrear, no queda otra.

Identificar precisamente el problema es siempre el primer esfuerzo. Tratar de arreglar “algo” que no se sabe qué es es sencillamente imposible. Trabajar sobre las consecuencias es una opción para ganar tiempo, pero nunca una solución a mediano o largo plazo.

No se puede resolver un problema de fondo sobre la emergencia. Cuando se presenta una emergencia hay que resolverla (en lo posible rápidamente) para aliviar la presión y poder pensar y resolver el problema de fondo con tranquilidad… Creo que en esto todos fallamos más de una vez, tal vez no tanto en la resolución rápida, sino en la disolución de la causa subyacente. ¿Cuántas veces dejamos parches provisorios como soluciones “definitivas” que no tardan en crear más y más graves apuros?

Presionando no se resuelve nada, por lo menos en sistemas. No es de mucha ayuda gritarle lo obvio al administrador de la red –que todas las terminales están fuera de servicio o que el mundo va a explotar-. Si encuentra la solución en un tiempo razonable será a pesar de ello y no gracias a ello. Ya habrá tiempo de repartir responsabilidades y amenazas luego, hay que concentrarse en buscar una solución.

Hay que dejar trabajar. Si nos es posible paliar las consecuencias o aliviar la presión, ésa es la forma de ayudar. Y si no está entre nuestras posibilidades hacerlo… mucho ayuda el que no estorba, dice el refrán.

Aprender por prueba y error implica resolver, aunque sea parcialmente, problemas de fondo. De cada problema, de cada situación, tenemos que quedarnos con alguna mejora. Puede ser pequeña, tal vez no una solución completa, tal vez apenas una alerta temprana para la próxima vez, algo, lo que sea. Si vivimos en un interminable devenir de emergencias, la única forma de salir de ello es de a poco, aprovechando el poco tiempo que nos queda para ganar más tiempo.

¿Qué puedo ser…? (meme).

  ¡Oh! ¡Oh! (Entusiasmo) ¡Me han pasado un meme! Ha sido Iboisset, a él se lo ha pasado TicTac… ¿y esto con qué se come?

Es uno difícil… “¿Qué puedo ser?” Uno puede ser tantas cosas… para complicar más la reflexión hay que tener en cuenta que lo que uno puede ser suele confundirse dolorosamente con lo que uno quiere ser.

Creo que puedo ser útil, servir para algo, hacer una diferencia. Usualmente no una gran diferencia, pero siempre alguna. Quiero ser un buen compañero de equipo y creo que puedo serlo… pero bajo mis términos, lo que implica que a veces puedo, desde algún punto de vista, ser un poco… desalmado, diría.

Puedo ser alegre, divertido, despreocupado, triste, hosco, irascible. A veces quiero ser en blanco y negro (o a lo sumo en CGA), pero -como todo el mundo- puedo ser a colores o en escala de grises.

Me interesa saber qué dirían Improbable, Alfonso o Juan, así que a ellos les paso esta molestia.

Novedades personales (fiesta del autobombo).

Para todos aquellos que no siguen mi blog de personales, sobras, retazos y clase B en general, no prestan atención a mis interesantísimos twits, no son parte de mi red en LinkedIn, apenas si leen de vez en cuando el feed y sólo entran al blog cuando hay algún video o imagen que no carga en el reader -y ni hablar de leer mi perfil aquí en la columna de la derecha-… bueno, para todos excepto una ínfima –pero valiosa- minoría (snif), aclaro: acabo de cambiar de trabajo (¡tada!).

Efectivamente, hoy fue mi segundo día como programador en una “proveedora de soluciones basadas en nuevas tecnologías bla bla bla”, Iceberg Solutions. Lo que llamaríamos coloquialmente una consultora o software factory, tirando a mediana diría yo, pero en todo caso visiten su página web.

Si vienen leyendo este blog desde hace un tiempo entenderán que sí, he sido tentado por el lado oscuro (no creo tener hijos por ahí, pero andaré con cuidado por la dudas). Lo digo –antes de que alguien me lo eche en cara- por cosas como ésta y ésta, que son las que preceden conclusiones del tipo “el pez por la boca muere” o “eres amo de tus silencios y esclavo de tus palabras” (tal vez ya he escrito demasiadas)… aunque para hacer honor a la verdad –o para complicarla tanto que apenas se entienda- también hay que decir que, en mi afán por contemporizar y brindar una lectura un poco irónica y mordaz pero nunca extremista (que al fin y al cabo aquí está mi nombre y apellido) he escrito esto y esto otro.

Como ya he dicho, es muy pronto para hablar de lo nuevo –salvo decir que me estoy llevando, por suerte y por ahora, una muy buena primera impresión-. Se me ocurrió que cuando termine esta suerte de orgía autorreferente hija de un egocentrismo fuera de control (v.g.: este post) sería bueno comentar un poco este proceso de selección, como para escapar a tanta teoría que se ha posteado sobre el tema en este blog (como aquí, aquí, aquí, y también por acá y acá).

Pero esas son, por ahora, promesas. La realidad es que bastante vida le he robado al fiel lector estirando este post que bien podría haber cumplido su cometido con una frase o –exagerando- un pequeño párrafo. Seinfeld estaría orgulloso.

Evitando la claustrofobia.

En LLeva a tus monitos de paseo divagaba sobre la importancia de “sacar” a los programadores al mundo real en cada oportunidad que se presente, llevarlos (no a todos juntos como a un grupo de jardín de infantes al zoológico, se entiende) a las oficinas de los clientes, a las reuniones, a los relevamientos, a las charlas de capacitación, etcétera.

En aquel post justificaba la actividad mencionando los beneficios de conocer las particularidades del negocio para el cual programan y diseñan, su entorno, los clientes, los usuarios: una transmisión más precisa de ese otro paradigma a los sistemas en los que se materializa, más sentido común en la interfaz del usuario, la posibilidad de encontrar nuevas ideas o herramientas… Beneficios, en definitiva, para el producto, para la empresa proveedora de software y para el cliente.

Ayer @rgil, que viene del lado de la consultoría, publicó El "arturo" y los estereotipos, cuya (breve) lectura recomiendo y de donde cito:

Hace unos días vino un consultor de una de estas grandes a una entrevista de trabajo. Le entrevistaban dos personas que, casualmente, habían trabajado en empresas de ese tipo [una de las Big Four]. Precisamente por eso, no podían dejar de reírse al comentar la entrevista y los términos que utilizaba "el arturo": "quiero pasar a cliente final", "¿cual es la denominación exacta del puesto?", "¿a quién debo "reportar"?", "¿cuales son las funciones y necesidades del puesto?", "¿cual será la estructura de mi equipo?"...

El consultor empleado de la gran empresa multinacional, tan empapado de esa cultura que ya no la reconoce como propia de un entorno particular, que la ha internalizado tan profundamente que choca al salir de ese entorno (aunque sea de esta forma que describe el artículo, más bien simpática, resultando ligeramente extravagante) es comparable al programador rodeado de programadores, algoritmos, patrones de diseño, clases, herramientas, e incapaz de sustraerse de ello.

Si cuando vemos una factura sólo vemos una relación cabecera-detalle, si cuando vemos una hoja de ruta sólo pensamos P=NP… tenemos un problema. El aislamiento profesional nos convierte en el estereotipo de nuestra profesión, de una manera que puede resultar desde simpática a patológica.

Salir, conocer otros ambientes, otros profesionales, otras personas, nos entrena no sólo para construir mejores sistemas (si sólo pensamos en función de eso, es el mismo problema), sino también para ser un poco más normales.

En LLeva a tus monitos de paseo los beneficios y la responsabilidad de establecer esa buena práctica estaban del lado de la empresa u organización. Aquí, ya que hablamos de beneficios (casi diría de necesidades) personales, tenemos que ubicar la responsabilidad de nuestro lado. En principio, responsabilidad de detectar el problema, de darnos cuenta de que estamos trabajando aislados profesional o personalmente para luego hacer algo al respecto.

Un equipo debe tener una fuerte cohesión, eso es indiscutible. Pero que la unanimidad sea la norma para todas las decisiones, que todos a nuestro alrededor adopten naturalmente el mismo punto de vista sobre temas controversiales o tiendan hacia las mismas soluciones o tengan los mismos gustos, pasatiempos y distracciones (¿son realmente distracciones?) debería, cruzada cierta frontera (difícil de establecer, pero desde el afuera se reconoce claramente), encender una alarma. Sentirse cómodo en el ambiente laboral es indispensable, pero demasiado cómodo ya es un poco preocupante… e incómodo fuera de éste es clara señal del problema.

La solución es tan simple y difícil como salir de vez en cuando. Si puede proponerse dentro de lo laboral, tomando responsabilidades o tareas que impliquen interacción con el afuera, mejor. Pero si esto no es posible habrá que buscar esas actividades y encontrar el tiempo para llevarlas a cabo. Es para nuestro propio beneficio, por lo que no debemos esperar a que un jefe o una oportunidad laboral nos lo sirva en bandeja.

Por suerte internet nos deja sin excusas para no conocer, aunque sea virtualmente, el exterior. Con tanto blog personal y profesional y conversación y web 2.0 las herramientas para la comunicación están ahí, al alcance de la mano. Es sólo cuestión de utilizarlas.

Más allá de eso, cursos, seminarios, ponencias, congresos… son buenas oportunidades para relacionarse con otros profesionales de nuestra área (pero de distintos entornos laborales). También podríamos participar de eventos no están relacionados con la informática o el desarrollo sino con el negocio para el cual servimos en un momento determinado.

Y creo que, si bien no es indispensable, es bueno tener alguna verdadera distracción, un verdadero hobby no tan relacionado a la vida profesional. Una actividad en la que refugiarse en momentos de saturación y que nos desconecte de vez en cuando.

Distraído.

Ya sé, es XKCD,  lo lee todo el mundo. Pero me siento tan identificado con esto que tengo que postearlo.

No es algo muy político de decir… pero bueno, estamos entre amigos. La conversación –teorizo- se establece en el mínimo común denominador de los participantes más extrovertidos, lo que hace que a veces me ponga a programar mentalmente. Recalco, a veces (otras estoy sinceramente cansado).

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.

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.

¿Qué malos hábitos de la vida real te ha provocado la programación?

Esa pregunta en stackoverflow ha motivado la friolera de 457 respuestas, cada una más delirante que la otra. Es gracioso (¿o triste?) constatar que lo que uno imagina como pequeñas y personalísimas manías son en realidad taras compartidas por miles de programadores alrededor de todo el planeta.

Algunas de las tantas con las que me he sentido identificado:

I tend to take things hyper-literally. For example, my wife was annoyed when she used to ask "Do you want to take out the garbage?" (no) instead of "Will you take out the garbage?" (yes). […]

---

Q; Do you want tea OR coffee?
A: Yes

---

I really need control+Z in real world.

---

I find that sometimes I speak very precisely, and get irritated when somebody […] doesn't appreciate the precision of what I said, and treats what I said kind-of sort-of similar to what I said.[…]

---

Believing that being right is enough.

Believing that people will listen to reason.

[…]

---

If I ask a question that's yes/no, I have serious difficulty processing an answer that isn't either one of those.

For instance, Q: "Do you care if I flip the channel?" A: "I'm IMing my sister."

To me, this is like: public bool canFlip() { return "I'm IMing my sister"; }

The return value here is clearly a string, and supposed to be a bool. From the other person's end they're answering the question. From mine they've just committed an invalid cast error. If I ask again and they answer the same, well, that's throwing an exception in a catch block.

… y esas son sólo un par de las primeras, casi que las pondría todas.

Renovación y primeras impresiones de Windows 7

Los asiduos habrán notado una brusca caída del ritmo de publicación en estas últimas dos semanas. El trabajo tuvo algo que ver (no mucho). El inicio de clases, con las corridas y preparativos de última hora pesó un poco más. Pero la razón principal ha sido el fallecimiento de mi computadora de escritorio (una Pentium 4 HT 3.2Ghz).

Es posible que haya muerto de envidia. Su deceso se produjo a las pocas semanas de la compra de una Acer Aspire One (apenas una netbook, pero ya la superaba en performance). A través de este post le rindo un sentido homenaje…

Pero la vida sigue. No soy de jugar con el hardware. Cada vez que una máquina dice “basta” hago el esfuerzo y compro el equipo más potente que puedo para olvidarme del tema por un par de años, durante los que no me preocupo en lo más mínimo por su mantenimiento hasta que casca nuevamente.

Es ésa y no otra la razón de mi elección por un Intel Core 2 Quad Q8200, sobre un motherboard Intel DG31PR con 4Gb de RAM y una placa de video “decente” (no soy un fanático de los juegos), una GeForce 9400 GT.

Lo anterior solamente viene a cuento de poner en contexto lo que realmente me interesa, que no es el hardware sino el software. Hace un tiempo que venía con ganas de probar la beta del Windows 7, así que aproveché la obligada migración para distribuir un poco más racionalmente mis datos (después de un par de años programas, documentos, fotos, videos y desarrollos e instalaciones a medias convirtieron mis discos en una masa compacta, indivisible y desordenada de archivos) e instalarlo en una partición propia.

Preconceptos

La verdad es que si bien la muy respetable opinión (y entusiasmo) de uno de mis compañeros de trabajo cultivó mi curiosidad, era escéptico respecto de la nueva interfaz.

He visto el Windows Vista de lejos pero en la oficina sigo con el XP (que es, en mi opinión -y creo que en la de la mayoría de los usuarios-, el mejor sistema operativo de Microsoft al momento). Esperaba entonces más o menos lo mismo de siempre: muchos cambios estéticos, algunos realmente molestos, la mayoría simplemente inútiles o intrascendentes, y las opciones y funcionalidades de siempre redistribuidas de modo que se maximiza la frustración en las primeras semanas de uso, hasta el momento en el que uno se rinde y somete a los designios de la nueva UI.

Las críticas al Vista, y mi percepción de que el 7 seguiría a grandes rasgos la misma línea no ayudaban mucho. Escéptico por naturaleza, descreía del buzz positivo alrededor de la nueva versión. En resumen, esperaba el chiste de siempre: uno se pasa la primera media hora jugando y los dos o tres primeros días tratando de dejar todo como estaba.

Instalación

Primero hacer un poco de espacio: achiqué la partición de un disco de 300Gb (nota mental: es bueno tener por lo menos dos particiones –datos y sistema operativo-) con el Partition Magic y creé una nueva de 20Gb. Un par de errores y reintentos después los datos contenidos en aquel disco estaban perdidos. Empezamos bien.

Ya molesto por el trabajo de recuperación que se avecinaba inicié con el disco de instalación del build 7057 de Windows 7.

Primera sorpresa: Ok, empezaba con una partición limpia, pero eso no resta méritos. Siguiente-siguiente-siguiente, escasos 20 minutos y ya está. No lloró por drivers, ni pidió actualizaciones, no aparecieron las típicas e inútiles preguntas que interrumpen la instalación cada 5 minutos (obligándome a aburrirme cerca de la máquina), ni siquiera se equivocó con la distribución de teclado.

Me pasé el resto del día recuperando y reorganizando los archivos perdidos en el movimiento de particiones, para finalmente reformatear todo el espacio libre. Trabajo aburrido si los hay, pero tengo que reconocer que la vida es más fácil teniendo las cosas ordenadas.

Primeras impresiones

Sorpresa. Es lindo. Bueno, eso era esperable. Pero más que lindo… es casi… sobrio. No molesta. No pregunta. No aparecen mensajes extraños ni anuncios catastróficos compitiendo por mi atención para que baje, actualice o descubra.

Lo primero que llama la atención es la barra de tareas, con el famoso preview que aparece al pasar el cursor por encima del ícono del programa abierto.

Pero es más que un “chiche”. Moviendo el cursor sobre el preview la ventana emerge al frente mientras las demás se vuelven transparentes, desde allí mismo podemos cerrarla o minimizarla, o volver a la ventana anterior con sólo desplazar el mouse fuera del preview. Se puede agregar o quitar el acceso directo a ese programa en la barra de tareas desde allí mismo, por lo que ya no hay que “personalizarla”, uno lo va haciendo y deshaciendo sobre la marcha.

La otra característica que me impresionó desde el primer momento es el cuadro de búsqueda en lo que antes era el “menú de inicio”. Mantiene el foco siempre que esté abierto el menú y va mostrando los programas y opciones de configuración que concuerdan con lo que vamos tipiando. Creo que puede extenderse para buscar en internet desde allí mismo, pero todavía no lo he probado.

Ese primer día me la pasé explorando y tocando opciones… y dejé todo como estaba. No, no dejé todo igual al XP, dejé todo igual a la configuración por defecto.

La convivencia

Luego reinstalé el XP en otra partición (hay que conservarlo, no olvidar que esto es una beta), y obviamente eso rompió la instalación del 7. Reparé la instalación del 7 desde el CD (identificó el problema –XP instalado después del 7 o Vista embarulla la configuración del multiboot- y lo reparó puntualmente, sin reinstalar) y –obviamente- rompió el XP (bueno, algunas cosas no cambian nunca). Indagando un poco me enteré de que el viejo y sencillo boot.ini fue reemplazado por el retorcido y complicado BCDEdit, que superó en largo mi paciencia para estos temas, con lo cual decidí simplemente borrar todo, instalar primero el XP en una partición, luego el 7 en otra y a otra cosa mariposa (¿ven para qué es bueno tener datos y archivos propios por separado? Yo aprendí de la manera difícil). Pero más allá de esos primeros roces los dos sistemas operativos conviven y comparten el resto de las particiones sin problemas.

Un par de días después

Me rindo, tengo que reconocerlo: Windows 7 es muy, pero muy bueno. Me molesta trabajar con XP, simplemente me molesta. Las nuevas características (sobre todo las dos mencionadas arriba) son tan naturales que es tan fácil acostumbrarse a ellas como difícil resignarlas luego.

Es obvio que Microsoft ha escuchado mucho a sus usuarios y se ha adaptado más a ellos que en otras versiones, abandonando esa actitud de –me parece- imposición de visiones en la forma de interacción con el sistema.

El rendimiento es impecable, aunque es obvio que si no lo fuera en esta máquina ya sería el colmo. Me han comentado que se degrada elegantemente en equipos con menos recursos, pero no lo he probado personalmente.

Han cascado varios programas (por mérito propio), y por supuesto que programando y probando he metido un par de bucles infinitos, ejecutado algún que otro código malicioso, y llevado la máquina casi al límite (con un par de máquinas virtuales haciendo de servidores de base de datos y de páginas web al mismo tiempo) y el sistema operativo ha respondido siempre sin problemas. Dudo que alguna vez le exija más que eso y estoy seguro de que un usuario medio tampoco.

Conclusión

De que Microsoft le ha vuelto a robar ideas se ha vuelto a inspirar en Apple, a Ubuntu y demás no caben dudas. De que nos vuelven a usar como beta testers gratuitos han escuchado a los usuarios tampoco. También es verdad que para mí, por primera vez desde aquel traumático primer pasaje del NT 3.11 al 95 (¡¿dónde están mis grupos?! ¡¿Qué es esto del escritorio?!) la transición es suave, relajada, para nada traumática, y, en definitiva, muy positiva.

Windows 7, en beta y todo, ya es mi sistema operativo por defecto desde hace una semana completa, en la que me he dedicado más a trabajar que a jugar (aunque he vuelto a jugar bastante, ahora que puedo) y tengo que reconocer que es más que cómodo. Por primera vez Microsoft ha logrado que su interfaz llegue velozmente al objetivo: volverse invisible al usuario.

Ahora no hay excusas para volver al ritmo habitual. Nos leemos.

¿Aburrido?

Hace ya un tiempo que tengo agendada para comentar esta entrada de The Daily WTF. El artículo clasifica los proyectos de software según el interés que pueden representar para los programadores.

Así, el software “aburrido” tiene nombre y apellido:

[…] information systems. And while the purpose of an information system changes from company to company, as do the specific requirements, they all are essentially the same. There’s a database that models the real world, rules to define how the data may be changed, an interface to the database, and lots of different reports.

…que es casi todo software que soporte algún tipo de negocio, en contraposición con el software “divertido” que representa

[…] the type of things that we use on a regular, day-to-day basis: SVN, Google Maps, Visual Studio, Firefox, etc. In fact, as software developers, we rarely have to use boring software ourselves.

En realidad se refiere a este último tipo de software como “sexy”, lo que me lleva a poco serias reflexiones sobre las inclinaciones del autor del artículo.

Pero más allá de eso descubro, no sin cierta sorpresa, que he dedicado mi vida a proyectos “aburridos”… es más, les he dedicado años de estudios universitarios (soy Licenciado en Sistemas de Información de las Organizaciones, que bajo este punto de vista es casi lo mismo que Licenciado en Sistemas Aburridos)… este blog, habrán notado, está también dedicado a ellos en gran medida.

El artículo me ha dejado pensando. He llegado a la conclusión de que… es verdad. Ese software es aburrido. Es innegable, un hecho de la vida.

Es aburrido para los usuarios, no cabe duda: no me imagino al cajero de una de las salas de juego que utilice el sistema de gestión de la empresa para la que trabajo saltando de alegría cuando el sistema le indique que “ha completado la venta del ticket” o algo por el estilo. Tal vez sí me imagino al gerente festejando luego de consultar un reporte de beneficio, pero no creo que se deba al hecho de utilizar el sistema.

Y puede ser aburrido para los programadores, dependiendo de lo que a éstos les interese.

Si sólo te parece divertido pasarte una semana testeando diferentes tipos de algoritmos de ordenamiento para bajar el tiempo de respuesta de un servicio en 100 o 200 milisegundos… sí, probablemente este tipo de software te parezca aburrido.

Si sólo te motiva quemarte las pestañas estudiando complejas fórmulas matemáticas para lograr que esa estúpida computadora diferencie un auto de una vaca… si, un arqueo de caja es aburrido.

Si únicamente saltas de alegría cuando ese driver que estás desarrollando para que otra impresora funcione en otro sistema operativo logra imprimir un “hola mundo”… y, probablemente que el sistema arroje un error comprensible para el usuario no te parecerá un gran logro.

Esas pueden ser las motivaciones de muchos. Están muy bien, ya que gracias a ese tipo de programadores tenemos sistemas de archivos resistentes a fallos, bases de datos cada vez más rápidas, lenguajes de cada vez más alto nivel, una miríada de sistemas operativos para cada necesidad, librerías de reconocimiento de imágenes y un montón de innovaciones espectaculares para revolucionar negocios y organizaciones (no saben cuánto puede agradecer alguien como yo el “simple” Plug & Play y los drivers transparentes).

Pero las mías (y creo que por suerte las de mis compañeros de equipo también, y las de muchos otros) son otras: quiero hacer software útil para una organización.

Ese objetivo puede implicar optimizaciones, reconocimiento de imágenes, interacción con otros dispositivos (de hecho hemos tenido que hacer o utilizar algo de todo eso eventualmente) y otras cosas “divertidas” (que les aseguro que finalmente no lo son tanto), pero lo que me ha llevado a enfrentar esos problemas ha sido siempre la satisfacción de cumplir un requerimiento de la organización, y sólo en menor medida la satisfacción de resolver un problema difícil con un algoritmo ingenioso.

La gracia del desarrollo de estos sistemas no está tanto en la codificación, que efectivamente es 90% rutinaria (consulta a base de datos, operaciones simples sobre colecciones, algunos cálculos, ingreso de datos del usuario, validaciones, grabar en la base de datos y listo).

La gracia está

• en los problemas que representa un entorno de desarrollo cambiante y muchas veces caótico, con clientes que desesperan, analistas que deliran, jefes de proyecto que dicen sí a todo y programadores que cometen (cometemos) más errores de comprensión del negocio que de codificación (a no enojarse por las referencias, ya ven que hay palos para todos);

• en la necesidad de armar y mantener una estructura que soporte esas constantes modificaciones y que al mismo tiempo sea simple y fácil de usar;

• en hacer que esa codificación rutinaria sea lo más rápida y limpia posible (o incluso automática), para tener más tiempo para lo que es realmente importante: diseñar, mejorar, innovar, simplificar;

• en la coordinación e interacción con otros compañeros de equipo u otros equipos que desarrollan otros módulos del sistema;

• en la comprensión del flujo de la información de un negocio en particular y en descubrir cómo el software puede optimizarlo, ayudando a las personas a preocuparse menos por tareas rutinarias (para eso está el sistema) y más por lo que sólo ellas pueden aportar mediante su esfuerzo.

Por supuesto, estos componentes están presentes en todos los sistemas (en los “divertidos” y en los “aburridos”), sólo que en unos tiene mayor importancia que en otros.

Más que buscar o crear chiches nuevos para integrar a nuestro proyecto,  partimos de los requerimientos y buscamos aquello que represente la mejor manera de satisfacerlos.

Así, si he aprendido a programar en entornos web ha sido porque un negocio lo requería. Si adopté MVC no fue por probar el nuevo framework de Microsoft sino porque tenía un enredo entre datos, negocio y presentación que necesitaba ordenar. Si experimenté con AOP fue porque encontraba requerimientos transversales, y así…

Creo, entonces, que no hay sistemas aburridos y divertidos. El mundo del desarrollo es enorme, así que está en cada uno encontrar el lugar en el que los requerimientos encajen en las propias motivaciones.

Así que si estás aburrido… ¡muévete!

Intercambio de webcomics.

Hace apenas un par de meses descubrí los webcomics. Sabía que existían pero nunca les había prestado demasiada atención.

Es un mundo enorme en el que hay para todos los gustos. Les paso mi lista de favoritos (todavía soy un newbie, así que no esperen grandes revelaciones), me gustaría recibir sus recomendaciones en los comentarios.

Los links apuntan al sitio y las imágenes a las tiras recientes que más me han gustado.

Sinergia sin control	Geek Hero Comic
Dilbert	We the robots
Cyanide & Happiness	xkcd
A Friki's Life	Geek in Love
404	Linux Hispano
Plétora de piñatas	El señor enviñetado
TiraEcol	El show de Juanelo
Indexed  (no creo que sea un webcomic, pero… adentro)