Libro: Rework

Titulo: Rework
Autor: Jason Fried y David Heinemeier Hansson
Editorial: 37Signals (supongo)

Hace un par de semanas terminé de leer uno de los libros de la gente de 37signals, Rework, que habla de su filosofía y experiencias en el desarrollo de software, la gestión de personas, el trato a los clientes, y en definitiva, todas las áreas no puramente técnicas sobre el negocio del software.

Se trata de un libro muy fácil de leer, con el que es difícil estar en desacuerdo (si no lo estás, me interesaría saber por qué, y si alguna vez has desarrollado un producto) y que a pesar de no ser exhaustivo, es una muy buena recopilación de consejos prácticos si quieres vivir con el software.

El estilo del libro recuerda al del Guy Kawasaki y es de los que van directo al grano, sin historietas ni adornos. Pura experiencia para el que la quiera o pueda aprovechar.

Como se trata de un libro muy variado, que está parcialmente online, e incluso traducido (aunque no parece muy buena traducción por lo poco que he visto de ella), y como ya hay medio millón de reviews en Internet, me abstendré de recopilar citas interesantes y me centraré en una que desgraciadamente sufro en mi puesto actual: considerar todo como urgente (ASAP:as soon as possible).

ASAP is poison Stop saying ASAP.
We get it. It's implied. Everyone wants things done as soon as they can be done. When you turn into one of these people who adds ASAP to the end of every request, you're saying everything is high priority. And when everything is high priority, nothing is. (Funny how everything is a top priority until you actually have to prioritize things.) ASAP is inflationary. It devalues any request that doesn't say ASAP. Before you know it, the only way to get anything done is by putting the ASAP sticker on it. Most things just don't warrant that kind of hysteria. If a task doesn't get done this very instant, nobody is going to die. Nobody's going to lose their job. It won't cost the company a ton of money. What it will do is create artificial stress, which leads to burnout and worse. So reserve your use of emergency language for true emergencies. The kind where there are direct, measurable consequences to inaction. For everything else, chill out.

Para terminar, solo comentar que es un libro indispensable si quieres hacer un buen trabajo con el mínimo de recursos, si trabajas en una PYME, en una startup, si planeas montar un producto o si te interesa conocer otras maneras de funcionar a parte de las que venden las megaconsultoras.

La cultura del ascenso

Vivimos mayoritariamente en una sociedad laboral basada en una falacia. La falacia del ascenso.


La cultura que impera señala como símbolo de éxito el cambiar regularmente de trabajo (como tarea o profesión, no como sinónimo de empleador) para realizar cualquier cosa alejada del núcleo original, del trabajo real, del trabajo productivo. A estos cambios sucesivos se los llama ascensos y son una de las lacras que convierte a excelentes profesionales en malos gestores y a brillantes gestores en pésimos líderes.


El principio de Peter en acción nos dice que cualquier persona asciende hasta su nivel de incompetencia, y aun así consideramos los ascensos como algo positivo.


Suponemos, equivocadamente, que es positivo pasar de hacer [ponga aquí un trabajo] a coordinar el hacerlo, luego ponerse a supervisar a los trabajadores y al coordinador, más adelante a planificar las líneas de trabajo y finalmente ponerse a plantear nuevas estrategias para todo un grupo de planificadores, supervisores, coordinadores y curritos. Siempre tratando de ir más y más arriba en una jerarquía lo más grande posible.


Imagino que esta evolución de la carrera profesional tiene que ver con el hecho de que cada paso pone a disposición de las decisiones del trabajador a un número cada vez mayor de personas (en una dañina jerarquía vertical), y ver eso como algo deseable y bueno podría estar relacionado con algún pedazo de nuestro cerebro de mamífero, ese que considera que ser líder de manada o macho alfa es una garantía para procrear con las hembras bajo nuestro mando. Pero eso es harina de otro costal. Sigamos.


Se presupone que un supervisor tiene más conocimiento y sabiduría que los supervisados... Y en muchos casos es así, pero si solo eres supervisor es muy probable que al cabo de un par de años sepas mucho menos que cualquiera de tus subordinados (bienvenido al siglo XXI, donde todo cambia cada 6 meses). Y por descontado un supervisor que tenga conocimiento y sabiduría para hacer bien su trabajo será un excelente trabajador que perderemos, quizá no totalmente, pero sí en su mayor parte, ya que en el mejor de los casos, si le mantenemos en su trabajo normal pero añadiendo el rol de supervisor, tendremos un trabajador con una carga administrativa adicional que le impedirá alcanzar su nivel habitual. Es un Win-Lose: ganas un supervisor malo, y pierdes un trabajador bueno. Y lo mismo para el resto de ascensos. ¿Quizá lo único bueno que se puede hacer es ascender a los peores trabajadores y demás? ¿Se pararía así la sangría de productividad? ¿Es la patada hacia arriba la mejor estrategia?


Creo que lo único que tiene sentido es cambiar la cultura del ascenso a una de recompensas (horarios, sueldo, herramientas...). Una cultura de empresa que premie a los trabajadores con una diversidad de conceptos: desde el dinero al tiempo, pasando por el derecho a usar herramientas especiales (coches, teléfonos, tablets, ordenadores...), participaciones en la empresa o la capacidad de decidir en qué proyecto entran o no. Una cultura social donde no importe a cuanta gente tengas "debajo" ni el puesto que tengas en la empresa, sino lo feliz que te sientas en tu trabajo. Una cultura corporativa donde una recompensa no lleve aparejado necesariamente un cambio de rol sino una mejora de vida y un aumento de productividad.


Como decía al principio, la cultura del ascenso es una falacia, y una de las que hacen daño. Obliga a someterse al principio de Peter, con gente focalizada en obtener poder sobre los demás, cargos y títulos, aun a costa de descuidar el trabajo "real". Lleva a establecer jerarquías verticales y luchas de poder como la que se comenta en la Ley de Parkinson. Y en lugar de conducir a una institución a desempeñar un trabajo con un alto grado de precisión y fiabilidad, convierte a las organizaciones en burocracias llenas de trepas.


Sí, soy un idealista, y la realidad del mundo empresarial hace que tenga serias dudas sobre si este tipo de medidas funcionarían en la realidad, pero creo que merece la pena intentar apoyar y formar parte de una cultura social y empresarial de estas características.


Debemos cambiar para mejorar. Pero no tanto de puesto como de cultura.


Para terminar, un par de apuntes menos cáusticos sobre la cultura del ascenso. La cultura del ascenso puede que tuviese sentido hace un siglo, cuando una persona podía pasar por varias áreas de una empresa y entender cada una, alcanzando un nivel aceptable de comprensión y maestría que le llevase a convertirse en un líder o supervisor realmente útil, pero ese tiempo pasó, y en el presente todo está tan interconectado y especializado que el pasar por una serie de áreas solo da una visión parcial del todo y a menudo superficial. Quizá la cultura del ascenso no tenga que desaparecer del todo para mejorar las cosas, quizá se pueda reciclar parcialmente para que aquellos que quieren especializarse o cambiar de rol a algo que les llene más según maduran y crecen como personas y profesionales, pero en su forma actual, esta cultura es mala como la hipertensión o las grasas hidrogenadas. 


PS: Aprovecho para recomendar el libro Rework de Jason Fried, relacionado con este tipo de pensamientos, que empecé a leer después de escribir este post, y cuyas ideas y principios comparto en un 99%, no tanto por idealismo, sino por haber visto con mis propios ojos que lo que dice no solo es cierto, sino que funciona.

*La foto está extraída de Wikimedia.

Toma de decisiones y desarrollo de software

Probablemente una de las cosas que más agota mentalmente a una persona sea tomar decisiones: recabar datos, modelar escenarios, simular, probar, imaginar, buscar, resposabilizarse, convencer... En informática esto se traduce en un agotamiento mental, que se nota al terminar una jornada, cuando has tenido que decidir cosas como:
Qué framework, tecnología y lenguaje usar, como distribuir lógicamente el código, como organizar el trabajo en equipo, como llamar a las páginas/clases/tablas/campos/variables/funciones, como almacenar los datos, como escribir cada estructura de decisión (if/while/switch/for y cual de todas usar), como organizar el interfaz, que colores poner, cual será el flujo del programa a nivel de usuario/interno, que tipo de seguridad se implementa, que pruebas realizar, como se tratan los errores, qué es un error y que no, qué navegador usar, qué tipos de datos toca en cada momento, qué partes optimizar, qué nivel de abtracción es suficiente, cuando se hacen según qué tareas (y cuales son estas), qué tiempo llevará cada hito de proyecto, qué recursos deberían usarse, qué versiones de los estándares se implementan (CSS/HTML/SQL/VB/JS...) y a qué nivel (por compatibilidad)... en fin, los afectados sabrán de que hablo. No olvidemos que cada decisión de este tipo, debe casar perfectamente con las anteriores, todo es vinculante en el código.

El desarrollo de software es, por su propia naturaleza, una tarea altamente creativa, no porque sea más cool que otras disciplinas, sino porque poco o nada puede llevarse a cabo de manera automática o mecánica (a nivel mental), dado que la principal característica de la informática es... automatizar procesos repetitivos. Y esta característica precisamente hace que cuando alguien se ha enfrentado a un problema y lo haya resuelto, puede aplicarse la solución de nuevo o adaptarla a nuevos casos (abstrayendo y reutilizando siempre que se conozca la solución, o te tocará resolver el problema de nuevo). Al final esta característica provoca que no se pueda hacer siempre lo mismo como desarrollador. Es irónico. Nunca se pueden resolver problemas típicos, porque estos ya se han resuelto. Los problemas a resolver son siempre nuevos.

Probablemente todo esto que cuento, es una de las ventajas en informática y una de las quejas comunes. Ventaja porque solo es necesario resolver los problemas una vez, y eso permite avanzar a toda máquina en cuestión de meses o años (al menos globalmente, con nuevas aplicaciones, plataformas y servicios). Queja porque siempre hay que estar aprendiendo, pensando y probando, nunca puedes “apalancarte” y muchos acaban quemados o abandonando lo que parece una carrera de ratas. Al final los que quedan, son probablemente los que más y mejores soluciones conocen (por mera experiencia) y eso debería hacerlos valiosos por encima de modas. Pero eso es otra historia.

Libro: El sueño del neandertal

Título: El sueño del neandertal. Por qué se extinguieron los neandertales y nosotros no.
Autor: Clive Finlayson
Editorial: Crítica

La razón por la que este libro acabó en mis manos es múltiple. Por un lado, desde hace al menos una década tengo gran interés en la evolución y la antropología, y desde que leí Homínidos y sus continuaciones, y posteriormente aprendí algo sobre los últimos descubrimientos en Atapuerca (Excálibur, la sima de los huesos...), tengo algo más de interés en los neandertales en particular.

Por otro lado y con mucho más peso, tengo la sensación de que existen semejanzas y relaciones importantes entre la Evolución (con mayúsculas) y el desarrollo de software... pero también con el mundo empresarial. Pero ese es tema para otro post. Sigamos con el libro.

Finlayson, tras sus excavaciones en Gibraltar, en la cueva de Gorham, y después de haber recopilado y analizado exhaustivamente datos de toda la península Ibérica, expone en este libro razones suficientes para mantener una tesis sobre la extinción de nuestros ancestros: neandertales, homo erectus, heidelbergensis...

Según su exposición la clave se haya en el clima, y de manera muy convincente expone la historia pormenorizada pero detallada de como los cambios geológicos y climáticos a escalas de miles de años presionaron a los humanos (considerando a nuestros ancestros como tales) para evolucionar, especializarse, y extinguirse cuando su hábitat dejó de existir. Habla de como el clima fue dando forma y podando poco a poco, nuestro árbol evolutivo.

Este libro propone que nuestros ancestros no eran menos inteligentes que nosotros, o al menos no tanto como para justificar su extinción. También trata de combatir la idea de que Homo Sapiens exterminase a sus ancestros, señalando numerosos datos en contra de esa teoría colonialista. Nos cuenta como vivían, qué comían, y como trataban de adaptarse cada uno de nuestros parientes a un mundo de clima, fauna y vegetación cambiantes. Y finalmente nos recuerda que el periodo climático en el que estamos, al que nos hemos adaptado, no es la norma, sino una excepción, y que no puede durar para siempre. 

Yo diría que si te gusta seguir la pista al estado del arte en antropología y saber algo más de cómo demonios hemos llegado hasta aquí, y qué podemos esperar del futuro, entonces este es tu libro.

Pero también quiero recordar que la principal idea con la que cogí este libro, fue la buscar similitudes entre la crisis actual, y la crisis que extinguió a nuestros parientes, para tratar de obtener alguna ideas de como sobrevivir a un hábitat económico y laboral cambiante, y creo que ese objetivo también se ha cumplido admirablemente. 

A continuación, algunos fragmentos de libro (particularmente el epílogo), por si alguien quiere picarse antes de leerlo.

Es con los agricultores donde vemos el gran cambio en densidad de población y en estructura social. Al ocurrir como lo hizo, después de que el clima se estabilizara, la expansión demográfica y geográfica de los agricultores tuvo mucho más que ver con la nueva tecnología que con un cambio en el ambiente. Señaló el inicio de la ilusión del progreso hacia un mundo de crecimiento insostenible, un sueño que hoy se ha transformado en pesadilla, al tiempo que seguimos postergando la solución mientras el estado actual y el futuro de nuestro planeta pende de la balanza como resultado de nuestra voracidad. ¿Cómo pudimos haber llegado a un estado de cosas tan malsano? La respuesta reside en la manera como hemos llegado hasta el presente, no como superestrellas de la evolución, sino como plagas que invadieron todos los rincones y rendijas posibles.

[...]

Nacimos de los pobres y débiles que tenían que gastar cada gramo de energía buscando las sobras que los mantuvieran vivos.

[...]

Estos supersupervivientes podían resolver mejor el riesgo de un suministro impredecible de comida o agua que cualesquiera otros de su especie, de modo que cuando el clima cambió e hizo que todas las cosas empeoraran, fueron ellos y sus descendientes los que salieron mejor parados. La forma más temprana de gestión del riesgo parece haber implicado vivir en el borde de dos o más hábitats o de un mosaico de hábitats. Una vez lejos de la zona de confort del bosque, estos innovadores funcionaban mejor si permanecían en lugares en los que había varios tipos de hábitats cerca, y ello les permitía explorar una variedad más amplia de alimentos que si hubieran vivido en un único hábitat [como los especialistas adaptados a un solo hábitat].

[...]

Parece que la conciencia del yo sería una consecuencia natural de la conciencia de los objetos en el espacio y en el tiempo, incluyendo a otros miembros de la propia especie. Una vez adquirida [...] como efecto secundario de desarrollar un efecto grande y complejo, la conciencia de uno mismos se añadió a nuestros sistemas complejos e intrincados de transferencia de información y de comunicación. Produjo un animal capaz de situarse en el espacio y el tiempo, un animal que se hizo consciente de las consecuencias de su propio comportamiento y mortalidad. [...] Pero al mismo tiempo, permitió comportamientos maquiavélicos conscientes y manipulación.

[...]

La cultura y la tecnología nos ofrecieron la gran oportunidad de reaccionar al cambio climático y ambiental mucho más rápidamente de lo que podían hacer nuestros genes. Cambiamos de rumbo, modificamos y cambiamos el ambiente y nuestros alimentos, nos hicimos cada vez más independientes de dicho ambiente y produjimos cada vez más descendientes. Durante un tiempo funcionó: el mundo era tan grande y nosotros éramos tan pocos que caímos bajo el hechizo de nuestros propios logros. Todo parecía sostenible (los recursos disponibles no tenían fin) y seguimos adelante. Pero a las escalas de tiempo que nos interesan, 10.000 años es una simple gota en el océano. A medida que la población del planeta ha aumentado, nos hemos dado cuenta de forma creciente de que este proyecto concreto sólo es sostenible a estas escalas de tiempo cortas, y que un día todo se vendrá abajo. Hemos visto colapsos espectaculares de civilizaciones aparentemente inexpugnables en la historia registrada, pero nada comparable a lo que nos espera. Y cuando todo se venga abajo, ¿quién sobrevivirá? En nuestro relato hay suficientes indicaciones para sugerir que no seremos aquellos de nosotros que vivimos en la zona de confort [primer mundo], los esclavos autodomesticados de la electricidad, los automóviles y el ciberespacio, que no duraremos más que unos pocos días sin la tecnología de soporte.

[...]

Los innovadores ganarán una vez más cuando la perturbación rápida y poderosa que será el colapso económico y social, generado por los conservadores mismos, señale irónicamente su propia ruina. Y la evolución dará otro paso en alguna dirección todavía desconocida.

Interrupciones y ruido en el desarrollo de software

Al hilo del resumen que encontré sobre Peopleware, y dándole vueltas a como mejorar mi flujo mental, me he puesto a pensar en que a lo largo de mi carrera, he tenido la interesante desgracia de encontrarme trabajando en diversos entornos ruidosos y con una gran cantidad de interrupciones. De todos ellos, creo que ha habido tres que han sido especialmente representativos en cuanto a lo que suponen para el desarrollo de software, tanto el ruido como las interrupciones.
De estos tres casos, una vez enfriados a base de tiempo para un análisis mínimamente objetivo, puedo decir que tenían, en mi opinión, las siguientes características:

1. El primer caso lo experimenté trabajando en un entorno con más ruido de conversaciones y teléfonos del deseable, pero relativamente amortiguado con algunos metros de distancia. Muy pocas interrupciones, y muy informales.
2. En segundo caso, el entorno era muy ruidoso, con montones de conversaciones al lado, y varias decenas de interrupciones diarias tanto in situ como de correo. Un caso bastante extremo, la verdad.
3. En el tercer caso, el entorno no era más ruidoso que cualquier otro en el que haya estado, pero había muchísimas interrupciones in situ. Telefónicas y de correo sin embargo, había muy rara vez.

En todas las ocasiones, tuve que realizar trabajo de análisis, diseño e implementación de las aplicaciones que tocaban en cada momento y en todos los casos hice un análisis de mi estancia, inmediatamente tras cambiar de empleo, como de costumbre, para tratar de aprender de errores propios y ajenos (una pseudo tarea de cierre y evaluación del proyecto que casi nadie lleva a cabo por lo que veo). Así que este artículo se centra exclusivamente en la relación entre ruido, interrupciones y desarrollo de aplicaciones.
Y una vez comentado el contexto creo que puedo pasar a exponer las siguientes opiniones que me he formado a base de estas y otras experiencias:

1. El trabajo de análisis y diseño admite mejor el ruido que la implementación. En mi caso puedo, por ejemplo, realizar documentación o establecer la arquitectura de una solución, con un nivel medio de ruido. Sin embargo para programar necesito muy poco ruido y/o cascos (como manera de aislarme), o la tarea se ve muy mermada en eficacia.

1. El análisis y diseño admiten interrupciones en ventanas de tiempo [x] relativamente pequeñas, quizá de media hora. Estas interrupciones merman estas tareas, pero no hasta un punto excesivo que eche por tierra horas de trabajo. En cambio la programación (la que se haga bien, no parchear algún desastre) muchas veces requiere de un par de horas como poco sin prestar atención a nada más o puedes irte directamente al bar y la productividad habrá sido similar pero con algo más de alegría.

Supongo que otras personas habrán tenido experiencias similares o diferentes, pero estas son las que tengo de primera mano, así que tengo pocas razones para discutirlas. Por otro lado, el por qué el ruido y las interrupciones afectan de determinada manera a mi trabajo, merecen al menos un intento de explicación. Y aquí es donde van mis dos céntimos.

Creo que la razón de esta diferencia entre las necesidades de concentración de una y otra tarea, se debe a que las tareas de análisis y diseño, son tareas de alto nivel, abstracciones (por definición incompletas), a menudo incorrectas y/o, ambiguas (un poco al hilo de las leaky abstractions de Joel Spolsky), tareas además más “naturales” en el sentido de que no requieren de un marcado ciclo de trabajo tan formal (ojo, no digo que no sea formal pero hay un trecho) y dependiente de la tecnología (IDE/compilador, base de datos, flujos de trabajo con sistemas de control de versiones…) como la implementación en código y bases de datos. Por tanto las tareas de diseño y análisis son más flexibles para con los ciclos de abandono y retomado propio de las interrupciones. Yo diría (en un sentido positivo aunque no lo parezca) que el análisis y el diseño de los sistemas informáticos, especialmente en cuanto a software, son tareas incompletas y erróneas por definición, y como otros trabajos de diseño, se sustentan muy bien sobre el papel.
Sin embargo, en la implementación, cuando el programador recoge las especificaciones y diseños del analista (uno mismo en caso de que el analista y el programador sean la misma persona), y se pone a codificar, se acaba encontrando con todas las omisiones, ambigüedades y errores que han pasado por el tamiz de los diferentes roles y hasta sus manos: desde el cliente, pasando por la toma de requisitos, análisis funcional y orgánico y cualquier otra fase que queramos meter en medio. Y es entonces cuando todo ese trabajo que no se ha realizado antes, todo lo que se ha olvidado, omitido conscientemente, tergiversado… cualquier decisión que no se ha tomado, se atasca en la implementación, que necesita convertir toda la documentación, en un producto funcional y mantenible en el tiempo, y debe hacerse sin errores, porque la implementación no perdona, y si no “cae” en el compilador, lo hará en tiempo de ejcución en el entorno de preproducción, o peor aún, en producción.

Parafraseando a Richard Feynman: "Para lograr un éxito tecnológico, la realidad debe estar por encima de las relaciones públicas, de los diseños, análisis y requisitos tomados, porque la problemática que resuelve el sistema, los usuarios que lo van a usar, el compilador, la base de datos y el entorno de producción no pueden ser engañados.".


La necesidad de hacer algo sólido, sin errores, ni omisiones, desde lo que es la documentación incompleta (como decíamos, por definición), obliga al desarrollador a mantener un modelo mental del sistema muy detallado, mucho más que en las etapas anteriores, y esto cuesta mucho más “cerebro” (atención, modelos mentales detallados, datos, simulaciones, peculiaridades del entorno…) que en el caso del análisis (que puede abstraerse del entorno como poco). Supongo que por eso cualquier cosa que robe “cerebro” o lo ralentice, como las interrupciones o el ruido, son tan perjudiciales en esta etapa de implementación. Y quizá por eso también los técnicos tienden (tendemos) a dejar de ver el bosque en muchas ocasiones, de tanto árbol que tiene, con las consiguientes quejas (con razón o sin ella) de usuarios y comerciales.

Y ojo, esto no es una crítica al indispensable trabajo de análisis y diseño (que me parece crítico para poder llevar a cabo el proyecto con éxito), ya que en mi caso hablo de mi propia experiencia en los diversos roles, sino una reflexión sobre la posible necesidad de mantener a los programadores en entornos más tranquilos y relajados que los de los analistas. Es una invitación a incentivar el uso de cascos (quizá proporcionándoles unos con reducción activa de ruido), quizá ropa cómoda, pero sobretodo a dejarlos en paz durante periodos largos del día, aislándolos de interrupciones y distracciones indeseadas. Y también es una invitación a establecer relaciones estrechas y de confianza (laboralmente al menos), entre los miembros de análisis y desarrollo, ya que su productividad como equipo debería mejorar con un lenguaje común, conocimiento de los talentos y limitaciones de cada uno, buenas costumbres y manías. Al fin y al cabo no son dos recursos intercambiables como les gusta pensar a demasiados responsables de proyectos y departamentos de RRHH, sino dos tipos de diseñadores creativos (o deberían serlo) que van a realizar una obra común de carácter muy técnico. Son dos creadores (ahora que está de moda la palabra con la Ley Sinde) que van a colaborar (en el sentido de Pixar), y es por ello que más vale que se entiendan bien y sepan donde ceder ambos el lápiz y el papel o la decisión para obtener algo coherente, porque de no ser así, el resultado puede ser catastrófico.

Vídeo relacionado: Jason Fried 2010 en TED o Youtube.

Foto de Wiki Commons.

NOTA: Este artículo empecé a escribirlo hace 10 meses, pero diversas circunstancias lo han mantenido en un cajón durante largo tiempo.

David contra Goliat y NoSQL

Hace algún tiempo leí por separado dos artículos que parecían tener poco en común: David beats Goliath y No to SQL.

En el primero, se hablaba de una serie de historias interesantes, donde el desconocimiento de las reglas implícitas en ciertas áreas permitía a ciertos individuos (es decir, novatos sin experiencia) desarrollar soluciones mejores que las de los expertos en el campo. De esta manera un entrenador con un equipo de baloncesto femenino clasificado como malo (en técnica y altura) conseguía aplastar a contrincantes más experimentados una y otra vez durante unos campeonatos tomando como principio básico un juego agresivo y de pura fuerza bruta (resistencia y tenacidad) pero sin ninguna técnica o habilidad adicionales, en vez de intentar ganar jugando con mejor técnica a rivales superiores. Algo parecido al caso del concurso de batallas navales simuladas que ganaba un ordenador con estrategias nada común como hundir sus propios barcos para ganar velocidad o dejarlos completamente desprotegidos para centrarse en la potencia de fuego. Es decir, este primer artículo hablaba de la ventaja que representa determinada ignorancia a la hora de resolver problemas tenidos por irresolubles.

El segundo artículo, habla de una iniciativa denominada NoSQL que aboga por no usar sistemas gestores de bases de datos (SGBD) relacionales. Como muchos sabréis un SGBD relacional, es una base de datos corriente y moliente (SQL Server, Oracle, MySQL…) que en la informática actual es algo considerado indispensable para tratar con volúmenes medios y grandes de información, es decir, están en todas partes. La gente de NoSQL decidió que quizá un SGBD relacional, no es algo tan indispensable al fin y al cabo, y se han dedicado a implementar de manera independiente sistemas masivos de almacenamiento de información no basados en bases de datos relacionales ni en el tradicional SQL. Con ello han conseguido (como pretendían) no solo tratar volúmenes de información muy difíciles para las bases de datos más potentes, sino hacerlo de una manera más barata. Todo un logro cuyo exponente más famoso sea probablemente Facebook con Cassandra una empresa bien conocida por tratar con una brutalidad de datos impensable hace tan solo unos años.

Y es releyendo por accidente el segundo artículo debido a tema relacionado en el trabajo cuando he recordado a Gerd Gigerenzer en Inteligencia Intuitiva y el caso de los comportamientos y respuestas automáticos inconscientes y el caso del fiasco de Accenture en la Bolsa de Londres por valor de 40 millones de libras y he pensado dos cosas:

La primera es que actualmente quizá el mayor error de un informático y que nunca nadie menciona es dar por hecho algo. La informática es algo MUY complejo y volátil por mucho que algunos se empeñen en no reciclarse y hacer las cosas "como siempre", y existen problemas inherentes como las abstracciones con fugas a nivel técnico o los wicked problems a nivel de proyecto, cuya única solución efectiva es “no jugar” que diría la computadora de Juegos de Guerra ("a strange game. The only winning move is not to play").
Mi segundo pensamiento ha sido que hay espacio para innovar en muchos campos. “Mucho espacio al fondo” citando a Feynman. Y para darse un paseo por ese espacio solo es necesario hacer algo que siempre nos recomiendan los teóricos y que a la vez suelen tratar de impedir muchos jefes de proyecto (como extensión del cliente) así como muchos clientes en su búsqueda de lo barato y rápido. Es necesario pensar mucho y bien (usando la razón y no la memoria para lanzar respuestas automáticas) antes de ponerse manos a la obra con casi cualquier cosa, hasta lo más básico.

Toda esta cháchara no tiene por objeto revolucionar, ni aleccionar, ni siquiera generar visitas o mantener vivo el blog sino simplemente recordarme un par de cosas que ya había comentado informalmente a nivel laboral, pero nunca por escrito:

1. No des nada por sentado. Las respuestas de memoria pueden no ser fiables en un campo (o mundo) que avanza cada semana y que trata proyectos a medida. Esta regla la solía enunciar como una pregunta sin segundas intenciones en mi antiguo grupo de desarrollo: ¿lo crees o lo sabes?
2. Dedica más tiempo a pensar, que a programar. Y piensa con cuidado. Son ya muchos años y desarrollos a las espaldas como para que piense que poner a la gente a aporrear el teclado a toda máquina va a servir para corregir una mala gestión del proyecto o un análisis deficiente. Si esos dos elementos (gestión y análisis) fallan, aporrear teclados solo sirve para empeorar el producto final.

PD: La imágen del cerebro ha sido tomada de Wikimedia Commons

Película: Startup.com

Título: Startup.com
Año: 2001
Tipo: Documental
Idioma: Inglés (EEUU) subtitulado al español.

Curiosa película. Narra en forma de documental, la creación de una empresa de Internet en los Estados Unidos antes de la crisis de las puntocom en el 2000 y su caída tras esta.

En los créditos finales (posible spoiler, pero es un documental, así que…) dan alguna información que supongo que dará una mejor idea del “argumento”, cito una parte a modo de epitafio de la empresa:

govWorks
Mayo 1999 – Diciembre 2000

Reunió fondos por valor de 60 millones de dólares.
45 ciudades internacionales contrataron sus servicios.

Ganaron el contrato de las multas de aparcamiento de Nueva York

En resumen se trata de un buen relato de la historia de una puntocom típica, con dos socios fundadores, Kaleil y Tom y se parece en muchos puntos (socios, desarrollo, problemas…), a una empresa en la que trabajé hace unos años y que siempre recordaré con cariño como la empresa en la que más aprendí sobre el trabajo, la tecnología, y el estrés, por qué no decirlo.
Esta película bien podría ser de visionado obligatorio para cualquier interesado en montar una empresa de software o trabajar en una joven startup de terceros, ya que se aprende mucho más de los errores que de los aciertos, pero si los errores son ajenos, mejor.

PD: Para saber más sobre errores en proyectos de software y empresas, recomiendo totalmente leer el artículo de Coding Horror: The only truly failed project.

Prejuicios, actualización y software

El otro día, hablando con mi jefe, salió a colación el tema de las bases de datos útiles para "cosas serias". El opinaba, desde su pasado de administrador de Oracle, que Oracle era lo más, y que MySql entre otros no te permitían construir un sistema "de hombres". Yo no estaba de acuerdo, y gracias a la web de los chicos de HighScalaility, pude demostrar con hechos que MySql es un producto a la altura de Oracle para cosas gordas, quizá mucho mejor desde un punto de vista técnico si no se dispone de dinero infinito.

La arquitectura de Youtube fue el ejemplo más evidente, aunque hay otras.

Todo esto, me llevó a reflexionar sobre lo poco de fiar que puede llegar a ser la opinión de alguien, aunque haya tenido experiencia, cuando pasan uno, dos o N años desde esta, y también me hizo pensar en la necesidad de pensar en sistemas claros y abstracción en capas, antes que en sistemas optimizados (otro tema candente en la oficina) o herramientas milagrosas. Ya lo decía (entre otras cosas) el admirado y venerable Donald Knuth en 1974:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Como lectura complementaria a todo esto, me gustó mucho el artículo de Joel Spolsky: Leaky Abstractions, donde Joel reflexiona sobre el curioso efecto que tiene la cada vez mayor cantidad de capas de abstracción existentes en el desarrollo de software y la utilidad de conocer las entrañas de los sistemas. Cito una de las frases finales de tan recomendable artículo porque me llegó adentro:

"the abstractions we've created over the years do allow us to deal with new orders of complexity in software development that we didn't have to deal with ten or fifteen years ago, like GUI programming and network programming. And while these great tools, like modern OO forms-based languages, let us get a lot of work done incredibly quickly, suddenly one day we need to figure out a problem where the abstraction leaked, and it takes 2 weeks."

Herramientas para elegir colores web

Hoy, de nuevo me he vuelto a topar (tangencialmente) con la vieja historia a la hora de crear un sitio web, de tener que elegir los colores para el interfaz de la aplicación. Así que esta entrada en bitácora va para todos aquellos que alguna vez se han topado con esta problemática y que han tenido que lidiar con diferentes gustos y juicios, daltonismo (no yo, gracias a dios) y otras hierbas... y ya de paso me evito tener que buscar las herramientas de nuevo.

Bueno aquí van mis dos centavos en aplicaciones web para generar esquemas de colores compatibles:

1.- WellStyled. Mi primera elección, probada hace meses, pequeña pero matona.
2.- Yafla. Mucho más bonita que la anterior y quizá más cómoda que la anterior, la descubrí hoy mismo.

En cualquier caso hay otras opciones fácilmente localizables mediante Google ("combinar colores web" funciona bastante bien).

El móvil como mando a distancia del PC/Mac

Mi actual teléfono Sony Ericsson K800i tiene un apartado dentro de su software de serie titulado Control Remoto. Se trata de un software que permite usar el propio terminal como mando a distancia para ordenadores (Mac Os inclusive), de manera que podamos controlar diversas opciones (cursor, clicks y algunas teclas o conjuntos de teclas) sin usar ratón o teclado y sin cable alguno.
Como descubrí poco después de usarlo por primera vez, se trata de una característica poco conocida llamada HID (Human Interface Device) que soportan los dispositivos con Bluetooth a partir de su especificación 1.2 (el K800i soporta la 2.0) y que permite usar los típicos teclados para móvil o hacer cosas como usar el terminal como dispositivo de control del ordenador.

El caso es que los desarrolladores de Sony Ericsson, tienen a disposición de cualquiera una aplicación llamada Bluetooth Remote Control para generar nuestros propios perfiles de mando personalizado, con lo que ya tengo un mando para el reproductor de video VLC, otro para el reproductor de música Winamp otro para las presentaciones de Power Point (muy útil en reuniones y cursos) y uno más para leer comics de Tom Strong con mejor visor de comics, el CDisplay. Este último programa tiene peculiar historia de que lo conocí de un profesor durante unas clases de integración de sistemas. Supongo que en este mundillo todos somos algo frikis.

Imagino que en Symbian y Windows Mobile tendrán algo similar, pero desgraciadamente no ni soy fan de Nokia desde cierto episodio con un proyecto que requería terminales que cumpliesen las especificaciones WAP, ni fan de Windows Mobile (soy pro Palm), así que escribo esta entrada solo para dar a conocer un poco más las posibilidades de uso de los "simples" teléfonos móviles en un mundo cada vez más bluetoothizado.

Adjunto un par de capturas de la aplicación, simple y funcional como ella sola, para quien quiera hacerse una idea.

Yahoo! Go para tu móvil, mejor que Google

Hoy he tenido la oportunidad de probar lo último para móviles de Yahoo: Yahoo! Go.
Se trata ni más ni menos que de una aplicación Java para teléfonos móviles que hasta donde he probado, integra los siguientes servicios de Yahoo:

1.- Buscador.
2.- Calendario/Agenda.
3.- Agenda de contactos.
4.- Mapas (con las habituales vistas aéreas, búsqueda de calles y negocios, rutas, y tráfico).
5.- Correo de Yahoo.
6.- Lector de Noticias/Feeds en varias categorías: noticias o suscripciones propias, deportes, entretenimiento y finanzas.
7.- El tiempo (clima) de tu ciudad.
8.- Flickr.

Ya había probado las páginas (para web y correo) específicas para navegador móvil de Yahoo/Flickr, Google y MSN/Hotmail, además de las aplicaciones de Google para móvil (Google Mapsy Gmail) y he de reconocer que esta vez Yahoo ha conseguido hacerlo, no mejor, sino mucho mejor que Google.

La idea de agrupar todo eso en una aplicación que en mi Sony Ericsson K800i es ligera como el viento ha sido realmente buena, pero además los mapas de Yahoo han resultado funcionar mejor, con mayor exactitud que los de Google Maps.
Si a eso sumamos que la usabilidad del Gmail móvil es similar a la del correo de Yahoo en esta aplicación y encima la aplicación de Yahoo ocupa 2'5 Megas frente a los 3'5 Megas de Gmail + GMaps, resulta que tenemos no un competidor sino un ganador por goleada.

Y la verdad es que es un lujo poder aunar todo eso en un terminal como el K800i que tiene una pantalla grande y con una luminosidad y contraste buenísimos, pero sumando las tarifas de datos tan baratas de Yoigo y su cobertura 3G la verdad es que no podría estar más encantado.

Buenas noticias para todos aquellos conspiranóicos hartos de la hegemonía de Google, pero buenas noticias sobre todo para los usuarios de teléfonos móviles que usen conexiones de datos.

Por otra parte, comentar un par de cosas más:
- Al recibir correo el teléfono suena y vibra.
- Al cerrar la aplicación, esta nos informa de la cantidad de datos transmitidos para que nos hagamos nuestras cuentas (con Yoigo nos da igual).
- La versión actual disponible en español es la 2.0, pero en la 3.0 parece que Es posible instalar Widgets para aumentar la funcionalidad de la aplicación.

Envio de SMS por Navidad.

Como gran parte, por no decir casi toda, la población española, he enviado los típicos y tan benneficiosos para las compañias de telefonía (130 millones de mensajes de texto dicen que hemos enviado), SMS de felicitación.
Este año he limitado el envío solo a fin de año, por si acaso alguno de mis contactos no le gusta celebrar la navidad.

Independientemente del mensaje, este año he innovado, incorporando elementos que han automatizado la tarea, haciendo menos tedioso el envio de estos SMS.

Para ello he utilizado el Nokia PC Suite, un software gratuito de Nokia que permite gestionar la información que tenemos en nuestro movil.



Para comunicarme con el movil, he utilizado Bluetooth, con un pendrive usb Bluetooth en el PC y el propio módulo de Bluetooth del Teléfono Movil (Nokia 6125).



Nokia PC Suite permite ver los SMS que tenemos en el movil y además crear nuevos mensajes desde el PC, con las ventajas que para escribir el texto conlleva el disponer de un teclado completo.
Además, el proceso de añadir destinatarios a un mensaje es tan facil como seleccionarlos directamente desde la lista de contactos almacenados en el movil.

Además algunas de sus características incluyen:

Transferencia automática y segura de datos entre el teléfono y el PC
Admite la Conexión inalámbrica o por cable
Conexión a Internet rápida y sencilla
Gestión de archivos almacenados en el movil
Ver las fotos o videos grabados
Sincronizar la agenda de Windows con la agenda del movil
Instalar aplicaciones
Realizar copias de seguridad de la información del movil
etc...

En resumen, una herramienta muy cómoda para gestionar la información almacenada en nuestro movil.

Aplicación Gratis: EverNote Portable

Solo durante el día de hoy (27 de Diciembre del 2007) en el sitio web "Give Away of the Day" , teneis disponible una muy buena aplicación para la toma de notas, recortes de código, imágenes, etc...

Se trata de Evernote Portable, una fantástica herramienta con un aspecto visual curioso y muy cuidado.



Además, dispone de la posibilidad de utilizar "tinta", es decir, contempla la posibilidad de escribir notas a mano alzada desde un Tablet PC o un UMPC.

También recordar que esta versión (Portable) se puede instalar en un Pen Drive o memoria externa para poder llevar todas nuestras notas con nosotros a cualquier ordenador con windows que utilicemos.

GTD y la planificación de tareas (I). El sistema.

Hace ya algunos meses que cambié de trabajo.
Sigo haciendo lo mismo (programar), pero con la ventaja de que en el actual puesto me permiten trabajar desde casa.

Si bien, esto es el sueño de mucha gente, debo reconocer que se está fantásticamente bien en casa ;-), hay que tener cuidado de que no nos invada la pereza y nos de por hacer las típicas cosas que todos tenemos pendientes en casa y nunca hacemos.

Existen muchos métodos para organizarse, quizás el más conocido sea el GTD (Getting Things Done de David Allen), que es un método de gestión de actividades, además de ser el nombre del libro de David Allen en el que se explica el método para lograrlo.

GTD se basa en el principio de que una persona necesita borrar de su mente todas las tareas que tiene pendientes guardándolas en un lugar específico. De este modo, se libera a la mente del trabajo de recordar todo lo que necesita hacer, y permitiéndole concentrarse en la realización de aquellas tareas.

Para conseguir esto, no se especifican prioridades como en otros sistemas, sino que las tareas se agrupan en contextos: casa, oficina, correos por enviar, llamadas pendientes, etc...
Según en el contexto en el que nos encontremos, debemos realizar las tareas asociadas a dicho contexto.

También implementa la norma de que toda tarea que pueda ser realizada en menos de 2 minutos, debe ser hecha inmediatamente.

Según Allen, lo más práctico para llevar a cabo nuestros trabajos es reflexionar previamente sobre ellos, generando una serie de acciones que hacer más tarde sin necesidad de volver a planificar durante su realización.

Personalmente el sistema GTD me parece un sistema bastante lógico de como se deben hacer las cosas. Si bien no lo sigo al pie de la letra, me gusta basarme en él para crear un sistema propio de gestión de tareas y documentación para mi trabajo.

La principal herramienta que utilizo, es un software que se llama Tiddly Wiki que comentaré en el siguiente post (no quiere que el artículo se alargue mucho :-D ) .

Aplicación gratis para PDA Palm OS en Handango

Hoy, la gente de Handango.com celebra lo que llaman los Free App Friday.
Esto es, regalan una aplicación para dispositivos móviles.
Las semanas pasadas les tocó a los Pocket PC, pero esta vez toca Palm y un programa que recomiendo. Se llama Snap.



Snap permite desde una única ventana introducir elementos en varias aplicaciones.
Concretamente estas aplicaciones son Agenda, Libreta de Direcciones, Tareas, Bloc de Notas (memos) y Aplicación de Correo (Versamail).

La potencia que tiene, desde mi punto de vista, es que no hace falta cambiar de aplicación cuando vas a introducir un elemento, y tampoco hace falta saber si vas a apuntar una cita, un teléfono, una nota o un email.
A mi me viene de maravilla cuando estoy hablando con alguien y me va a dar algún dato, que no se si voy a tener que introducirlo en mi agenda, mi libreta de direcciones o prefiero enviarme un mail a la cuenta de correo del ordenador de sobremesa para anotarlo posteriormente.

En resumen, una buena aplicación que durante el día de hoy es gratuita.