La Naturaleza Del Software

Forma y Función

2013-05-12T10:29:00-04:00

It is the pervading law of all things organic and inorganic, of
all things physical and metaphysical,of all things human and all things superhuman —of all true manifestations of the head, of the heart, of the soul— that the life is recognizable in its expression, that form ever follows function. This is the law.
Louis Sullivan The Tall Office Building Artistically Considered

Para el arquitecto Louis Sullivan, admirador de los pensadores racionalistas norteamericanos como Thoreau, Emerson, Whitman y Melville, existía un sólo credo estético, con una regla simple “que no permite excepciones”, la “forma siempre sigue a la función”.

Sullivan desarrolló el concepto de rascacielos con estructura de acero en el Chicago de fines del siglo XIX. Las fuerzas de la economía y la tecnología convergían en ese momento y había que diseñar algo nuevo, fuera de los antiguos patrones escritos en viejos libros de arquitectura. Para Sullivan si algo tenía que determinar la forma, esto sería el propósito del edificio. La propuesta de Sullivan es que la “forma sigue la función, versus el anterior credo de que “la forma sigue al precedente”. Hasta ese tiempo, la arquitectura se basaba en el principio de que la arquitectura debía re utilizar las grandes formas de la antigüedad.

Esto llevó a los arquitectos a buscar estilos arquitectónicos que no fueran influenciados por la historia. La idea era expresar la verdadera forma del edificio siguiendo un estricto apego a su funcionalidad. Al grado de llegar a rechazar todo ornamento arquitectónico, reflejado en el ensayo de Adolf Loos: “ornamento y crimen”.

Estos conceptos, llevaron al surgimiento de los movimientos modernistas en arquitectura.

Loos proclamaba que la evolución de la cultura, el progreso, busca la eliminación del ornamento en los objetos útiles. El ornamento provoca que los objetos pierdan estilo, y por lo tanto se vuelven obsoletos. Por esto que perder esfuerzo en el ornamento de un objeto es un crimen, pues llevará al objeto a su obsolescencia. Los objetos útiles deben ser simples, sin ornamentos, es la finalidad de esta propuesta.

Es muy interesante estudiar las discusiones y propuestas del diseño y la arquitectura de fines del siglo XIX y principios del siglo XX, porque pueden ser ilustrativas para el desarrollo de la arquitectura de software en particular.

Aunque he sostenido que desarrollar software no es construir software, en el sentido de que no se deben aplicar directamente las analogías de construcción de edificios con el desarrollo de sistemas, es innegable que el software requiere de un diseño previo.

Veamos que pasa si adoptamos una definición de arquitectura de software acorde con estos conceptos de forma y función. Definamos por ahora que de lo que trata la arquitectura de software es del estudio de la forma y función de un sistema.

Forma, es lo que el sistema es, función es lo que el sistema hace. ¿Pero cómo lo hace? Cuando tratamos de entender cómo el sistema hace lo que debe hacer, es que entramos a discutir sobre la estructura. La estructura es el soporte a la forma, y la forma, como nos recuerda Sullivan, sigue a la función.

Si les pido diseñar una silla, la forma está dada inmediatamente por la función, que es permitir descansar el cuerpo de cierta forma precia. No se puede hacer una silla totalmente vertical, pues queremos mantener a la persona en cierta posición específica. Sin embargo, es relevante preguntarse cómo esta silla sostendrá el peso, de que materiales debe estar construida, cuáles son las fuerzas a la que se verán sometidos los materiales, cual deberá ser la duración, cuanta gente podrá usar potencialmente la silla, por cuanto tiempo, etc.

Lo mismo pasaría con un sistema informático. La función es lo primero que debemos definir: Qué hace el sistema, a qué responde, para qué lo hacemos. De esto sale la forma, y definida la forma debemos desarrollar la mejor estructura que lo soporte.

Veamos las consecuencias de esto con un ejemplo práctico:

Queremos desarrollar un sistema que permita a las personas indicar donde están y qué están haciendo en cada momento. Para esto los usuarios ingresarán su “Estado”, que corresponde a un mensaje breve que indica qué está haciendo en cada momento relevante. La idea es que otros puedan saber donde está y que está haciendo, pues es útil para coordinar las tareas de un equipo. Para indicar su estado las personas no necesariamente deberán tener acceso a un computador. Esa es la función.

Para cumplir esta función, permitiremos que los usuarios envíen sus mensajes de estado a un sitio central, y permitiremos que cualquiera pueda observar una linea de tiempo con los estados de cada uno de los participantes del sistema. Las personas que usen este sistema podrán elegir a quienes seguir, y podrán saber quienes les siguen. Esta es la forma.

Y acá viene la discusión interesante de la arquitectura. Como queremos acceso desde cualquier parte, permitiremos que los mensajes sean enviados vía SMS, esto produce una limitación al mensaje de estado, que para ser compatible con todos los sistemas de mensajería por celular de la época, implica que el estado estará limitado a 140 caracteres.

Usaremos un sitio web para consultar la linea de tiempo de los demás participantes, y para elaborar nuestras listas de usuarios que nos interesa seguir, junto con consultar el estado de nuestros seguidores.

Con todo esto, podemos construir este sitio usando Ruby On Rails, en poco tiempo, y podemos disponibilizarlo en la web. Lo llamaremos Twitter.

Acá viene la diferencia fundamental con la arquitectura tradicional, esa que se encuentra limitada por la fuerza de la gravedad. Porque Twitter empieza a popularizarse, y empieza a ser usado para más que la función inicial. Decimos que Twitter, el sistema, evoluciona, y requiere adaptarse a los nuevos requerimientos, que surgen dinámicamente, porque el software permite una mayor maleabilidad.

Hoy Twitter es una herramienta que cumple funciones diferentes a las soñadas por sus creadores. Su arquitectura actual no es la misma que la que tenía cuando inició. Seguramente en este momento hay una gran preocupación en el equipo sobre la seguridad de las cuentas de twitter, ya hemos visto como la apropiación indebida de una cuenta en twitter provocó una caída en la bolsa del índice Dow Jones. La arquitectura debe hacerse cargo de esos aspectos también.

Lo que empezó con Ruby On Rails y MySQL, ahora es una combinación de muchos frameworks, lenguajes (ruby, scala y java principalmente) y de bases de datos (relacionales y NoSQL). Soportando plataformas móviles y toda clase de clientes y soportando miles de aplicaciones que aprovechan su API.

Decimos que la arquitectura de Twitter ha evolucionado, y efectivamente de eso se trata, de evolución permanente, es la gran diferencia que la arquitectura de software presenta frente a la arquitectura tradicional.

Así que nuestra definición de arquitectura debe cambiar. La arquitectura de software tiene que ver con la forma y la función de los sistemas, y con la evolución de los mismos. Es por eso que decimos que desarrollamos software y no que lo construimos, para dar cuenta de la naturaleza dinámica de nuestras arquitecturas.

Definir El Problema

2013-04-28T11:06:00-04:00

“La arquitectura es un producto de una actividad llamada diseño, y no hay diseño sin un _problema_. La definición de un problema es una declaración explícita y escrita de un problema: la brecha entre el estado actual y el estado deseado”
James O. Coplien Lean Architecture: For Agile Software Development

Me gusta esta definición de problema: “la brecha entre el estad actual y el estado deseado”. Lo que hacemos al resolver un problema es cambiar una situación, normalmente molesta. O satisfacer una necesidad.

Por esto que es importante saber y definir adecuadamente cuál es el problema. Si lo entendemos como acortar una brecha es más fácil llegar a enunciar y entender el problema. Veamos, a modo de ejemplo, este diálogo con unos desarrolladores, tomado del libro de Coplien que citamos arriba:

–¿Cuál es el problema que están resolviendo?
–Estamos tratando de llegar a ser más orientados al objeto.
–No, esa es una solución al problema, no un problema. ¿Cuál problema están resolviendo?
–Oh, estamos usando la orientación a objetos para obtener una mejor reutilización.
–No, reutilización es en si misma una solución a un problema. ¿Cuál problema están resolviendo?
–Bien, el último proyecto fue demasiado costoso, y estamo tratando de reducir nuestros costos.
–¿Cuantas alternativas han considerado?
–Bueno, ninguna. Todos los demás están usando objetos, así que decidimos tomar un camino de bajo riesgo.
James O. Coplien Lean Architecture: For Agile Software Development

De seguro que podrán identificar alguna organización en la que han trabajado. Es un síntoma clásico de la poca claridad del propósito de la labor de ingeniería de software.

Se trata de una falta de reflexión sobre el sentido, la orientación del trabajo. En algunos casos toma la forma de la Ley de Prodan: “No se lo que quiero, pero ¡lo quiero ya!”.

Yo digo que ahí falla la dirección, la que define la visión inicial, y los objetivos subordinados a esa visión. Recordemos lo dicho sobre Dirección, Organización y Método, cuando planteamos una visión debemos definir el resultado, el plazo u oportunidad y los parámetros de calidad.

Antes de empezar a resolver un problema y de incluso definir estos tres elementos, debemos tener claro qué queremos resolver, pero sobre todo para qué. Eso es lo que llamamos propósito. Una buena definición del problema permite aclarar ese propósito.

Muchos problemas surgen de la conversación del día a día. Me pasó recientemente, una aplicación entregaba feedback sobre errores, pero no con el suficiente detalle para que el usuario pudiera realizar la correcciones. Estamos trabajando en la implementación de una lista de nuevos requerimientos, pero en esta lista no estaba considerado el hecho de que se necesitaba un mejor detalle al entregar los errores. Ese problema sólo surgió de la interacción durante unas pruebas. Fue mediante esa interacción que pudimos levantar un nuevo requerimiento.

Este caso es la típica situación en que se revela que hay una diferencia entre lo que el usuario pide y lo que el usuario espera. Y eso se descubre mediante la identificación de la brecha entre la situación actual y la deseada, eso es una expectativa. Lo malo, y de ahí viene el arte, es que las expectativas no siempre son enunciadas, porque en la mayoría de los casos es difícil expresarlas en palabras. Esta situación es la que produce uno de los hechos más frecuentes en la vida de los proyectos: “el requerimiento emergente”. Y digo hecho, no problema. Hay personas que consideran al “requerimiento emergente” como un problema, no lo es, el problema es creer que uno debe tener todos los requerimientos claros antes de comenzar. “Espera lo inesperado” debería ser la consigna de un buen administrador de proyectos. En la literatura ágil se habla de que lo que pasa es que vamos descubriendo nuevos problemas en el camino, no es eso, lo que pasa que el acto de diseñar en realidad crea nuevos problemas, es más en muchos casos el diseño cambia la propia naturaleza del problema. Por eso que debemos revisitar nuestra definición del problema siempre.

Una buena definición del problema es vital, nos ayuda a enfocarnos, y por supuesto, a guiar nuestra labor de gestión del proyecto. Pero ¿cómo lograr una buena definición? Acá viene la mala noticia para nuestros amigos ingenieros del tipo aspergueriano: “la mejor manera de definir un problema es conversando”.

Equipo

A mi jefe le gusta la definición de que un equipo es un “conjunto de conversaciones recurrentes”, y los que resuelven el problema son los miembros del equipo. ¿Quiénes son los miembros del equipo? Los clientes, los usuarios, los desarrolladores, los ingenieros de sistemas, etc. Pensar que el equipo sólo lo componen los desarrolladores es uno de los mayores errores que se puede cometer. Todos deben estar involucrados en la solución del problema. Otra vez, algunos verán que esto de conversar es una pérdida de tiempo, pero en realidad es tiempo bien invertido.

La propiedad del problema

Una cosa importante antes de continuar, es necesario identificar la propiedad del problema. Este concepto tan simple es normalmente mal abordado y lleva a problemas en la ejecución del problema. Lo importante, es que cualquiera sea la respuesta a la pregunta “¿quién es el dueño del problema?” debe siempre considerar y respetar a las personas con el poder de resolver el problema.

“Es frecuente en la vida que una persona formula el problema y lo delega a otra para que lo resuelva. Le pides a tu secretaria que se deshaga del vendedor. Tu jefe te pide que recortes tu presupuesto en un 15%. Un cliente te pide que arregles un bug. Mientras estas situaciones persistan en el mundo, es mejor si la persona que tiene (o los que tienen) el problema sean los que escriban la definición del problema. De otro modo, la declaración del problema se convierte en una manera de que una persona ejerza poder sobre otra, y eso restringe la auto organización y retroalimentación que permite la agilidad.”[1]

El dueño del problema es el que debe definirlo, y por definirlo hablamos de “escribirlo en una declaración explícita”. Pero debemos guiarlo en la conversación previa, para que no llegue a confundir la solución con el problema.

Es frecuente que recibamos un “requerimiento para arreglar algo”, que se origina en algún punto de la cadena de poder de la organización. Lo que podemos hacer es re escribir ese “requerimiento para arreglar algo” como una buena definición del problema y proponérselo al solicitante, a modo de retroalimentación. Esta re escritura del problema debe ayudar a definir los criterios de solución (deben ser medibles), de este modo el problema no se nos vuelve una trampa que lleva a la falla.

La Capacidad para Resolver

Tenemos claro quién o quienes son los dueños del problema, y respetamos el rol de los que son capaces de resolverlo, porque hemos delegado la resolución del problema a otra parte del equipo. Los usuarios definen el problema, porque son los dueños del mismo. Los desarrolladores son los que resuelven el problema porque tienen la capacidad y han sido empoderados para hacerlo. El equipo de operaciones (sistemas) es el que se preocupa que la solución esté disponible siempre que se la necesite. Cada rol es valioso, y por esto que es importante mantener la conversación viva entre todos los integrantes del equipo, siempre, y desde el principio.

Definir el Problema

Entonces, ¿cómo definir bien el problema?

Hay varias técnicas, una puede ser los 5 Por qué de Toyoda, que es muy usada para encontrar la causa raíz de un problema.

Otra técnica es responder las 7 preguntas básicas: ¿Quién?, ¿Qué?, ¿Cuándo?, ¿Dónde?, ¿Por qué?, ¿Cómo? y ¿Cuantos?.

Hay muchas técnicas más, todas implican conversar, de una forma más o menos estructurada. Lo importante es no eludir esa conversación.

En todo este proceso de definición del problema debemos aplicar tres de las cuatro actividades básicas de la labor del ingeniero: escuchar, entender, solucionar y comunicar. Sobre las que habláramos más adelante.

Finalmente, el resultado de todas esas conversaciones deben ser plasmadas en la definición del problema, escrita por el dueño del mismo. Cuando tenemos esta definición del problema, podemos dedicarnos a resolver con tranquilidad, y cuando hayan dudas, o veamos que nos estamos desviando del objetivo, debemos volver a esta definición, siempre. Es nuestra guía, nuestra brújula que impedirá que nos perdamos.

Notas [1] Las citas están tomadas del libro Lean Architecture: for Agile Software Development, de James O. Coplien y Gertrud Bjornvig

Expectativas

2013-03-23T10:20:00-04:00

“You‘ve got to start with the customer experience and work back toward the technology - not the other way around.”
Steve Jobs WWDC 1997

Casos de Uso, les cuento lo que pensaba una amiga de los casos de uso. “Esha” es argentina, ¿viste? En una ocasión me contó un típico diálogo con uno de sus programadores: “¡Che! y le pregunto que cómo era posible que una factura tuviera fecha de vencimiento menor a la fecha de emisión, y ¿sabés que me contesta el boludo? ¡Que esa situación no estaba contemplada en el caso de uso! ¡¿Sabés que podés hacer con tus casos de uso?! le contesté…”

:-) Suele suceder, con bastante frecuencia en realidad, hasta yo mismo en alguna ocasión he usado ese argumento, si no está en el caso de uso, entonces no tiene por que estar implementado, ¿verdad?

Pues no es así, y ese es el gran problema con la toma de requerimientos. Siempre partimos de la base de preguntarle al usuario qué quiere, que desea que le “construyamos”. Cuando en realidad deberíamos tratar de comprender que es lo que espera del sistema.

¿Cómo es eso? ¿No son los requerimientos lo que espera el usuario del sistema? ¿Y no se refleja eso en los casos de uso?

¿Qué quieren los usuarios?

You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.
Steve Jobs “An Interview With Steven Jobs, Inc.’s Entrepreneur of the Decade, Abril 1989”

Algo de razón tenía Steve Jobs cuando dijo que cuando le preguntas a tus clientes que quieres y tratas de dárselos, en el momento que lo hayas construido ya quieren algo nuevo. Es una rueda sin fin en la que nos involucramos desarrolladores y usuarios, nunca parecen alinearse las expectativas con los resultados. ¿Qué es lo que falla entonces? ¿Cómo solucionarlo?

Bruce: Eran tantos. Sólo les di lo que querían.

Dios: Sí. Pero, ¿desde cuando alguien tiene idea de lo que realmente quiere?
          -- Jim Carrey y Morgan Freeman en Todopoderoso

El enfoque tradicional, la aproximación al desarrollo en cascada, recoge los requerimientos y trata de plasmarlos a través de una cadena de actividades meticulosamente detallada y documentada: Toma de Requerimientos - Análisis Funcional - Análisis No Funcional - Diseño General - Diseño de Detalle - Diseño de Arquitectura - Programación - Diseño de Pruebas - Pruebas Unitarias - Pruebas de Integración - Pruebas de Aceptación de Usuario - Correcciones - Paso a Producción.

Cuando al fin logramos de pasar a producción ya nadie quiere el sistema, y a veces termina siendo descartado. Con el tiempo se convoca un nuevo proyecto, o entramos en un eterno ciclo de “mantenciones”.

La respuesta ágil

Ante esta situación la respuesta del movimiento ágil es privilegiar las interacciones entre los individuos, por sobre los procesos y las herramientas.

La propuesta ágil es agnóstica a la tecnología, no es relevante, lo que importa es satisfacer el requerimiento. La idea es la siguiente: el usuario no tiene claro que desea, nosotros tampoco, así que descubrámoslo en el hacer. Construyamos una funcionalidad, e iteremos. La cascada desaparece, aparece un molino de agua: recoger funcionalidades, priorizarlas e iterar, mejoras sucesivas hasta que descubramos juntos lo que se necesita.

Lo que importa en el manifiesto ágil es el hacer: “Working Software”. Pero ahí parten los problemas, esta solución privilegia el “Working Software”(software funcionando), pero no habla del “Usable Software” (software útil).

El agilismo es esencialmente reactivo. Propone colaboración con el cliente, “responder al cambio por sobre seguir un plan”. Construimos software, el usuario lo prueba, no es lo que esperaba, iteramos nuevamente….

No es que esté en contra del movimiento ágil, pero después de años de intentar adherirme a sus principios, y observando los resultados obtenidos, creo que le falta algo. Llevo tiempo reflexionado al respecto y creo que he visto algunas de las falencias de esta aproximación, y algo de eso es lo que intento explorar en este texto.

Requerimientos vs Expectativas

Si se fijan todas la metodologías tienen que ver con cómo plasmar los requerimientos del cliente en un producto. En términos simples, todo se trata de elaborar una lista de lo que tenemos que hacer y después hacerlo. El orden, la forma en que nos aproximamos es la que varía, ya sea que ejecutemos las tareas en forma secuencial una tras otra, de forma iterativa incremental, o de forma reactiva, como se propone en las formas más extremas de agilismo.

Lo que yo digo es que el problema no está tanto en la forma, sino en el fondo. El problema es que todas esta metodologías tratan sobre el manejo de los requerimientos, cuando en realidad deberían preocuparse del manejo de las expectativas.

¿Cómo es eso?

Una expectativa no es un deseo casual, es algo tácito que va más allá de los supuestos conscientes, es algo que reside parcialmente en el inconsciente del usuario.

“Muchos usuarios pueden expresar lo que quieren, algunos pueden justificar sus necesidades, y cuando usan tu producto todos pueden decirte si este hace lo que ellos esperaban”[1]

En muchos proyectos se elaboran listas de funcionalidad potenciales, elegidas y motivadas por la visión de negocios de que es lo que el cliente está dispuesto a pagar (o sea, lo que el cliente quiere). Esta descripción por si misma no nos dice mucho sobre cómo serán usadas estas funciones, o por qué se usarán.

Una lección que aprendieron los autores del libro Lean Architecture fue la siguiente:

“Aprendimos una lección sobre las expectativas de los usuarios a partir de un cliente nuestro. El cliente construye sistemas de análisis de ruido para todo tipo de artefactos, desde automóviles hasta aspiradoras. Algo que aprendimos que sus clientes productores de aspiradoras insistían en que una buena aspiradora hace un ruido sustancial cuando está trabajando a tope. Para el mercado alemán este ruido debe ser un rugido grave, para otros mercados un chillido agudo. La meta no es minimizar el ruido, a pesar de que es posible construir aspiradoras bastante silenciosas sin reducir su efectividad.

Anticipación

Uno de los problemas con la toma de requerimientos es que no es posible anticipar todos los escenarios que pueda concebir un usuario. Así que debemos profundizar en la percepción del usuario sobre la forma del sistema. Esto se conoce como el modelo cognitivo del usuario final.

“Los casos de uso capturan las interacciones con el sistema que los usuarios finales pueden anticipar. Si los usuarios finales pueden anticipar todas las interacciones para todos los valores posibles de entrada, entonces la especificación es completa. Esto hace que construir el programa sea innecesario porque hemos delineado toda posible respuesta a partir de toda posible entrada, y bastaría con revisar la respuesta en las especificaciones en vez de ejecutar el programa. Por supuesto, esto es absurdo. Los buenos sistemas de software tienen valor porque pueden, hasta cierto grado, manejar lo no anticipado.”[1]

Supongamos que nos piden construir un procesador de textos. Un requerimiento sería poder mover una tabla dentro del documento. Veamos posibles escenarios o casos de uso posibles: mover la tabla de una página a otra; mover la tabla justo entre dos párrafos ya existentes; o mover la tabla dentro de otra tabla. Las posibilidades son interminables. ¿Cómo abordamos eso con el enfoque tradicional de casos de uso?

En vez de eso, es mejor orientar nuestros esfuerzos a definir algo más importante: el modelo cognitivo del usuario final. Los usuarios tienen modelos en su cabeza de los detalles internos del programa que utilizan. Confían que el programa “sabe” qué es una tabla, un párrafo, una figura, etc. El usuario confía en que los programadores han prestado atención a la necesidad de que haya un espacio en blanco entre la tabla y los párrafos adyacentes. Estos elementos del modelo mental del usuario final, aunque sean estáticos, son útiles para poder razonar sobre los posibles escenarios que modelamos en los casos de uso.

En el caso que les relaté al principio, el de mi amiga y sus sistema de facturación, la falla está en que el requerimiento no capturó adecuadamente el modelo mental del usuario, “en una factura la fecha de vencimiento no puede ser menor a la fecha de emisión”, esto es algo evidente, pero por eso mismo es muy raro que vaya a surgir de una toma de requerimiento, es algo que suponemos que el desarrollador domina, o que al menos ha investigado.

Este modelo cognitivo debe capturarse dentro de la arquitectura de la solución. Si lo capturamos bien, podemos garantizar que podremos satisfacer lo que el usuario quiere y necesita, pero de paso haremos nuestra solución más resiliente cuando nos pidan implementar un escenario razonable pero no anticipado.

Problemas y Soluciones

Jerry Weinberg define problema como “la diferencia entre el estado actual y un estado deseado”. Así que cuando vamos a enfrentar un desafío de programación (sea una simple rutina, o un sistema completo), debemos empezar por aclarar la noción de qué queremos resolver. Teniendo clara esta noción sabremos que significa que algo esté listo (done).

“Sin una definición del problema, es difícil saber cuando has terminado. Claro, puedes señalar una lista de tareas que has completado y que fueron diseñadas inicialmente para acortar la brecha entre el estado actual y el estado deseado, pero eso no significa que hayas terminado. Los requerimientos emergentes provocan que el paisaje se desplace durante el desarrollo, y aún así los caminos mejor planeados no te llevan a los destinos mejor concebidos.” [1]

A esto lo llamamos visión. La visión es la brújula que nos guía. ¿Por qué estamos haciendo lo que estamos haciendo? Esa es la pregunta esencial que debe hacerse el buen ingeniero.

La visión también ayuda a entender mejor las expectativas del usuario.

Recientemente leí este tweet:

Insumir mucho tiempo pensando como soportar una carga grande de usuarios sin siquiera haber lanzado el producto, es una pérdida de tiempo.
@ideasagiles twitter.com/ideasagiles/status/…

¿Qué significa esto a la luz de lo que estamos discutiendo? Sin tener claro cuál es la visión, puede tener mayor o menor sentido. Claramente pesa la visión del hacer y reaccionar del agilismo. Que está bien, después de todo lo importante es salir con el producto. Pero, ¿y si el cliente, esperaba que el sistema soportara una carga grande de usuarios desde el principio?

El modelo ágil tradicional (Scrum, por ejemplo) privilegia el “hacer y reaccionar”. Hay otra manera de abordarlo (Lean), que privilegia el pensar y luego hacer.

Ese es el modelo que es mejor, en mi opinión. Pero sin llegar al extremo de pensar demasiado y no hacer nada. Pasar 3 meses diseñando un sistema no lleva a ninguna parte.

Eso es algo que debemos recuperar, y que parece haberse perdido en el agilismo. Pensar, luego hacer, por sobre el hacer y reaccionar. Software útil (usable software) más que software funcionando (working software).

Prácticas Perdidas

Muchos al abordar metodologías ágiles piensan que se trata de botar todo lo “desagradable”, cosas como arquitectura, documentación, análisis funcional, deben quedar fuera. Como si se tratara de traer un Scrum Master o algo similar que toque el tambor, y poner a usuarios y desarrolladores a iterar juntos hasta sacar algo mínimamente aceptable. Después de todo, se trata de “individuos e interacciones por sobre procesos y herramientas”.

El agilismo tiene la virtud de ser probablemente el primer movimiento en el desarrollo de software que introdujo un conjunto maduro de disciplinas. Lamentablemente, en el camino mucha experiencia ganada, que no estaba en este conjunto de disciplinas se fue perdiendo, o la fuimos considerando como irrelevante, y no lo son.

Hay que recuperar esas prácticas perdidas. ¿Cuáles prácticas? me preguntarán, bueno, de eso vamos a hablar en los próximos posts ;-)

Notas

[1] Lean Architecture, for Agile Software Development, James Coplien & Gertrud Bjornvig.

¡No somos cocineros!

2013-03-08T20:14:00-03:00

Este post es largo, quiero decir laaaaargo, porque tiene ambición, y pretende decir muchas cosas importantes. Como dice el Chef Antoine de New Orleans (citado por Fred Brooks en The Mythical Man Month):

“La buena cocina toma tiempo. Si le hacemos esperar, es para servirle mejor, y complacerle”

Si yo fuera ustedes me buscaría un buen sofá, un momento de tranquilidad para leer esto, que en algunos momentos se puede poner bastante denso, pero creo que vale la pena. Al menos decidí tomarme el tiempo adecuado para escribirlo, con calma, con reflexión, como se debe hacer cuando las cosas que hacemos consideramos que son importantes.

Comunidad

“El hombre aislado no desarrolla ningún poder intelectual. Es necesario que él esté inmerso en un ambiente… Podría quizás hacer un poco de investigación por si mismo y lograr algunos pocos descubrimientos… la búsqueda de nuevas técnicas debe ser vista como algo realizado por la comunidad humana en su totalidad, más que por individuos.” – Alan Turing

Yo escribo este blog para aprender. La preparación de un post me puede tomar mucho tiempo en algunos casos. Me tomo el tiempo porque me gusta aprender.

Cuando investigo encuentro cosas interesantes, descubro relaciones que no sospechaba, la apertura de mente que esto produce es notable. Si me pidieran un consejo sobre cómo mejorar , ya sea profesionalmente, o en la vida sería: “escribe un blog, pero escríbelo bien”, es decir, investiga, preocúpate de que lo que digas es veraz, y que esté bien argumentado. Preocúpate primero de lo esencial, que el tema sea interesante, e investígalo con la mayor profundidad que puedas dedicarle. También considera cuidadosamente lo accidental, como la ortografía y la redacción, en eso debo reconocer que tengo fallos, pero creo que la solución se da en el tiempo.

Sólo practicando un arte se puede llegar a dominarlo, incluso en los detalles accidentales.

Hace unos meses decidí que mis textos quedarían en un repositorio GitHub, de modo que cualquiera pueda clonarlos y ayudarme a mejorar la calidad de mis post. Por ejemplo, uno de mis lectores más antiguos, Javier Novoa (@jstitch), de México, encontró un fallo en uno de mis artículos, y gentilmente decidió usar esta herramienta para ofrecerme la corrección, mediante lo que se conoce como un Pull Request. Finalmente el error lo descubrí y corregí en paralelo, pero fue la primera vez en que se plasmó la iniciativa, la intención que yo buscaba al publicar mis textos en GitHub, que ustedes me ayuden a corregir su contenido. Este blog es opensource, lo que significa que ustedes me pueden ayudar a mejorarlo y a enriquecerlo.

Algo tan personal, e individual como escribir un blog se enriquece con la comunidad, uno no escribe para si mismo, sino que para que los otros lo lean. Pero el blog tiene la ventaja que permite el debate, los comentarios, y la interacción con otros autores. Cuando el cuadrito para comentar se hace corto, tienes que recurrir a tu propio espacio y escribir tu propio post respondiendo al otro. Al menos es lo que hago yo en muchos casos.

Pero me parece que he dado un paso más, porque ahora además de comentar, ustedes pueden ayudar directamente a mejorar la calidad de este blog.

La Naturaleza del Software

La razón por la que ahora puedo “enriquecer” aún más el contenido de este blog, con la ayuda de ustedes, es porque, después de todo, estas palabras que escribo son software.

En una oportunidad por twitter alguien me comentó que ahora podría remezclar mis textos y llevarlos a audio, usando tecnología text-to-speech, y quien sabe, en un acto de creatividad máxima se podría hasta musicalizar. ¡Eso sería notable!

Esa es la infinita plasticidad del software, uno de sus atributos que lo hace tan fascinante, una de las creaciones más importantes del ingenio humano.

El software es más que código. Si no se ha entendido eso, entonces se produce una limitación muy importante. Hay muchas personas que producen software sin ser conscientes de eso. El software ha permeado nuestras vidas cotidianas sin darnos cuenta. Parece invisible, está dado. Nadie reflexiona mucho sobre la naturaleza del software que corre en sus móviles, o tablets. Esa es la gracia, y la desgracia al mismo tiempo. Es ese impacto profundo que hemos logrado en las vidas de las personas, esa transformación silenciosa, que es tan maravillosa y aterradora a la vez.

¿Qué es el software?

“¿Qué es el software? ¿Por qué profesionales y científicos clásicos, para qué decir los “humanistas”, aprecian/usan/usufructuan del software pero desprecian la actividad y sus profesionales? Argumentaré que se debe a que el software es primo hermano de la cocina. Y esta gente lo intuye. La cocina es una actividad cuyos productos son apreciados como pocos, pero cuya actividad y quienes la desarrollan parecieran pertenecer a la oscura trastienda de lo socialmente superfluo.”

El texto citado fue publicado hace pocos días en el blog del Departamento de Ciencias de la Computación de la Universidad de Chile, bajo el título El Goce Del Puro Hacer y escrito por Claudio Gutierrez académico de ese departamento.

En ese artículo desarrolla un argumento que trataré de resumir en los próximos párrafos.

Motivado por la lectura del Gorgias de Platón, el autor pretende explicar por qué la “intelectualidad clásica” usufructa del software, pero desprecia esta actividad y a sus profesionales.

La hipótesis escogida es que “el software es primo hermano de la cocina”, y dado que, tal como se muestra en el diálogo de Platón, el cocinar siempre ha sido menospreciado por los filósofos, entonces el software es despreciado de la misma manera.

Es decir, el software es como la cocina, y lo que buscamos de la cocina es placer (adulación). Pero hay adulación positiva, la realización de los deseos, y adulación negativa que corresponde a la manipulación de los deseos.

Los programadores, de acuerdo a Gutierrez, lo que hacen es satisfacer los deseos de los usuarios mediante el software. A esto, el autor lo llama la “adulación del hacer”. Dado que autores tan prestigiosos como Fred Brooks o Ivar Jacobson han fracasado en definir la naturaleza del software, entonces nos quedamos con que esta consiste en la “adulación del hacer”.

Y esto constituye una doble falta a los ojos de la tradición, porque: “Primero, al desarrollador de software no le importan las causas, la naturaleza. No se ocupa del “bien”, sino de lo que desea el usuario. Por ello no constituye un arte; es adulación. Segundo, lo adulado por el software, el hacer, al contrario del cuerpo o del alma, es algo que nunca ha sido bien mirado.”

¿Por qué no es bien mirado? Porque todos quieren obtener placer sin hacer nada. Eso es lo que se le ofrece a las nuevas generaciones. Y luego viene el epílogo que a mi personalmente me deja con una sensación extraña:

Terminemos: ¿sería posible un mundo sin software? Por supuesto. Y sería un mundo más tranquilo, con haceres pausados y rústicos. La gente no moriría de hambre ni de frío… pero sí de aburrimiento. No habría nadie que nos adule en el hacer, que satisfaga el insaciable placer del hacer.

Vamos a tratar de aclarar todo lo anterior, porque me parece que ya se ha vuelto bastante confuso.

Filosofía y Cocina

“Tengo siempre la costumbre, cuando alguien habla, de prestarle mi atención, especialmente cuando el que habla me parece sabio, y en mi deseo de comprender lo que dice, averiguo, reexamino, comparo lo que se dice, a fin de aprender. Si el que habla me parece de poco valer, ni insisto en mis preguntas ni me intereso por lo que dice. En esto reconocerás a los que yo considero sabios; encontrarás que soy insistente sobre lo que dicen y que interrogo para aprender y sacar provecho.”
– Sócrates en el Diálogo de Platón “Hipias Menor”

El primer problema es que no tenemos claro que es lo que el autor entiende por software. De lo que se puede entender del texto creo entender de que está hablando de la programación, más que del software en sí. Y ahí creo que parte la confusión del argumento.

El otro problema, radica en la tesis que se nos presenta, que parece una petición de principios. La tesis, recordemos, es que la intelectualidad clásica usufructa del software pero desprecia esta actividad.

En esencia el argumento va más a o menos así.

La intelectualidad clásica desprecia el software.
El software es como la cocina, porque es una adulación, no un arte.
La intelectualidad clásica se place en la adulación (como cualquiera), pero sin embargo la desprecia.
Luego la intelectualidad clásica desprecia el software.

La demostración se sostiene en la premisa de que el software es adulación del hacer, y esta consiste en que el software se hace para satisfacer los deseos del usuario.

Pero esa definición más parece un truco retórico (petición de principios) y por esto creo que se cae el argumento (es notable el hecho de que el Gorgias sea el diálogo sobre la retórica, y que en uno de sus pasajes lo que trata de probar Sócrates es que la retórica no es más que un truco, algo menor, no un arte y por lo tanto sea menos valiosa).

¿Y qué hay de malo con esa definición? Porque si ésta se sostiene, aunque haya algún problema lógico formal con la exposición, el argumento central puede salvarse.

El problema del cocinero

Me gusta la cocina, y mucho. No me considero un cocinero, apenas me aparezco por la cocina, es la verdad, pero de repente tomo mi wok y preparo algo salteado, o alguna ensalada.

Del cocinar lo que me más me gusta es la experimentación, la mezcla de sabores. Efectivamente cocinar es una actividad placentera, y sorprender a los comensales es la gran recompensa, y por lo tanto lo que buscamos al cocinar es adular, tal como dice Sócrates en el Gorgias.

Por otro lado las analogías de la programación y la cocina surgen de manera natural. Ya les conté en otra ocasión como cocinar te da una visión especial de lo que significa abordar la comprensión y programación de un algoritmo.

Y con todo eso, no puedo decir que mi profesión sea similar, o parecida a cocinar, al menos no si la entendemos como simplemente adular al usuario.

Podríamos discutir si la cocina más que una adulación, y al contrario un verdadero arte. Al menos, en muchos aspectos parece serlo, y un chef seguro que defendería ese punto.

Cuando la cocina va más allá de la simple técnica, y es mucho más que mezclar ingredientes, hace algo más que complacer al usuario en su requerimiento, y es el arte del Chef el sorprendernos, no olvidemos eso. (Les recomiendo leer mi reflexión sobre la película Ratatouille donde elaboro un poco más este punto, y refuerzo mi idea de que en realidad el programar es más parecido a hacer cine que a cocinar).

Entonces, sólo si la cocina va más allá de complacer al usuario, podríamos empezar a aceptar la comparación. Pero tratemos de aclarar estos términos.

Dinning Philophers

Hay un famoso problema en computación conocido como el problema de la cena de los filósofos, planteado por Edsger Dijkstra para representar el problema de sincronización de procesos en los sistemas operativos. Vease Wikipedia

Ese problemas nos permite recordar la vieja máxima que para filosofar primero hay que tener la barriga llena. La filosofía requiere que ciertas necesidades básicas estén cubiertas, si hasta Ciorán y los filósofos estoicos tenían resuelto ese problema, se sabe que Diógenes, el más pobre de los filósofos, tenía resuelto el problema con lentejas, y ¡pucha que son ricas las lentejas! Lo que me sugiere que este puede ser un buen momento para preparse algún bocadillo antes de continuar ;-).

Así que sólo si hemos resuelto el problema básico de comer, nos dedicamos a filosofar. Puede ser que por esa razón a los filósofos no les ha interesado dedicarle mucho tiempo al problema de cocinar. Para ellos eso es una cosa resuelta, ¿para que dedicarle más vueltas?

Pero la verdad es otra. Sucede que mi hermano es filósofo y vivimos juntos en un pequeño departamento durante nuestra época de universidad. Así que mientras él estudiaba, yo estaba expuesto a estos textos. Fue ahí donde desarrollé mi gusto por los Diálogos de Platón, y el Gorgias es un texto importante. Gorgias es el diálogo sobre la retórica (que notable coincidencia). Es uno de los textos maduros de Platón, donde plantea sus ideas, usando la voz de Sócrates, sobre la política y la justicia, tema que profundizará en su famosa obra magna La República.

Hay un apartado del Gorgias que habla sobre la naturaleza de la retórica, y si esta tiene que ver con la justicia y la política. En un momento del diálogo la discusión se centra en determinar si la retórica es un arte como afirma Gorgias. Sócrates niega esta posibilidad, y argumenta que la retórica no es un arte como la considera Gorgias, sino que una práctica, un truco, algo menor, “adulación” (y acá vienen los problemas de las traducciones). Para sostener este punto, Sócrates usa varias analogías, una de las más famosas es la de comparar la cocina con la medicina.

Es importante también entender que los griegos consideraban la frugalidad una virtud, de hecho encontraban decadentes a los persas, sus eternos enemigos, por su lujo y exhuberancia gastronómica. Ser chef no era buen negocio en la Grecia de Platón.

Aunque es un ejercicio un tanto ocioso, yo sostengo lo contrario que dice Gutierrez, que si Platón viviera en este tiempo tendría que llegar necesariamente a la conclusión que el software es el producto de un arte, no una adulación, si es que su pensamiento es coherente con lo que expone en el Gorgias. Allí está el Gorgias para que puedan sacar ustedes sus propias conclusiones.

Pero para aclarar mi punto voy a citar a Donald Knuth que lo expone bastante bien en su hermoso discurso sobre el arte de la programación.

Si vamos a las raíces latinas, encontramos ars, artis que significan “habilidad”. Quizás es significativo que la palabra griega correspondiente era τεχνη, la raíz de “tecnología” y “técnica”. *(Esta es la palabra usada por Platón en el Gorgias, nota de E.D.)
En nuestros días cuando alguien habla de “arte” probablemente piense primero en las “finas artes” tales como la pintura y la escultura, pero antes del siglo veinte la palabra era usada generalmente en un sentido bastante diferente.
En los tiempos medievales, las primeras universidades fueron establecidas para enseñar las, así llamadas, “siete artes liberales” a saber, gramática, retórica, lógica, aritmética, geometría, música y astronomía. Noten que esto es bastante diferente de los currículos de los colegios de artes liberales, y que al menos tres de las siete artes liberales son componentes importantes de la ciencia de la computación. En aquel tiempo, un “arte” denotaba a algo ideado por el intelecto humano, en oposición a las actividades derivadas de la naturaleza o el instinto; las artes “liberales” eran liberadas o libres, en contraste a las artes manuales tales como arar. Durante la edad media la palabra “arte” por si misma usualmente significaba lógica, la que usualmente denotaba el estudio de los silogismos.

Tal como nos dice Knuth, hace rato que los filósofos clásicos definen el arte como el producto del intelecto humano, comer es algo que viene del instinto, y por lo tanto el cocinar por ser una actividad vinculada o originada de una necesidad primaria, no puede ser considerada arte en el sentido clásico del término.

Por lo mismo, no puede ser considerado el software algo menos que el arte, ¡por la misma razón que expone Gutierrez en el último párrafo de su artículo! Porque precisamente puede concebirse un mundo sin programación, porque la programación surge como una actividad propia del intelecto humano, más allá de las necesidades básicas o naturales. La programación está más allá de la simple adulación o satisfacción del placer. No es adulación en el hacer. El desafío intelectual nace de la necesidad de resolver un problema mayor, tal como en la concepción platónica la política nace del problema de buscar la justicia y la verdad, la programación, y por ende el software, nacen de una necesidad mayor aún, la de resolver un problema.

Y acá es preciso que agregue más palabras del discurso de Knuth:

La Ciencia es conocimiento que entendemos tan bien que se lo podemos enseñar a un computador, y si no podemos entender algo completamente, es un arte tratar con él. Dado que la noción de un algoritmo o programa de computador nos provee de una prueba extremadamente útil de la profundidad de nuestro conocimiento sobre un asunto dado, el proceso de ir desde un arte a una ciencia significa que aprendemos cómo automatizar algo.

Así que no puedo aceptar que la programación es adulación en el hacer, pues es más que eso, es un arte en el sentido clásico del término, y al ser un objeto cuya raíz es el intelecto humano no puede ser comparado con el cocinar, que nace de cubrir una actividad humana básica. En el sentido clásico, el programar sería un arte liberal.

Bondad, Belleza y Verdad

El programador desarrolla un software que hace lo que el usuario quiere. No existe un programa “bueno”, “verdadero”, “bello”, absoluto. Un buen software satisface deseos en el mundo del hacer. Nada más. Muchas veces estos se confunden con los chatos deseos de los empresarios: eficiencia, velocidad, economía. – Claudio Gutierrez, Op. Cit.

Hay en el fragmento que acabo de citar muchas consecuencias que me preocupan. Es sabido desde antiguo que no se puede cargar de virtudes propias del ser humano a las cosas, o a los animales. Un cuchillo no es culpable de un asesinato. Es el uso que hacemos de ellas y sus virtudes estéticas las que nos hacen apreciarlas en mayor o menor medida. Decimos, este cuchillo es bueno si cumple adecuadamente su función. Por lo mismo, decimos que un un programa (no un software) es útil, o bueno. La belleza del mismo es un atributo que dependerá del observador.

Una aplicación puede ser útil, y bella a la vez. Esa belleza puede ser apreciada a distintos niveles y por distintas personas. Para un usuario la belleza puede estar en la interfaz, en la fluidez y diseño de las interacciones. Si la aplicación responde adecuadamente, resuelve el problema, pero además es agradable de ver, será apreciada.

Pero un técnico puede apreciar la belleza de una aplicación a otros niveles. En su arquitectura, el grado de acoplamiento, la elegancia en el diseño de las APIs. Incluso se puede apreciar en el estilo de programación. Cómo diría Dijkstra, “La Belleza es Nuestro Negocio”

El ingeniero apreciará la eficiencia, velocidad y economía de recursos. Yo recuerdo que cuando estudié ingeniería nos hacían apreciar estos tres aspectos, y no porque sean “chatos deseos de empresarios”, es labor del ingeniero usar los recursos de manera eficiente y económica. Parece que eso ha cambiado en el discurso académico, ¿o será que ya no hay ingenieros formando ingenieros, y se han olvidado las viejas virtudes de esta noble profesión?

Si no hay bondad, belleza y verdad en el quehacer del profesional, y sólo el deseo compulsivo de complacer, entonces ya no vale la pena dedicarse a la profesión. Yo creo que esta idea es peligrosa, desalentadora. Al menos no quiero dedicarme a una profesión que se vea si misma de ese modo, no es por eso por lo que me he dedicado al hermoso arte de la programación todos estos años.

El programador compulsivo

Pero hay un riesgo con la programación, es una suerte de patología, identificada por Joseph Weizenbaum hace muchos años atrás, y que si seguimos y extrapolamos la visión de la “adulación en el hacer” nos puede hacer caer directamente en esta trampa.

Porque de la adulación del hacer es fácil caer en el programar por el simple placer que produce programar.

El programador de computadoras, […] es el creador de universos para los cuales es el único legislador. Así, también, es el diseñador de cualquier juego. Pero universos de complejidad virtualmente ilimitada pueden ser creados en la forma de programas computacionales. Más aún, y este es un punto crucial, los sistemas así formulados y elaborados actúan sus guiones programados. Sin chistar siguen sus leyes y vívidamente exhiben su comportamiento obediente. Ningún dramaturgo, ningún director de escena, ni emperador, no importa cuan poderoso, ha jamás ejercido tal autoridad absoluta para ordenar un escenario o campo de batalla y para comandar tales inquebrantables y cumplidores actores o tropas.
Uno debería sorprenderse si la observación de Lord Acton de que el poder corrompe no fuera aplicable en un ambiente en el cual la omnipotencia es tan fácilmente alcanzable. Aplica. Y la corrupción evocada por la omnipotencia del programador de computadores se manifiesta en una forma que es instructiva en un dominio mayor que el ambiente inmediato del computador. Para entenderlo, tenemos que observar un desorden mental, que aunque bastante antiguo, parece haberse transformado en un nuevo tipo: la compulsión por programar.
[En distintos centros de cómputo] brillantes jóvenes de aspecto descuidado, a menudo con ojos rojizos y hundidos, pueden ser vistos sentados en consolas de computadoras, con sus brazos tensos y esperando para disparar sus dedos, listos para atacar a los botones y teclas en los cuales su atención parece estar remachada como lo está el jugador sobre los dados rodando. […] Ellos trabajan hasta que prácticamente desfallecen, veinte, treinta hora de una vez. Su alimento, si lo disponen, llega a ellos: café, Coca Colas, sandwiches. Si es posible duermen en sacos cerca del computador. Pero sólo por pocas horas, luego vuelven a la consola.[…] Sólo existen, al menos cuando están enganchados, a través y por las computadoras. Son vagos de los computadores, programadores compulsivos. Son un fenómeno internacional.
¿Cómo puede distinguirse a un programador compulsivo de un programador profesional dedicado que trabaja muy duro? Primero por el hecho de que el programador profesional ordinario se dedica al problema a ser resuelto, mientras que el programador compulsivo ve el problema principalmente como una oportunidad de interactuar con el computador. El programador común usualmente discutirá tanto su problema sustantivo como los problemas técnicos con otros. Generalmente hará un trabajo preparatorio largo, como escribir y diagrama, antes de trabajar con el computador en si mismo. Sus sesiones con el computador pueden ser comparativamente cortas. Incluso puede que deje que otros hagan el trabajo en la consola. Desarrolla su programa de forma lenta y sistemática. Cuando algo no funciona, puede pasar mucho tiempo lejos del computador, considerando hipótesis cuidadosamente sobre las causas del malfuncionamiento, y diseñando experimentos cruciales para probarlas. […] Es capaz, mientras espera los resultados del computador, de atender otros aspectos de su trabajo, como documentar lo que ya ha hecho. Cuando ha compuesto el programa que que pasa a producción, es capaz de escribir una descripción razonable de este y cambiar su atención a otras cosas. El profesional ve la programación como un medio para un fin, no como un fin en si mismo. Su satisfacción viene de haber resuelto un problema sustantivo, no de haber sometido al computador a su voluntad.”
– Joseph Weizenbaum, Science and the Compulsive Programmer, en Computer Power and Human Reason, 1976

Voy a repetir eso último porque es importante: la satisfacción del programador profesional viene de haber resuelto un problema sustantivo, no de haber sometido el computador a su voluntad.

Cuando Weizenbaum escribía la labor de programación profesional requería de un mayor tiempo de reflexión alejada del computador a lo que se da hoy. En la actualidad, la interacción con el computador es más compulsiva que en 1976, porque tenemos compiladores más rápidos, metodologías más ágiles. El peligro de compulsión es mayor en mi opinión.

En su libro Computer Power and Human Reason, Joseph Weizenbaum advierte sobre los peligros de esta patología, y la compara con otras ya conocidas, como la del jugador/apostador compulsivo. Y tiene razón en muchas de sus preocupaciones. Es más, sospecho que muchas corporaciones tecnológicas abusan de esta patología para explotar a estos brillantes jóvenes. No es para nada coincidencia que se les ofrezca tener el campus, la comida, y todas sus necesidades cubiertas (incluso la recreación) en los mismos edificios donde trabajan. Tampoco es coincidencia que los confites, bebidas energéticas sean gratis en estos centros de programación, está estudiado que el chocolate aporta nutrientes que afectan nuestro estado de ánimo y bienestar (el triptófano que regula la serotonina conocida como la hormona del bienestar, la feniletilamina un neuromodulador que mejora el estado de ánimo, y la anandamina que nos hace sentir tranquilos y contentos).

Pues bien, el programador compulsivo estará de acuerdo con esta idea del placer del puro hacer de la programación. Y no se si Claudio Gutierrez está de acuerdo o no conmigo, porque no me queda claro si es una preocupación para él, o es algo que encuentra positivo.

Finalmente creo que esta “patología” del programador compulsivo termina expresándose en otro tipo de estado de ánimo, que exacerba una necesidad natural del ser humano, que es el sentido de reconocimiento.

El Programador Emo

¿Por qué profesionales y científicos clásicos, para qué decir los “humanistas”, aprecian/usan/usufructuan del software pero desprecian la actividad y sus profesionales?

Todos necesitamos reconocimiento. Es una necesidad tan natural, que la exigimos desde el momento en que lloramos por primera vez para demandar la atención de nuestra madre.

Sin embargo, con el tiempo vamos madurando y reconociendo que no es necesario andar exigiendo reconocimiento, que este llega sólo como fruto de una tarea bien hecha. Ganamos en seguridad, y cuando ya estamos maduros no andamos mendigando reconocimiento, sabremos que lo obtendremos por la calidad de nuestras acciones.

Por eso cuando leo un texto como el citado al principio de esta sección me molesto, porque cae en ese lugar común de muchos informáticos y que a esta altura francamente me tiene bastante tostado.

Es esa actitud de “pobrecitos nosotros los informáticos, todos usan nuestras creaciones, pero aún así somos ignorados por todo el mundo, nadie nos quiere, todos nos odian, queremos comer gusanos…”, como dice una vieja canción infantil proto-emo de los ochenta.

Si esperas ser reconocido porque doblegaste la voluntad del computador, entonces estás perdido, a nadie le va interesar eso, salvo quizás a otros programadores compulsivos como tu mismo.

Pero si tu actividad es sustancial, si aporta al bienestar de la humanidad, si tu aporte es valioso, bello, justo. Si resuelves una necesidad, si rascas una comezón, si aportas realmente a otro ser humano, el reconocimiento llegará.

Yo he sentido muchas veces la gratitud. Hace unos meses atrás conocí a una mujer que supo que yo había escrito cierto programa hace varios años atrás y que ahora ella estaba usando. Cuando nos presentaron se acercó a mi me dio la mano y un abrazo, y me agradeció, pues encontraba que mi programa era la solución más útil y práctica que había encontrado en muchos años para su problema.

¿Puedo decir que mi actividad es despreciada por otros? No, porque tengo muchos ejemplos y anécdotas similares que contar. ¿Que mayor satisfacción es esa?

El problema no es que otros no aprecien a los informáticos y sus obras, el problema creo yo es que los que se quejan de esa falta de reconocimiento nunca han resuelto nada que realmente pueda ser apreciado, o están en el lugar equivocado. Entonces, ¿de quién es el problema?

Herramientas

2013-02-22T21:13:00-03:00

Mi padre, como buen electrónico, contaba con muchas herramientas interesantes, algunas peligrosas, como descubrimos con mucho dolor mi hermano y yo. Otras herramientas eran intrigantes, extrañas, y complicadas. Alicates, destornilladores, voltímetros o testers, osciloscopios o simples soldadores, placas para montar circuitos, unos lentes de aumento con visera y lupa que servían para revisar circuitos, o disfrazarse de extraterrestre, pero la mejor, mi favorita era ese “lanza dardos paralizantes usado en las guerras clónicas del siglo XXV en los cerros de Chuquicamata”, el “dessoldador a pistón”. Ahí hay una foto lo más parecido que encontré a este maravilloso aparato futurista, al menos para un niño de 11 años en 1977 (con esto comprenderán ahora porque me gustó tanto Super 8 )

Como todo buen técnico, mi padre cuidaba sus herramientas, y por cierto no creo que le causara mucha gracia que mi hermano y yo las “secuestráramos” para nuestras aventuras espaciales. Habían herramientas que el recibía de su trabajo, y otras que compraba el mismo. Alguien que trabaja con herramientas toma muy en serio su adquisición, y en la medida que podía invertía en herramientas de calidad.

Hay herramientas baratas, y otras carísimas todos hemos comprado herramientas, y sabemos que podemos comprar algún destornillador que no durará más que para alguna reparación rápida. Pero si uno es serio en esto de usar herramientas, entonces invertirá un poco más de tiempo y dinero, después de todo una buena herramienta no sólo durará, sino que también te permitirá ganar tiempo en tu trabajo.

Lo otro importante es el espacio donde desarrollas tus actividades, donde ocupas esas herramientas. Mi padre tenía su espacio propio, un lugar para él, su lugar sagrado, donde se reencontraba con sus herramientas, tal cómo lo hemos hecho los humanos desde los tiempos en que éramos cazadores-recolectores.

Cómo le dijo Joseph Campbell a Bill Moyer en El Poder del Mito:

“Esta es una necesidad absoluta para el mundo de hoy. Debe haber una habitación, o cierta hora, o cierto día, donde no sepas nada de lo que dicen los periódicos esa mañana, donde no sepas donde están tus amigos, donde no le debas nada a nadie. Este es el lugar donde puedes experimentar y traer de vuelta lo que eres y lo que deberías ser.” “Este es el espacio para la incubación creativa. Al principio verás que nada pasa allí. Pero si tienes tu lugar sagrado y lo usas, algo eventualmente pasará.”

Para mi ese lugar sagrado está en mi casa, desde donde estoy escribiendo esto ahora, donde me acompaña ahora mi jarrón con un poco de te de menta, y nadie me interrumpe. Estoy yo, mis pensamientos, un teclado y 1920x1080 píxeles.

Este “locus de creación” es tan esencial cómo nuestras herramientas, es el lugar donde nuestra lanzas, hachas de piedra, arados, osciloscopios, teclados y lanza dardos paralizantes del siglo XXV se guardan, como objetos sagrados, que nos acompañan en nuestras aventuras.

Desde las puntas de lanza de la Cultura Clovis, hasta nuestros modernos aceleradores de partículas, hemos buscado perfeccionar nuestra herramientas, somos Homo Sapiens y Homo Faber, al mismo tiempo, o al menos lo somos aquellos que alteramos el mundo para adaptarlo a nuestras necesidades y deseos.

Imagino la fascinación que experimentaron aquellos primeros homínidos que tallaron esas antiguas piedras en los ríos de Zambia, las muestras más antiguas de nuestro pasado tecnológico. Sabemos que los simios superiores son capaces de usar herramientas, y recientemente hemos descubierto que algunos las construyen (aunque parece porque han aprendido de nosotros). Sin embargo, parece que somos los únicos seres que hemos hecho de esta habilidad de construir nuestra herramientas una ventaja evolutiva que nos ha permitido dominar (para bien o para mal) este planeta.

Tenemos el poder de crear y destruir almacenado en nuestras herramientas. Así de importantes son para nosotros. No creo que haya un ser humano que no use una herramienta de alguna clase, podemos decir que este realmente es uno de los aspectos esenciales de lo que nos hace humanos. Hasta el lenguaje podría ser considerado una herramienta, probablemente la más importante que hemos creado.

Maestría

La maestría en un arte u oficio sólo se alcanza cuando diseñas y llegas a construir tus propias herramientas, hasta que no has alcanzado esa etapa sólo eres un aprendiz en tu profesión.

Los programadores tenemos la ventaja de que podemos construir herramientas poderosas usando algo parecido a espacio sagrado que describí anteriormente, con teclados y pixeles, podemos crear universo de infinita complejidad como nos dice Weizenbaum, herramientas que nos permiten realizar milagros, o automatizar tareas rutinarias, que nos permiten crear cosas que no existían.

Recientemente un amigo ganó un importante premio usando las herramientas que él ha creado. Me refiero a Álvaro Graves, quien ganó el Health Metadata Challenge, un concurso que busca desarrollar nuevas funcionalidades tecnológicas usando los repositorios de open data del Departamento de Salud de Estados Unidos.

Esto es notable, y muestra el poder de nuestra profesión, la que considero, sin ninguna vergüenza, como una de las más importantes que ha creado el ser humano, y probablemente una de las que cambie profundamente nuestra sociedad (como ya lo está haciendo).

Así que ahí está tu desafío, no basta con adquirir tus herramientas, tenerlas, y dominarlas, sólo podrás empezar a alcanzar la maestría en tu oficio cuando seas capaz de construir tus propias herramientas, e incluso crear las herramientas que otros van a usar.

El camino de la innovación

2013-02-15T13:30:00-03:00

Adrian Cockcroft es el “arquitecto de nube” en Netflix, sí, cloud architect. ¿Qué diablos es eso? En otra oportunidad les voy a explicar. Lo importante es que escribe un blog bien interesante, sobre el cual se basa casi todo lo que voy a escribir hoy.

En diciembre de 2011 escribió un post titulado “How Netflix gets out of the way of innovation”, que les sugiero que lean. Es en realidad el “script” de una presentación sobre la cultura de Netflix.

Lo que quiere explicar Cockcroft en su presentación es: cómo Netflix puede hacer cosas tan rápido (a veces demasiado rápido), de modo que han podido realizar movidas estratégicas de gran envergadura, en poco tiempo y con un equipo pequeño de ingenieros.

Fíjense en lo que acabo de escribir: “realizar movidas estratégicas de gran envergadura, en poco tiempo y con un equipo pequeño de ingenieros”.

No es fácil, claro está. ¿Donde está la clave?

Cómo siempre, la clave está en no seguir las reglas del libro, hacer las cosas cómo los agoreros del desastre dicen que no se deben hacer, sin miedo, y torciendo un poco las reglas.

Netflix nace en 1997, fundada por Marc Randolph y Reed Hastings, ambos desarrolladores de software que trabajaban en Pure Software, los creadores de Purify, un debugger de memoria para C y C++ bastante popular a principios de los noventa en ambientes Unix. En esos tiempo esta era una herramienta valiosísima para depurar programas. Reed Hastings además era fundador de esa empresa.

En 1997 fueron adquiridos por Rational Software, la empresa detrás de UML y RUP, y que actualmente pertenece a IBM.

De esos tiempos Hastings recuerda que Pure Software era una pequeña empresa, bastante libre y anárquica, pero en la medida que fue creciendo se volvía cada vez más burocrática. Así que se retiró en cuanto fue adquirida por Rational, y pensó durante 2 años cómo volver a organizar su nuevo emprendimiento de modo que no cayera en estos “vicios del crecimiento”.

El resultado es Netflix, una empresa basada en los principios de “libertad y responsabilidad”. Hastings le paga muy bien a sus empleados, tienen vacaciones ilimitadas, y les permite estructurar sus propios paquetes de compensaciones. A cambio se espera un alto desempeño, que cada empleado sea capaz de hacer el trabajo de 3 ó 4 personas.

Voy a citar a Cockcroft quien describe de este modo la cultura innovadora de Netflix:

Lo que encontré en pocos años es una cultura que permite la innovación, de modo que Netflix hace las cosas más rápido que otras compañías, que están demasiado asustadas o son muy lentas para intentar algo.

¿Quién trabaja en una compañía que tiene más de una linea de productos? El problema es que esa compañía pierde el foco y tiene problemas asignando recursos que se necesitan, y esto produce grandes peleas. Toma una cosa grande y hazla bien. Para Netflix, el mercado objetivo es todo aquel que le guste ver películas y programas de TV, eso es lo que nos mantendrá ocupados por un tiempo.

[evitar la sobrecarga en la comunicación y la sincronización] Para los geeks, piensen en la Ley de Amdahl aplicada a las personas. Tenemos la mayor cantidad de personas en el mismo lugar. Ancho de banda alto, y baja latencia en las comunicaciones.

No tenemos ingenieros junior, ni estudiantes en práctica. Encontramos que los ingenieros que cuestan el doble son más de dos veces productivos, porque necesitamos menos sobrecarga administrativa. Reducir la sobrecarga administrativa es un aspecto importante para una cultura innovadora.

Vale la pena el gasto extra en ingenieros que no requieran administración. Somos pequeños comparados con compañías como Google, ellos toman talento crudo y lo desarrollan, nosotros a veces tomamos la opción de contratar a alguien con sólo cinco años de experiencia.

No tenemos un comité de arquitectura, ni estándares centralizados de codificación. Lo que hacemos es crear herramientas que creen un camino de mínima resistencia, lo que, combinado con la presión de los pares, mantiene alta la calidad. Los ingenieros son libres y responsables de resolver sus propios problemas.

Tampoco tenemos un equipo de sistemas (operaciones) que se encarga de correr el código en producción. Los desarrolladores ejecutan lo que han escrito. El teléfono celular de todos está disponible siempre, el truco es asegurarse de que no te llamen.

Toda la gente en operaciones tiene historias de horror acerca de desarrolladores estúpidos, y viceversa, pero no tiene por qué ser así. Tenemos una organización de desarrolladores que lo hace todo y no hay un equipo de IT Ops involucrado en nuestro desarrollo en cloud.

¿Quién tiene que pedir permiso para desplegar (deploy) 100 o 1000 servidores? Nosotros no. Los desarrolladores usan nuestro portal directamente, tienen que llenar un ticket de control de cambio donde registran lo que hicieron y pasa a producción, eso es todo. Hemos entrenado a nuestros desarrolladores para operar su propio código. Hemos creado y destruido hasta 1.000 servidores en un día, con sólo publicar nuevo código.

¿Quién tienen un ciclo centralizado de publicación y tienen que esperar el próximo tren antes de publicar su código? Nosotros no. Cada equipo maneja su propio calendario de liberaciones (releases). El código nuevo se actualiza frecuentemente, y reduce su ritmo en servicios maduros. Los equipos son responsables para manejar la evolución de la interfaz y dependencias por si mismo. Libertad y responsabilidad nuevamente.

Nuestros administradores de proyectos no están preocupados del seguimiento de las entregas. Ellos son dueños de sus recursos y de establecer el contexto para sus equipos. Tienen tiempo para hacerlo porque hemos eliminado todo el BS (Bull Shit) de su rol.

Los administradores tienen que ser buenos para seleccionar personal, deben ser técnicos y con la capacidad para “arquitecturar” lo que su equipo hace, además de gestionar el proyecto para lograr resultados. No separen esto en tres personas. Reduzcan la sobrecarga administrativa, minimicen el BS y el tiempo perdido. Los equipos típicamente están compuestos de 3 a 7 personas. Tengan una reunión semanal con el equipo y un 1 a 1 con cada ingeniero para mantener el contexto.

No tenemos herramientas estándares de desarrollo. Asumimos que los desarrolladores ya saben como ser productivos por si mismos. Damos algunos patrones comunes para que los nuevos puedan empezar, como Eclipse, IntelliJ, en Mac o Windows. Algunos usan Emacs en Linux. Contraten ingenieros experimentados que sean preocupados de su trabajo, y se encargarán de la calidad del código y los estándares sin tener que decírselo.

Trabajen con gente que respetan. La única manera de tener una alta densidad de talento es sacar a la gente que no aporta. Eso también aplica a lo que algunos llaman “pelmazos brillantes” (brilliant jerks). Aunque hagan un gran trabajo, la cultura no puede tolerar a las prima donnas ni el comportamiento anti social, así que la gente que no confía en otros o comparte lo que saben no encajan.

No pagamos bonos. No tenemos otros grados más que Ingeniero Senior, Manager, Director y VP. No registramos las horas o los días de vacaciones, decimos “tómatelas”. Una vez al año revisamos el salario de todos comparados con sus pares y el mercado.

Algunos pensaran que esto debe salir bastante caro, ¿pero cuál es el valor de ser increíblemente productivo y moverse más rápido que la competencia? Puedes adelantarte y establecer una posición líder antes que cualquiera se de cuenta que estás en el juego. ¿Recuerdan cuando hace unos pocos años atrás los “Analistas” decían que Netflix, la compañía de los DVD sería aniquilada por la otras compañías de streaming, y repentinamente el público se dio cuenta que estábamos generando más ancho banda de streaming que el resto?

Así, ¿qué puede salir mal? Bueno, erramos recientemente, fuimos demasiado rápido, en parte porque podíamos, pero no tuvimos suerte y metimos la pata. Lo bueno es que Netflix puede re planear y ejecutar los arreglos que necesitamos muy rápido, sin angustia interna ni acusaciones mutuas (finger-pointing).

Menos proceso, pocas reglas y principios simples. Denle a la gente libertad, háganlos responsables, reemplacen a los que no pueden o no quieren desempeñarse en ese ambiente. Enfóquese en la densidad de talento y en conservar la atención de la administración removiendo el BS de sus trabajos.

Ese es tu desafío. ¿Quieres organizar una banda y partir en una misión para salvar tu compañía? Deja de hacer las cosas que te quitan velocidad, y elimina toda la basura improductiva que obstruye tu gestión y a tus ingenieros.

Ese es el mensaje, y la segunda razón por la que me gusta Netflix. Libertad y Responsabilidad, así es cómo hay que trabajar. ¿Se atreverían a seguir un modelo como el propuesto por Netflix? ¿Creen que en su trabajo aceptarían un cambio cultural de este tipo? ¿Qué es lo que nos falta?

Jugar bien sus cartas

2013-02-13T12:14:00-03:00

Me gusta Netflix. No me gusta la TV, quiero decir la televisión pública actual, hace rato que no la veo, y yo era un verdadero “tevito”, pero hace tiempo que me aburrió con sus realities y sus pésimos noticiarios. Crecí en los setenta, donde la televisión significaba, al menos en Chile, series yankis como Star Trek, El Hombre Nuclear, Bonanza, y “Tardes de Cine”, con películas de Abbot y Costello o de Dean Martin con Jerry Lewis, pero de vez en cuando algún clásico del cine de terror, como la Momia con Boris Karloff, o Drácula con Bela Lugosi. Incluso recuerdo haber visto PSicósis de Hitchcock en Televisión Nacional una noche de verano cuando tenía unos trece o catorce años. Así que no vi tan mal cine ;-) Al menos cuando la televisión era pública, de verdad.

Por eso me gusta Netflix, porque encuentro viejas series, pero además le he dado la oportunidad a su servicio, y de a poco su programación ha empezado a interesarme más, he encontrado algunas joyitas, películas no tan antiguas, que probablemente nunca llegaron a nuestros cines, o revisar series que no pude ver cuando estaban en el cable, como Gallactica, o Breaking Bad.

Pero hay dos razones adicionales por las que me gusta Netflix. Una es que han entrado en la fase de la producción propia, una movida en la que también están Amazon, y Youtube. Y la otra razón es que tienen un equipo humano de desarrolladores notable.

Sobre la primera razón voy a hablar en este post, el aspecto tecnológico y de gestión de su equipo tecnológico quedará para el post que sigue.

En Febrero Netflix estrenó la serie House of Cards, una intriga política ambientada en Washington DC. Producida por el talentoso director de cine David Fincher (Seven, Fight Club, Zodiac, Social Network) quien además dirige los primeros capítulos, y por Kevin Spacey que es el protagonista de la misma. Una suerte de Ricardo III (tienen que leer a Shakespeare niños), conspirador, ambicioso, y que hace cómplice al espectador dirigiéndose directamente a la cámara, tal como sale en el video de promoción de la serie, y que corresponde a una escena del primer episodio:

Una serie muy bien lograda, pero lo notable es la forma en que ha sido exhibida. Al contrario de otras cadenas más “tradicionales”, como HBO (Juego de Tronos) o AMC (Mad Men), en este caso Netflix liberó la primera temporada completa, con sus 13 capítulos el 1 de febrero de 2013. Me gusta esta serie, y se las recomiendo, y si alguien quiere discutir conmigo su trama abajo están los comentarios para hacerlo ;-) (claro que sean gentiles con los demás y avisen cuando van a adelantar algo de la trama para los que no la han visto (spoiler alerts)).

Como muchos de los que ya no vemos televisión en forma pasiva, lo que busco es series completas disponibles por internet, no me gusta tener que depender de la programación del cable, quiero verlas cuando tenga tiempo, a mi ritmo, y normalmente me gusta verlas en “maratones” de estas series. Es por eso que sitios “piratas” como Cuevana o Series Yonkis son tan populares, sobretodo en Latino América. Y esto lo entiende muy bien la gente de Netflix, como se desprende de las palabras de Reed Hastings, el CEO de la compañía en una entrevista en EMOL del año pasado:

Uno de los problemas para el mercado latino es la piratería, que ofrece contenido nuevo y gratis, aunque de forma ilegal. ¿Cómo convencen a la gente de que Netflix es una buena opción?

“Es desafiante, con Cuevana y otros sitios que se ven muy profesionales. Pero Cuevana en las noches es muy difícil, y no tienen dinero como para invertir y mejorar el sistema. Es como el agua en botella. No todo el mundo va a pagarla, no todos pueden pagarla, pero es más sana. Lo que tenemos que hacer es que el streaming funcione perfecto, ampliando la selección. Hay gente que seguirá en la piratería, otros se convertirán. Lo único bueno que tiene la piratería es que introduce a la gente al concepto de video por internet”.

¿Los productores de contenido ven a Netflix como una manera de llegar a Latinoamérica de forma legal?

“Sí. Ellos son los que más pierden con la piratería, así que nos han apoyado. Pero quieren que paguemos. Les gusta lo que hacemos, pero quieren que paguemos”.

Es cierto que hay un problema con la actitud de la industria del cine, no se dan cuenta que al ser tan cerrados con su actitud están perdiendo mucho dinero. Por eso que aún no podemos contar en Latino América con cierto contenido que sí está disponible en USA o Canada, y mientras tanto, la gente sigue visitando sitios de streaming “piratas”.

Con sus más de 30 millones de subscriptores Netflix ya se siente con la confianza de crear material original, de este modo saltando muchas de las restricciones que imponen los codiciosos estudios.

Al menos yo pago feliz los 8 dólares del servicio, me parece un precio razonable, tengo contenido que me satisface, lo veo cuando quiero. Sí, es cierto que hacen análisis de mi comportamiento, y analizan mis hábitos de consumo de contenido, pero no me preocupa tanto si finalmente me dan el contenido que se ajusta con mis gustos. Al menos hasta ahora, Netflix ha demostrado ser más efectiva que el viejo People Meter en darme programación de calidad, algo que ya no existe en televisión. Esto viene de un equipo de desarrollo informáticos de alto nivel, que es el aspecto que más me gusta de Netflix, pero de eso voy a hablar en el próximo post.

Diferencia

2013-01-31T22:29:00-03:00

I’ve had people love me and had people hate me, and while I prefer the love by a wide margin, I kind of prefer either to indifference. Because I’m not about making indifference; I’m about making a diference.

He tenido gente que me ha amado y gente que me ha odiado, y aunque prefiero el amor por un amplio margen, prefiero cualquiera de los dos a la indiferencia. Porque no estoy para generar indiferencia, estoy para hacer una diferencia.

– Ron Jeffries, uno de los fundadores del eXtreme Programming.

cuatro cosas mínimas

2013-01-19T10:42:00-03:00

Hay una pila enorme de herramientas que a los ingenieros les gusta usar en su proceso de desarrollo, pero sólo hay cuatro que realmente necesitan:
* Editor
* Compilador
* Control de Versiones
* Bug Tracking
– Michael “Rands” Lopp

Todos los que se dedican a desarrollar software tienen algún tipo de editor o ambiente integrado de desarrollo (IDE) y un compilador disponible. Lo increíble es que el control de versiones y la herramienta de seguimiento de bugs no están presentes en muchas empresas que se dedican a desarrollar software.

Hace un tiempo nos tropezamos con un proveedor, que tenía una importante pieza de software que necesitábamos, pero al poco andar nos dimos cuenta que no tenían estas prácticas básicas incorporadas, y por esto no podían cumplir a las exigencias de nuestro negocio. Así que decidimos orientarlos para que empezaran a usarlas, les pedimos que incorporaran control de versiones, e incluso los incorporamos a nuestro propio “Jira” para poder hacer seguimiento de sus bugs y tareas pendientes. Esta son prácticas mínimas, y en este caso ayudaron a ordenar el proyecto, y están contribuyendo a mejorar el producto final, además creo que ha ayudado internamente a esa empresa, tanto para mejorar sus productos y servicios como para valorar más a su equipo técnico, porque nos dirigimos al staff ejecutivo directamente para solicitarle que debían implementar estas prácticas en su equipo de ingeniería. Aunque fue un proceso lento, los frutos se están notando.

Todo esto, por supuesto, son condiciones necesarias, pero no suficientes, tengo que aclarar. Lo importante es que incorporar estas herramientas básicas te establece una fundación mínima para controlar la complejidad de cualquier proyecto.

Debes controlar el caos de la administración de tus proyectos, y estas cuatro simples cosas harán mucho por ti. Como dice Michael “Rands” Lopp:

Estas herramientas empoderan a los ingenieros, permitiendo a todo el equipo lo siguiente;
* Colaborar sin pisarse los callos unos a otros, yo haré esto, tu harás esto otro.
* Responsabilizarse por su trabajo. ¿Quién está trabajando en esto?¿De quién es este bug?
* Medir su trabajo. ¿Cuantos bugs o tareas tengo asignadas? ¿Cuantas tienes tú?
* Recordar lo que hicieron. Uh, ¿quién diablos programó esta basura?
Encontrarás muy temprano en tu trabajo de administración que la principal razón por la que la gente va a tu oficina es para resolver conflictos. Una vez que los participantes del conflicto dejan de gritar, necesitarás que vean los hechos, porque los hechos los aterrizarán, y aterrizar significa menos gritos. Estas herramientas son excelentes repositorios de fríos y duros datos, y eso puede ayudar mucho.

Como bono adicional, y si a ustedes les interesan estos temas de las certificaciones, les puedo contar que de acuerdo al honorable Instituto de Ingeniería de Software (SEI), el contar con estas cuatro cosas tan simples te puede hacer merecedor de una linda certificación CMMI Nivel 2 (“en este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente”).

¿Cuentan ustedes con estas cuatro herramientas básicas? ¿A cuantas instituciones conocen que ni siquiera están usando un control de versiones? Lamentablemente, son muchas más de las que uno sospecha.

El Efecto Elop

2013-01-08T22:50:00-03:00

“Si conoces a tu enemigo y te conoces a ti mismo, no temerás el resultado de cien batallas. Si te conoces a ti mismo, pero no a tu enemigo, por cada victoria lograda sufrirás una derrota. Si no te conoces ni al enemigo ni a ti mismo, sucumbirás en cada batalla.” – Sun Tzu

El gráfico muestra los ingresos (revenue) de las divisiones de Smartphones de tres grandes compañías, desde el primer trimestre de 2009 hasta el cuarto trimestre de 2010. ¿Cuál es Nokia?

Orgullo Finés

Desde el 7 de diciembre de 1939 hasta el 8 de enero de 1940 las tropas finesas y soviéticas se enfrentaron en la batalla de Suomussalmi. Al coronel Hjalmar Siilasvuo de Finlandia se le encomendó la misión de atacar al noveno ejército Sovietico dirigido por el general Mihail Pavlovitz Duhanov, que había cruzado la frontera norte con la Unión Soviética una semana antes. El noveno ejército ruso contaba con 45.000 efectivos, 90 tanques y fuerza aerea. Las tropas finesas no superaban los 11.000. Sobre uno de los terrenos más helados del mundo, muy cerca del círculo polar ártico.

A pesar de estar en desventaja numérica de 1 contra 4, y de no contar con tanques ni fuerza aérea fue capaz de derrotar a las tropas rusas, con una pérdidade 1.000 hombres, mientras que el ejército soviético perdió 13.000 soldados (algunos afirman que fueron más) y fueron capturados unos 2.100 prisioneros. En esta batalla los fineses capturaron 43 tanques (al empezar la guerra Finlandia sólo contaba con 30 tanques en todo su ejército). No sólo eso, Soumussalmi fue capaz de bloquear a la 44a división sovietica que venía a reforzar a las tropas del general Duhanov.

Después de la batalla los soviéticos destituyeron al general Duhanov. Uno de sus comandantes de división, el general Alexei Nikolajevitz Vinogradov fue encontrado tan incompetente e inepto, que fue juzgado, condenado y ejecutado cuatro días después de la batalla. Fue fusilado junto a otros comandantes y oficiales sobre un lago congelado delante de las tropas sobrevivientes de la batalla, el 11 de enero de 1940.

Comprenderán que para los fineses Suomussalmi es un héroe y realmente merece ser considerado uno de los grandes estrategas de la historia, capaz de derrotar a un adversario con mejor tecnología y cuatro veces más recursos.

Tal como Steve Jobs puede ser considerado uno de los CEO más brillantes, frente a uno de los peores Stephen Elop, en la batalla por el mercado de los smartphones. Por eso que les duele tanto a los fineses que Nokia haya perdido su liderazgo en esta industria. Tal como lo relata Tomi T. Ahonen, autor y consultor nacido en Finlandia, quien se lamentó en un extenso post donde pide la cabeza de Elop, y con razón a mi parecer[1].

Nokia, nuestra plataforma se quema

La linea punteada del gráfico anterior indica el momento en que Stephen Elop asume como CEO de Nokia. En ese momento, entrando en el segundo semestre de 2010, Nokia vendía más del doble que Apple. El iPhone fue introducido en 2007, a inicios del 2010 iPhone aún estaba rezagado con respecto a Nokia. En la historia sólo podemos encontrar una situación similar (que un competidor venda el doble que su más cercano rival) sólo si nos remontamos a 1915, cuando Ford vendía más del doble que GM.

Elop fue contratado para arreglar problemas de ejecución. Nokia Corporation había tenido una mala gestión por parte de los CEO anteriores, pero no la división de SmarthPhones. Esta división contaba con una salud impecable como muestra el gráfico, y con ingresos que duplicaban a sus competidores. Era un escenario soñado, la oportunidad para construir un imperio en la industria de los smartphones.

Pero, ¿qué sucedio? Dejemos correr el reloj y veamos el mismo gráfico unos trimestres después.

Recordemos, estamos viendo sólo la división de smartphones, que era la joya de la corona de Nokia.

A fines de 2010 se produce el “efecto Elop”.

Este impacto en ventas no fue el resultado de un producto fallido, ni problemas inesperados, ni un cambio repentino en los gustos de los consumidores. Ni desastres naturales, ni huelgas. Fue un memorandum, el famos Burning Platforms Memo de Stephen Elop, cuyo texto he incluido al final en las notas[3].

¿Qué llevó a pensar a Elop que siendo el que más vendía smartphones en 2011 estaba condenado a perder el liderazgo de la industria?

En el memorandum Elop iguala la situación de Nokia a la de un hombre atrapado en una plataforma petrolera en el mar del norte, en medio de la oscuridad de la noche, rodeado por las llamas. El hombre decide saltar a la oscuridad del mar.

Según Elop, Nokia estaba sobre una plataforma en llamas, en la completa oscuridad e incerteza, a la compañía sólo quedaba saltar valientemente al vacío.

Atención, en esa época las ventas de Nokia estaban en aumento, es después del memo de Elop que estas empezaron a declinar.

Según Ahonen este es uno de los memoradum más costosos en toda la historia de la administración.

Fue después de este memo que Nokia decidió abandonar Symbian y MeeGo para optar por Windows Phone 7.

Recordemos que Stephen Elop era jefe de la división de negocios de Office 2010 en Microsoft, que en marzo de 2011 recibió de Nokia 6 millones de dólares en bonos de “compensación por pérdidas de ingresos de su anterior empleador”, por encima de su salario anual de 1.4 millones de dólares.

Según Ahonen, toda la imagen del memo de Elop es un autoengaño.

En el primer trimestre de 2011 Nokia cayó más que Palm, Motorola, Windows Mobile, Ericsson, Blackberry o cualquier otro fabricantes de móviles en su peor momento.

En el momento que el memo apareció colapsó la confianza al interior de Nokia, la confianza en los empleados de Nokia, y la de estos con el CEO. El gran error de Elop, no confiar en su producto, en la tremenda historia y capacidad que Nokia había demostrado hasta entonces.

De acuerdo a Ahonen, el memo de Elop le costó a Nokia 13 mil millones de dolares en ventas en 12 meses (4,8 mil millones en utilidades) [2].

La idea convencional es que iPhone mató a los smartphones de Nokia, según Ahonen, y tiene datos para demostrarlo, cada año de existencia de iPhone fue un año en que Nokia creció en ventas, hasta 2010. Desde que apareció iPhone hasta el memo de Elop, Nokia vendió el doble de unidades que iPhone. Nokia ganaba en tecnología, tenía una tienda de aplicaciones, juegos, un buen sistema operativo, estaba innovando con MeeGo, etc.

Todo eso se perdió, por culpa del que probablemente sea uno de los errores en administración más grandes de nuestro tiempo.

Notas

[1] El análisis de Ahonen es de julio de 2012 un blog extenso, pero muy detallado y lleno de información, del que saqué los gráficos de este post.

También ver su nota del 7 de enero sobre los siete grandes colapsos en la historia de los smartphones

[2] [Post sobre las pérdidas de Nokia] (http://communities-dominate.blogs.com/brands/2012/06/the-final-reckoning-of-burning-platforms-memo-damaged-nokia-by-wiping-out-13b-in-revenues-and-destro.html)

[3] The Burning Platform Memo

Este es el texto del memo enviado por Stephen Elop en febrero de 2011.

Hello there,

There is a pertinent story about a man who was working on an oil platform in the North Sea. He woke up one night from a loud explosion, which suddenly set his entire oil platform on fire. In mere moments, he was surrounded by flames. Through the smoke and heat, he barely made his way out of the chaos to the platform’s edge. When he looked down over the edge, all he could see were the dark, cold, foreboding Atlantic waters.

As the fire approached him, the man had mere seconds to react. He could stand on the platform, and inevitably be consumed by the burning flames. Or, he could plunge 30 meters in to the freezing waters. The man was standing upon a “burning platform,” and he needed to make a choice.

He decided to jump. It was unexpected. In ordinary circumstances, the man would never consider plunging into icy waters. But these were not ordinary times - his platform was on fire. The man survived the fall and the waters. After he was rescued, he noted that a “burning platform” caused a radical change in his behaviour.

We too, are standing on a “burning platform,” and we must decide how we are going to change our behaviour.

Over the past few months, I’ve shared with you what I’ve heard from our shareholders, operators, developers, suppliers and from you. Today, I’m going to share what I’ve learned and what I have come to believe.

I have learned that we are standing on a burning platform.

And, we have more than one explosion - we have multiple points of scorching heat that are fuelling a blazing fire around us.

For example, there is intense heat coming from our competitors, more rapidly than we ever expected. Apple disrupted the market by redefining the smartphone and attracting developers to a closed, but very powerful ecosystem.

In 2008, Apple’s market share in the $300+ price range was 25 percent; by 2010 it escalated to 61 percent. They are enjoying a tremendous growth trajectory with a 78 percent earnings growth year over year in Q4 2010. Apple demonstrated that if designed well, consumers would buy a high-priced phone with a great experience and developers would build applications. They changed the game, and today, Apple owns the high-end range.

And then, there is Android. In about two years, Android created a platform that attracts application developers, service providers and hardware manufacturers. Android came in at the high-end, they are now winning the mid-range, and quickly they are going downstream to phones under €100. Google has become a gravitational force, drawing much of the industry’s innovation to its core.

Let’s not forget about the low-end price range. In 2008, MediaTek supplied complete reference designs for phone chipsets, which enabled manufacturers in the Shenzhen region of China to produce phones at an unbelievable pace. By some accounts, this ecosystem now produces more than one third of the phones sold globally - taking share from us in emerging markets.

While competitors poured flames on our market share, what happened at Nokia? We fell behind, we missed big trends, and we lost time. At that time, we thought we were making the right decisions; but, with the benefit of hindsight, we now find ourselves years behind.

The first iPhone shipped in 2007, and we still don’t have a product that is close to their experience. Android came on the scene just over 2 years ago, and this week they took our leadership position in smartphone volumes. Unbelievable.

We have some brilliant sources of innovation inside Nokia, but we are not bringing it to market fast enough. We thought MeeGo would be a platform for winning high-end smartphones. However, at this rate, by the end of 2011, we might have only one MeeGo product in the market.

At the midrange, we have Symbian. It has proven to be non-competitive in leading markets like North America. Additionally, Symbian is proving to be an increasingly difficult environment in which to develop to meet the continuously expanding consumer requirements, leading to slowness in product development and also creating a disadvantage when we seek to take advantage of new hardware platforms. As a result, if we continue like before, we will get further and further behind, while our competitors advance further and further ahead.

At the lower-end price range, Chinese OEMs are cranking out a device much faster than, as one Nokia employee said only partially in jest, “the time that it takes us to polish a PowerPoint presentation.” They are fast, they are cheap, and they are challenging us.

And the truly perplexing aspect is that we’re not even fighting with the right weapons. We are still too often trying to approach each price range on a device-to-device basis.

The battle of devices has now become a war of ecosystems, where ecosystems include not only the hardware and software of the device, but developers, applications, ecommerce, advertising, search, social applications, location-based services, unified communications and many other things. Our competitors aren’t taking our market share with devices; they are taking our market share with an entire ecosystem. This means we’re going to have to decide how we either build, catalyse or join an ecosystem.

This is one of the decisions we need to make. In the meantime, we’ve lost market share, we’ve lost mind share and we’ve lost time.

On Tuesday, Standard & Poor’s informed that they will put our A long term and A-1 short term ratings on negative credit watch. This is a similar rating action to the one that Moody’s took last week. Basically it means that during the next few weeks they will make an analysis of Nokia, and decide on a possible credit rating downgrade. Why are these credit agencies contemplating these changes? Because they are concerned about our competitiveness.

Consumer preference for Nokia declined worldwide. In the UK, our brand preference has slipped to 20 percent, which is 8 percent lower than last year. That means only 1 out of 5 people in the UK prefer Nokia to other brands. It’s also down in the other markets, which are traditionally our strongholds: Russia, Germany, Indonesia, UAE, and on and on and on.

How did we get to this point? Why did we fall behind when the world around us evolved?

This is what I have been trying to understand. I believe at least some of it has been due to our attitude inside Nokia. We poured gasoline on our own burning platform. I believe we have lacked accountability and leadership to align and direct the company through these disruptive times. We had a series of misses. We haven’t been delivering innovation fast enough. We’re not collaborating internally.

Nokia, our platform is burning.

We are working on a path forward – a path to rebuild our market leadership. When we share the new strategy on February 11, it will be a huge effort to transform our company. But, I believe that together, we can face the challenges ahead of us. Together, we can choose to define our future.

The burning platform, upon which the man found himself, caused the man to shift his behaviour, and take a bold and brave step into an uncertain future. He was able to tell his story. Now, we have a great opportunity to do the same.

Stephen.

new style

2013-01-05T18:52:00-03:00

Año nuevo, estilo nuevo y cambio en la plataforma de publicación.

A contar de hoy este blog usará octopress como su plataforma de generación de contenido.

Otra novedad de este año es que todo el contenido se encuentra disponible en este repositorio github, bajo licencia creative commons 3.0.

No sólo es por tener un respaldo, sino que además es un medio de preservar y difundir el contenido de este blog. Estando todo el “código fuente” de mis contenidos durante estos años disponible, ustedes pueden ayudarme a mejorarlo, y a difundirlo. Si han usado github saben que si encuentran un “bug” (error) en mis posts pueden obtener la fuente y corregirlo directamente en github y avisarme mediante un “pull request”. Es la magia de github y la podemos usar para mejorar la calidad del contenido.

Lo otro que me permite este medio es la flexibilidad para poder llevar estos artículos a otros formatos, como un libro electrónico, por ejemplo, un proyecto que llevo postergando mucho tiempo y que probablemente este año pueda concretar.

Gracias nuevamente por seguir leyendome, los espero y que todos tengamos un muy buen año 2013.

Dichos, Locos y Trenes

2012-12-29T08:31:07-03:00

Los principios del agilismo (y del mejor proceso para desarrollar software) los aprendí hace muchos años de la frase popular que dice: “hay que matar los piojos de a uno, antes que los piojos lo maten a uno.”

El arte de gestionar proyectos parte de cosas simples, de saber qué se quiere y orientar los esfuerzos y recursos para lograr ese objetivo: Dirección+Organización+Método. Pero no siempre tenemos todos los recursos, o no contamos con todos los elementos, o simplemente no alcanza el tiempo para lograr el objetivo. Allí es cuando es necesario aplicar el principio de la suboptimización de las partes en función del todo, también conocido como el principio del loco y la rueda pinchada.

Si no lo leyeron en mi post anterior, acá está de nuevo la historia que expone este importante principio de administración:

Era un día de lluvia torrencial, y Marcos pincha un neumático justo enfrente de un manicomio. Luego de estacionar se baja, se protege de la lluvia como mejor puede y procede a sacar los pernos que sujetan la llanta. Los deja cuidadosamente en el suelo formando un montón. Lleva la rueda a la maleta del auto para cambiarla por la rueda de repuesto, y cuando vuelve patea los pernos sin querer, con tan mala suerte que estos ruedan cayendo por las alcantarillas.

“¡Qué mala suerte tengo!”, exclama Marcos, “¿ahora que voy a a hacer?”

En ese momento, uno de los locos que miraba por la ventana esta escena lo llama: “¡Oiga, amigo!. ¡Super fácil! Sáquele un perno a cada una de las otras ruedas y le coloca tres pernos a la rueda, y se va así hasta la próxima estación de servicio donde compra pernos y arregla la rueda.”

Marcos queda asombrado, y tras escuchar la ingeniosa propuesta del loco no hace menos que agradecerle entusiasmado: “¡Qué gran idea loco! ¿cómo se te ocurrió?”

La respuesta del loco fue inmediata: “¡Porque yo estoy aquí encerrado por loco, no por tonto!”

El loco conoce el principio de la suboptimización de las partes, el que dice:

“Para que el objetivo de un sistema se cumpla, necesariamente las partes deben sacrificar o minimizar el logro de sus propios objetivos. Lo más importante es el todo (el sistema). El principio de suboptimización indica que las partes deben suboptimizar sus objetivos para que se logre alcanzar el objetivo general.”

El problema de muchos gestores, y que es más frecuente en los líderes más jóvenes o con menos experiencia, es que esperan optimizar los objetivos de todas las partes. Siempre se quejan de que no tienen suficientes recursos, porque están buscando la optimización de su propia unidad. Siempre se verán llenos de trabajo y sobre demandados, pero a veces es necesario darse cuenta que no es posible lograr el óptimo de su unidad, porque hay un objetivo mayor (que a veces es ignorado por los miembros de la sub unidad, o simplemente no lo saben).

Lo que importa es lograr el objetivo de la dirección, el logro del todo, por sobre el logro de la parte individual. Es una de las claves del principio peor es mejor que ya hemos discutido antes acá.

Los malo de sobre optimizar, es que nos lleva a situaciones ridículas y al estancamiento, y por ende el fracaso del proyecto (atraso, exceso del presupuesto, o simplemente no terminarlo). Y es un error tan frecuente, sobretodo en los proyectos tecnológicos y en los de desarrollo de software en particular.

Resulta que el software es tan maleable que da la sensación de que siempre podemos optimizar un poquito más aquella rutina, o buscar hasta la última vulnerabilidad y colocar todo el código preventivo para evitar que seamos hackeados, o perdamos consistencia en nuestra base de datos, o que dejemos de brindar el servicio en el momento más crítico, olvidando que no es posible tener consistencia, alta disponiblidad y tolerancia a fallas, todo al mismo tiempo.

Todo esto de ponerse en todos los escenarios posibles me recuerda El Principio de la Melania que viene de este viejo cuento:

Esta es la historia de un campesino chileno que era guarda agujas de tren, como el de la fotografía de abajo. Antiguamente, y quizás en algunos ferrocarriles siga siendo así, ciertos segmentos de las vías, donde estas se cruzaban por ejemplo, requerían la manipulación coordinada del desvío) mediante una palanca, conocida como aguja.

Esta es la historia de Pedro, un huasito que cuidaba una aguja de tren, que vivía con su mujer en una choza cerca de las vías del ferrocarril. Un día un curioso turista se para y le pregunta a qué se dedica para vivir:

– Yu soy un guarda ‘guja – responde Pedro – ¿Y qué tiene que hacer? – pregunta el turista – Güenu, yo pesco esta palanca que ve acá, que si llama ‘guja, y la mueo, así ¿ve? – ¿Pero para qué la mueve? – inquiere el turista – Porque cuandu el tren del sur quiere ir p’al norte… yu mueo la ‘guja pa’ entro. Y si viene el tren del norte que quiere ir pa’l sur yu mue’o la ‘guja pa’ juera.

El turista lo mira divertido y decide ponerlo a prueba:

– ¿Y si vienen los dos trenes al mismo tiempo? – ¡Gúeno, en ese caso llamo a la Melania pueh! – ¿Y quién es la Melania? – pregunta el sorprendido turista – La Melania es mi mujer, y la llamo pa’ que venga a ver ¡la media cagadita que va a quedar!

Y ese es el Principio de la Melania :-) que tengan un buen fin de año.

Locos y Ruedas

2012-12-19T17:09:56-03:00

Era un día de lluvia torrencial, y Marcos pincha un neumático justo enfrente de un manicomio. Luego de estacionar se baja, se protege de la lluvia como mejor puede y procede a sacar los pernos que sujetan la llanta. Los deja cuidadosamente en el suelo formando un montón. Lleva la rueda a la maleta del auto para cambiarla por la rueda de repuesto, y cuando vuelve patea los pernos sin querer, con tan mala suerte que estos ruedan cayendo por las alcantarillas.

“¡Qué mala suerte tengo!”, exclama Marcos, “¿ahora que voy a a hacer?”

Marcos queda asombrado, y tras escuchar la ingeniosa propuesta del loco no hace menos que agradecerle entusiasmado: “¡Qué gran idea loco! ¿cómo se te ocurrió?”

La respuesta del loco fue inmediata: “¡Porque yo estoy aquí encerrado por loco, no por tonto!”

Este cuento se lo escuché hace tiempo a mi jefe, y es notable porque explica un importante principio de administración. La pregunta queridos lectores es: ¿cuál es el principio de administración que se expone en este chiste?

Caine's Arcade

2012-12-08T13:39:28-03:00

Me entero de esta maravillosa historia Vía Pensamientos Ágiles.

Dicen que un niño sólo necesita de su imaginación, y quizás una caja de cartón para ser feliz, y en este caso Caine nos muestra que ese don puede alegrar a mucha gente.

La historia apareció en Reddit y tuvo un impacto grande como pueden ver en el video, actualmente existe una iniciativa para becar los estudios de Caine y otros niños tan imaginativos como él, la que hasta ahora ha recaudado más de 200.000 dolares:

Un Modelo De Confianza

2012-12-03T09:26:33-03:00

Un Modelo de Confianza (*)

“No confían en nosotros”, “¡no nos creen!”, son frases que se escuchan frecuentemente cuando empezamos una relación de trabajo, servicio o negocios.

La confianza es algo que toma tiempo y esfuerzo construir, pero que puede perderse muy rápidamente. Que importante sería contar con un modelo que nos permita evaluar y mejorar el grado de confianza con nuestro clientes y usuarios.

Existe un modelo de confianza que divide este concepto en cuatro dimensiones que pueden ser aglutinados en una sencilla ecuación:

T = (C + R + I) / S

Los términos de esta ecuación son:

T: Trust, la Confianza que es el resultado.
C: Credibility, la credibilidad, que vienen dadas por las credenciales o conocimientos, además de la honestidad.
R: Reliability, la fiabilidad, la seguridad, el saber que las promesas se cumplen.
I: Intimacy, la intimidad que se logra al conocerse. Afecta a las emociones, es el sentirse conectado con la otra persona, es la apertura, la transparencia.
S, Self orientation o Selfishness, la auto orientación, la búsqueda de lograr los objetivos propios en desmedro de los objetivos de la relación, es el grado de egoísmo en la relación.

Fíjense que los primeros factores, la credibilidad, la fiabilidad y la intimidad suman confianza, son graduales, cada elemento por separado ayuda a aumentar el resultado.

En cambio al aumentar el egoísmo, el interés propio, el querer cumplir con “la agenda propia” en desmedro del objetivo común, hace que el valor de la confianza baje rápidamente. A mayor auto orientación menos confianza.

Se puede analizar cualquier relación usando este modelo. Un modo consiste en asignar valores de 1 a 10 en cada uno de estos parámetros, en ese caso una relación de confianza perfecta debería dar un valor de 30 y la desconfianza absoluta tendría el valor de 0,3.

Veamos un ejemplo.

Prospección de un nuevo cliente. En este caso la percepción inicial que tengan de nosotros está dada por la reputación de nuestra empresa. Supongamos un valor 6, sobre el promedio, en una escala de 1 a 10. La fiabilidad toma tiempo establecerla, así que en base a comentarios con otros clientes pueden evaluarnos inicialmente con un 3, lo mismo pasa con la intimidad, el grado de conocimiento y cercanía, supongamos que es un 3. La auto orientación que reflejaremos en este caso será alta, porque estamos es un escenario de ventas, así que nos asignarán un valor de 8.

Los valores serán finalmente: C=6, R=3, I=3, S=8.

Hacemos el cálculo T= (6+3+3) / 8 = 12 / T = 1,5

Así que el valor de la confianza parte normalmente con un valor bajo cuando empezamos una relación.

En clientes que ya nos conocen el valor sólo depende de nuestro desempeño (C y R), del grado de conocimiento mutuo que tengamos (I) y de la manera en que hemos logrado transmitirles que estamos interesados en brindarles un buen servicio (S con un valor bajo).

Típicamente en relaciones con clientes estos los valores son así:

C (credibilidad) = 7 R (fiabilidad) = 8 I (intimidad) = 5 S (auto orientación) = 4

T (confianza) = (7+8+5)/4 = 20/4 = 5

La confianza perfecta sería un 30. Una meta más realista es lograr un valor entre 12 y 20. Estos valores cambian según el tipo de relación o de proyecto. El grado de intimidad es algo que depende totalmente del cliente y este puede limitar mucho este factor. El factor más importante, y donde hay que enfocarse para mejorar la confianza es la auto orientación, es importante transmitir que estamos alineados con los objetivos e intereses de nuestro cliente.

En la medida que aumentamos la confianza nuestros clientes nos pedirán consejo en áreas más amplias que nuestro conocimiento técnico. Entenderán mejor el valor que aportamos. Habrá una mayor tolerancia ante nuestros fallos (cuando son errores honestos y no por descuido en nuestro quehacer). Los clientes se abrirán más a mostrarnos su real situación. Y finalmente seremos recomendados a otros potenciales clientes.

Algunos consejos para mejorar estos parámetros

C: CREDIBILIDAD

Decir la verdad
No exagerar
Decir inmediatamente y en forma directa cuando no se sabe algo
Hacer nuestros deberes
Amar lo que hacemos

R: FIABILIDAD

Hacer pequeños compromisos, en cosas pequeñas, y cumplirlos
Usar la terminología del cliente, o usuario
Ser consistente
Enlazar las intenciones con las acciones

I: INTIMIDAD

Ser paciente, la intimidad se da en el tiempo
Abrir nuestro proceso, mostrarnos transparentes
Saber escuchar
Demostrar que te preocupas del otro (empatía)

S: AUTO ORIENTACION O EGOISMO

Dejar que la contraparte llene esos espacios en blanco en una conversación
Escuchar, ser reflexivo
Enfocarse en definir el problema, no en describir la solución
Tomar la responsabilidad por el fallo en la comunicaciones
Ser honesto con uno mismo, si tenemos poco interés en esta situación es casi inevitable que nos enfoquemos más en nosotros mismos que en lograr el éxito conjunto
Comprometerse con la mayor intensidad en ayudar al otro (tu cliente, tu usuario).

(*) Este artículo fue publicado originalmente en mayo de 2011, esta es una versión corregida y aumentada :)

Este artículo fue inspirado por una excelente charla de Ariel Plon Partner Lead de Microsoft Chile.

Fuente: The Trust Equation http://www.collieassociates.com/common/Trust_Equation.pdf

La Paradoja de Teseo y otras ideas sobre los cambios

2012-12-01T07:24:12-03:00

“El barco en el cual volvieron (desde Creta) Teseo y los jóvenes de Atenas tenía treinta remos, y los atenienses lo conservaban desde la época de Demetrio de Falero, ya que retiraban las tablas estropeadas y las reemplazaban por unas nuevas y más resistentes, de modo que este barco se había convertido en un ejemplo entre los filósofos sobre la identidad de las cosas que crecen; un grupo defendía que el barco continuaba siendo el mismo, mientras el otro aseguraba que no lo era.” – Plutarco, citado desde Wikipedia

Dejen que las instituciones funcionen, es casi un lugar común en la política chilena, una frase que se sostiene en la idea de la perpetuidad y continuidad de las mismas, “las personas cambian, las instituciones quedan”.

En uno de sus viajes el escritor inglés Douglas Adams visita el Golden Pavilion en Kioto, Japón, y relata la siguiente anécdota:

“Yo recuerdo que una vez en Japón, fui de visita al Gold Pavilion Temple en Kyoto y me sorprendí al observar lo bien que el templo había resistido el paso del tiempo desde que fuera construido en el siglo catorce.

Entonces me explicaron, que en realidad el edificio no había resistido, ya que de hecho se había quemado hasta los cimientos dos veces durante este siglo. Por lo que le pregunté a mi guía japonés “¿O sea que no es el edificio original?”.

“Al contrario, por supuesto que es el original”, me contestó, un tanto sorprendido por mi pregunta. “¿Pero no se incendió?”. “Sí”. “Dos veces”. “Muchas veces”. “Y fue reconstruido”. “Por supuesto. Es un edificio histórico importante”. “Con materiales completamente nuevos”. “Por supuesto. ¡Si se había incendiado!”. “Pero entonces, ¿cómo es posible que sea el mismo edificio?” “Siempre es el mismo edificio.”

Entonces, la pregunta es si los elementos cambian gradualmente, uno por uno, ¿cómo se mantiene la unidad, o la identidad de la institución?

Aristóteles trata de resolver la paradoja alegando que hay cuatros causas o razones que describen una cosa. Está la Causa Formal, o el diseño de la cosa, mientras que la Causa Materiasl es la materia de la que están hechas las cosas. El Barco de Teseo, o el Golden Pavillion pueden ser descritos como la misma cosa debido a la causa formal, o diseño, que no cambia, aunque cambie el material usado para construirlos varíe con el tiempo. Del mismo modo que un río tiene la misma causa formal, aunque la causa material (el agua contenida en este) cambie en el tiempo.

Otra causa de Aristóteles es el fin, o Causa Final, es el propósito previsto de una cosa. El Barco de Teseo podría tener el mismo fin, transportar a Teseo, incluso pese a que su causa material pudiera cambiar con el tiempo. Por último está la Causa Eficiente que es como y por quien está hecha una cosa, por ejemplo, la forma en que los artesanos fabricaron y montaron alguna cosa. En el caso de El Barco de Teseo, los trabajadores que construyeron el barco en primer lugar podrían haber usado las mismas herramientas y técnicas para reemplazar los tablones en el barco.

Así que la respuesta de Aristóteles, nos lleva a concluir que la esencia de las instituciones no necesariamente reside en las personas, sino que en los procedimientos, en las formalidades, las reglas, las leyes que las norman. O el fin para el que fueron concebidas. O a veces puede ser por la simple costumbre.

Lo que me recuerda otra historia sobre unos monos:

En un experimento, un grupo de científicos metieron cinco simios en una habitación. En el centro de la misma ubicaron una escalera tipo tijera, como la que utilizan los pintores o carpinteros de obra. En lo alto y sobre la escalera colocaron unas bananas. Cuando uno de los monos ascendía por la escalera para acceder a las bananas, los científicos aplicaban al resto de monos un chorro de agua helada. Al cabo de un tiempo, los monos relacionaron el uso de la escalera y el chorro de agua fría, de modo que cuando uno de ellos se aventuraba a ascender en busca de una banana, el resto de monos se lo impedían con violencia. Al final, e incluso ante la tentación del alimento, ningún mono se atrevía a subir por la escalera.

En ese momento, los científicos extrajeron al azar a uno de los cinco monos iniciales y lo sustituyeron por uno nuevo en la habitación. El mono nuevo, naturalmente, trepó por la escalera en busca de las bananas. En cuanto los demás observaron sus intenciones, se abalanzaron sobre él y lo bajaron a golpes antes de que se descargara sobre ellos el chorro de agua fría. Después de repetirse la experiencia varias veces, el nuevo mono comprendió que era mejor para su integridad renunciar a ascender por la escalera.

Los investigadores sustituyeron otra vez a uno de los monos del grupo inicial. El mono que había sido sustituido participó con especial interés en las palizas al nuevo mono trepador.

Posteriormente se repitió el proceso con los monos restantes, hasta que llegó un momento en que todos los monos del experimento inicial habían sido sustituidos.

En ese momento, quienes realizaban la investigación se sorprendieron con los resultados. Ninguno de los monos que había en la habitación había sido sometido alguna vez al chorro de agua fría. Sin embargo, ninguno se atrevía a trepar para hacerse con las codiciadas bananas.

Aunque no tengo claro si esta es una historia real o apócrifa, su lección es clara, y no pueden negar que refleja muchas veces lo que pasa en nuestras instituciones, u organizaciones. Lo mismo a una escala menor como nuestros equipos de trabajo. Cuantas veces pasa que alguien llega y no se le explica nada, pero se le pide que realice cierta labor de cierta manera, y en el fondo nadie sabe muy bien por qué. Como los monos de la historia, nadie se atrevió a experimentar el resultado de quebrantar la norma, o cuestionarla, nadie ni siquiera sabe que podría pasar, como los monos.

Dicen que si los maderos originales del barco de Teseo se hubiesen guardado en otro lugar, algún intrepido habría sido capaz de reconstruirlo, y podría haber clamado, con mucha razón de que era el poseedor del verdadero Barco de Teseo. Salvo, por el pequeño detalle que no contaba con Teseo y sus amigos. Pero eso es tema para otra reflexión posterior.

¿Es tu jefe un programador funcional?

2012-11-21T19:01:51-03:00

Probablemente tu jefe, y mi jefe, sin ser informáticos, ni programadores o ingenieros de software, sean mejores programadores funcionales que tu mismo, claro, porque es probable que ellos utilicen uno de los lenguajes funcionales más populares que existen: Excel.

Sí, Excel, ese que usan muchos de tus colegas no informáticos, soporta perfectamente el paradigma funcional.

Primero en Excel tienes valores, números, o a veces textos, que colocas en celdas. Por ejemplo, puedes colocar en la celda A1 el valor 2, y en la celda A2 el valor 3.

Después tienes funciones, u operaciones que trabajan sobre valores que se encuentran en una celda, por ejemplo, puedes definir que el valor de la celda A3 se calcula como A3 = A1 * A2. Excel te mostrará el valor de aplicar esta operación a los valores disponibles en ese momento en las celdas A1 y A2, en nuestro caso se verá en A3 el número 6.

[caption id=”attachment_3123” align=”aligncenter” width=”141”] Definiendo el valor de una celda en función de otras dos[/caption]

Lo ”interesante” es que esta operación no cambia el valor de las celdas que son usadas como argumentos. Esto quiere decir que en Excel no hay efectos laterales, el resultado de la función sólo afecta a aquellos que usen el resultado, pero no a los argumentos de entrada.

Veamos que pasa si agregamos otras ecuaciones a nuestra planilla, haciendo que unos valores dependan de resultados previos.

Por ejemplo: A4=A1+2, B3=A2A2, B4=A1-A2, C3 = B3-B4, C4 = B3B4.

Excel nos permte ver las dependencias de esta secuencia de cálculos:

[caption id=”attachment_3124” align=”aligncenter” width=”303”] Dependencias entre las celdas[/caption]

Decimos que el orden de evaluación está dado por las dependencias de los datos.

Otra cosa interesante es que dados los mismos valores de entrada el resultado final no cambia, en nuestro caso, si A1 contiene el valor 1, y A2 contiene el valor 2, entonces la celda C4 siempre tendrá el valor -4, no hay sorpresas, el valor de la celda C4 depende sólo de los argumentos de entrada y la secuencia de cálculos intermedios.

Consideren la siguiente función en C:

int calc(int x, int y) { static int z = 0; z = z + x * y; return z;

}

Si invocamos esta función la primera vez con los valores 1 y 2, el resultado será 2, pero si lo invocamos por segunda vez, con los argumentos 2 y 3, el resultado será 8, si la invocamos por tercera vez, con los valores 1 y 2, ¡el resultado será 10!

Esto pasa porque C permite efectos laterales, en particular al declarar la variable z como static hace que ese valor se mantenga a lo largo de cada invocación a la función.

Los lenguajes de programación funcional prohiben esta opción, no pueden haber efectos laterales como estos, el resultado de la función solo debe ser el mismo para los mismos argumentos de entrada.

Ahora bien, excel, usada a este nivel, junto con algunas funciones pre definidas, opera como lenguaje funcional, pero no todo excel es funcional, por ejemplo, cuando se usan macros, o se crean funciones con lenguajes de extensión en VBA u otros lenguajes (como C#).

Pero la mayor parte de los usuarios la usan a este nivel, y sin darse cuenta, programan usando el paradigma funcional.

Las propiedades más importantes de la programación funcional están disponibles en Excel a nivel básico. Lo demás, todo lo complicado, que asusta a tantos programadores, como los combinadores, la monadas, el currying, las reducciones, el lambda cálculus, etc, son temas más avanzados, que a pesar de sus nombres intimidantes, y de la costumbre de la comunidad funcional de “hablar en difícil”, son temas perfectamente abordables por cualquier programador.

Pero si nunca te has animado a aprender la programación funcional, quizás es hora de que abras una planilla de cálculo y empieces a jugar con ella, verás que es muy iluminador.

Te propongo los siguientes ejercicios:

Calcula la sucesión de Fibonacci en Excel
¿Es posible crear funciones recursivas en Excel? (sin usar VB o algún lenguaje de programación para “extender” excel).

(Este post está disponible también en La Sombra de Dijkstra)

Disclosure: No es llegar y hacerlo

2012-11-20T11:58:13-03:00

El siguiente post es de un notable ”villano invitado”, se trata del experto en seguridad, y gurú en cervezas ;-), Cristián Rojas.

Esta nota nace de una conversación con Cristián en El Test Acido, la que dado el formato del programa no pudimos profundizar, por eso le pedí a Cristian que elaborara el tema en un artículo que ahora comparto con ustedes.

Disclosure: No es llegar y hacerlo

Por Cristián Rojas

Recientemente fui testigo (¿victima?) de la divulgación de una vulnerabilidad en un conjunto de servidores UNIX distribuidos con NIS en el cual tengo una cuenta de usuario. La vulnerabilidad consiste en que mediante un comando cualquier usuario podría obtener la lista de todos los usuarios del conjunto de servidores NIS con sus respectivos verificadores de passwords. Muy a pesar que las passwords están convertidas en verificadores utilizando crypt, como ocurre en todo sistema basado en UNIX, podría ocurrir que una clave muy fácil (o basada en una palabra de diccionario) fuera descifrada utilizando herramientas como John The Ripper.

Sin embargo, el problema no está en la vulnerabilidad, sino en quién la divulgó. El denunciante es otro usuario del sistema, quien mencionó que no es primera vez que reporta la vulnerabilidad a través del foro. Contacté en forma privada a los administradores del sistema y les indiqué acerca del problema, el cual corrigieron al día siguiente, y además les pregunté si habían recibido alguna comunicación en forma privada por parte del denunciante, ante lo cual me respondieron que no.

Es muy probable que al divulgar la vulnerabilidad en el foro, el denunciante debe haber sentido que hizo un bien a la comunidad de usuarios del sistema. El problema es que al hacerlo, expuso innecesariamente a los usuarios afectados a que sus cuentas fueran vulneradas, o peor aún, que otros servicios que usen éstos fueran vulnerados también. ¿Malicia por parte del denunciante? Muy lejos de serlo. Ignorancia quizás.

Modelos de (no) divulgación

Existen hoy en día 3 modelos de divulgación que puede seguir un usuario al encontrarse con una vulnerabilidad de seguridad en un sistema computacional, en una red o en un software.

El primer modelo es el de No Divulgación, en el cual quien encuentra una vulnerabilidad simplemente se queda callado. Este modelo es interesante porque, si quien encuentra la vulnerabilidad es inescrupuloso, podría explotar la vulnerabilidad él sólo y profitar con ello. Nadie más se entera, ni el proveedor (con esta palabra me refiero al Webmaster, Sysadmin, o desarrollador en caso de un software), ni otros usuarios. El problema es que la vulnerabilidad seguirá existiendo, y la información seguirá siendo expuesta o modificada ilícitamente, esto es, hasta que alguien más se tropiece con la vulnerabilidad y la revele, momento en el cual puede ocurrir uno de los otros dos modelos.

El segundo modelo es el de Divulgación Abierta, también conocido por algunos como Divulgación Irresponsable, que consiste en que el usuario, al encontrar una vulnerabilidad, la hace pública en su blog, foros, etc., y publica todos los detalles al respecto: En qué aplicación/sistema está, qué vulnerabilidad es y cómo explotarla. Al hacer esto, permite que, por ejemplo, los investigadores en seguridad se pongan a elaborar firmas nuevas para antivirus, los administradores de sistemas se pongan en alerta y tomen medidas pseudo-mitigatorias (workarounds), y los usuarios finales queden muy asustados. No sólo eso, sino que mete presión a los proveedores para parchar sus sistemas o software.

Hay 2 problemas con este tipo de divulgación. El primero de ellos consiste en que al tener una vulnerabilidad no parchada y de la cual todo el mundo está enterado, ocurre lo que se conoce como ataques Zero Day, que son ataques contra sistemas los cuales no han sido parchados contra esa vulnerabilidad, por lo tanto están completamente expuestos, y lo seguirán estando hasta que salga un parche. Y de ahí surge el segundo problema: El proveedor deberá apurar un parche y preocuparse de dos cosas: Que el parche mitigue la vulnerabilidad y que no cause una regresión. Además, el proveedor no podrá dormir 100% tranquilo, ya que una cosa es lanzar el parche y otra muy distinta es que la gente lo instale.

Un ejemplo claro de esto es el siguiente: Si Usted es un usuario de Windows, ¿se ha preguntado alguna vez qué es esta Herramienta de eliminación de software malintencionado de Windows que llega a través de Windows Update, y por qué llega cada mes? No es un antivirus. Es una herramienta que permite el parchado automático de sistemas Windows contra gusanos como el Nimda o el SQL Slammer, que fueron lanzados hace ya casi 10 años, sin embargo aún causan estragos porque muchos sistemas Windows en el mundo están desatendidos, y estos gusanos se siguen autoreplicando a través de la red desde y hacia estos sistemas vulnerables.

¿Eso significa que estamos todos expuestos a vulnerabilidades, Zero Days y gente que las divulga en forma abierta?

No necesariamente. Existe un modelo poco conocido (o poco utilizado) conocido como Divulgación Responsable, el cual consiste en que el denunciante contacta en forma privada al proveedor y le revela sólo a él los detalles de la vulnerabilidad, mientras indica públicamente que la aplicación tiene una vulnerabilidad.

El diablo está en los detalles

En ambos casos el denunciante publica la vulnerabilidad. ¿Dónde está la diferencia? En los detalles que éste hace públicos al descubrir la vulnerabilidad. En el caso de la divulgación abierta todos los detalles son divulgados inmediatamente, mientras que en la divulgación responsable el denunciante sólo se limita a decir “este sistema tiene una vulnerabilidad”, sin mencionar mayores detalles. De hecho, lo de “responsable” se configura como una responsabilidad tanto para con el proveedor, como para con los usuarios de la aplicación, ya que el denunciante acuerda un plazo razonable con el proveedor para que éste corrija la vulnerabilidad, tiempo después del cual el denunciante hará públicos todos los detalles de ésta.

Lo que se recomienda es usar divulgación responsable. Incluso hay organizaciones que ofrecen dinero como motivación para reportar vulnerabilidades usando este modelo. Sin embargo, no todo el mundo tiene esta posibilidad financiera. Pero ahora tenemos claro cuáles son los modelos de divulgación y sabemos cómo divulgar bien (y mal) las vulnerabilidades de seguridad de los sistemas que usamos.

Sobre el Autor:

Cristián Rojas es Ingeniero Civil en Computación de la Universidad de Chile. Actualmente se desempeña como especialista en monitoreo de sistemas para Firenxis, y como consultor freelance en desarrollo de software seguro y de politicas empresariales de seguridad de la información. También se desempeña en el campo de la docencia, participando como profesor del módulo de Seguridad de Software en el Diploma de Postítulo en Seguridad Computacional de la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile, y además como profesor de pregrado en el curso CC5315: Seguridad de Software de la misma facultad.

Tortugas y Ranas

2012-11-19T18:29:22-03:00

Alan Kay crea Smalltalk e inventa el término “orientado al objeto”. Cuando se le pregunta qué significa él replica que “los programas Smalltalk sólo son objetos.” Cuando se le pregunta de que están hechos los objetos él responde, “ de objetos”. Cuando se le pregunta de nuevo él dice “mire, todos son objetos todo el camino hacia abajo. Hasta que se encuentre con las tortugas.” – Una breve y disparatada historia de los lenguajes de programación, James Iry

En la cosmología Hindú el “Universo era un ente cerrado, contenido en los anillos de Seshu, la cobra negra . En el fondo de todo había un mar de leche rodeado completamente por esa serpiente. Una enorme tortuga nadaba en el lácteo océano, sobre cuyo caparazón se apoyaban cuatro elefantes (cada uno en un punto cardinal). Al mismo tiempo esos elefantes sostenían sobre sus lomos a la Tierra. En su centro se formaba una gran montaña central donde un gigantesco fuego giraba a su alrededor ocasionando el día y la noche. Seshu, con un anillo superior contenía a la bóveda celeste.” [1]

Mirándolo de cierta manera todas nuestra arquitecturas de sistemas con todas sus capas tienen una estructura similar a estas exóticas cosmologías, la diferencia es que a veces, pareciera que en vez de ser una torre de sólidos animales, como tortugas y elefantes, lo que tenemos es una torre llena de ranas dispuestas a saltar en cualquier momento :-)

Las ruinas de Troya y otros errores periodísticos

2012-11-18T11:02:13-03:00

“El hombre que no lee nada tiene mejor educación que aquel que sólo lee los periódicos” – Thomas Jefferson

En una nota publicada hoy en La Tercera, página 66, sección de tendencias, se nos informa que las murallas de Troya tenía 8 metros de altura, y 4 metros de largo. ¿4 metros de largo? ¡Realmente era una ciudad en miniatura! Seguramente el redactor de la nota trató de expresar el ancho de las murallas.

Un gazapo, un detalle menor, me dirán, pero ¿se imaginan si el rey Priamo hubiera encargado la construcción de una muralla de apenas 4 metros de largo? Homero se habría quedado sin tema para su poema épico, y Aquiles sería visto como un matón de barrio.

Ayer este mismo diario publica una nota sobre el terror a las matemáticas que sufrimos todos. Bueno yo no le tengo miedo a las matemáticas, así que supongo que la periodista autora de esa nota estará hablando de su experiencia personal y generalizando como suelen hacer ultimamente los periodistas (los “periodistas post-google”, como les dice mi hijo, estudiante de periodismo, que tiene el peso de tenerme como editor en las sombras ;-) ).

No voy a analizar en profundidad el problema de esa nota (pagina 12 del suplemento tendencias del 17 de noviembre), sólo consideren que se confunde síntoma con causa, pero no son los científicos los que cometen el error, el problema es del redactor de la nota de divulgación.

Gracias a uno de mis lectores recibo la referencia del libro El Periodista Universal, de David Randall. Como dice mi corresponsal, un libro que todo periodista debería leer.

De acuerdo a Randall los errores más comunes de la prensa son de estos 6 tipos:

Errores de Detalle: nombres, edades, direcciones, etc.
Errores narrativos: una parte del reportaje es falso, aunque el resto sea correcto
Engaños e invenciones: toda la nota es falsa
Errores de contexto: falta información de fondo, o está equivocada, con lo que lo relatado es inexacto
Errores por omisión: un reportaje se hace engañoso al omitirse una parte
Errores de interpretación: sumar dos y dos y que salga cinco

Y ~~once~~ las trece causas de estos errores son (*):

Información falsa de las fuentes
Anotaciones deficientes
No comprobar los hechos con las fuentes
Desear que algo sea cierto
Renuencia a comprobar datos o sucesos “sensacionales”
No leer la historia una vez escrita
Confiar demasiado en los sitios web
Desoír nuestros propios recelos
Omitir hechos que no encajan con una teoría pre concebida (o concebida con demasiada rapidez)
Dar a imprimir demasiado pronto
No consultar lo temas técnicos con especialistas
Excesiva confianza en datos de archivo
Errores de producción, errores no intencionales, introducidos por copistas, editores por ejemplo

Este modelo de Randall me parece bastante razonable, y si se dan cuenta también aplica a nosotros que escribimos un blog, e incluso a otros ámbitos (estoy pensando en la toma de requerimientos).

Lo importante, creo yo es reconocer nuestros errores, y tratar de poner la mayor honradez en nuestra labor de divulgación, tanto si somos “bloguers” como si somos periodistas (con mayor razón aún).