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.

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.

“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”

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.

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

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?

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.

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 )

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.

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.

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.