Soy la gota que colmo el vaso, o la paja que le jodió la espalda al camello o como cojones se diga por aqui (nunca me ha quedado claro). Lo se desde hace tiempo y las matemáticas los refuerzan. Somo más o menos 23 en el curro (nos gusta decir esa cifra por lo mistico y lo hacker -algunos saben de lo que voy- pero hay alguno más por ahi) y la estructura que tenemos es radicalmente horizontal. Nadie es más que nadie, nadie manda sobre de nadie y aqui se arremanga hasta el CEO cuando hay que picar código y estar hasta las cuatro de la mañana con los ojos como platos porque nos ha reventado un servidor. Es parte del encanto que le echo al asunto. En zdnet, hace unos días, nos llamaron socialistas anarquistas que queremos forrarnos con el placer ajeno. No es que vaya muy descaminado (aunque lo de socialista sobra, quiza), pero nos quedamos unas horas sonriendo pensando que era uno de los piropos más bonitos que nos habían echado en mucho tiempo.
No se si saben como me pillaron. Quitando jaleos de cambio de visado tardaron un año en contratarme. De septiembre a septiembre. Tenia (tengo) un buen amigo alli dentro y daba la brasa con que debería dejar a las multinacionales de los cojones e irme a currar con ellos. Acepté y envié el curriculum, con el truco de que nunca envio un documento txt, sino un enlace unico alojado en mi servidor (los docs ni los envio, yo mismo he tirado a la basura curriculums en word con macros en visual basic apenas abriendolos) como el nombre es unico, un simple tail -f va diciendome porque manos pasa mi curriculum y quien accede varias veces a consultarlo. Conté 23 accesos, todos los empleados y acepté a encontrarmelos varias veces para comer, cenar, irnos de juerga. Nunca me preguntaron nada técnico ni tuve que escribir una linea de programación, solo ideas vagas de diseño y que pensaba de la vida y la información y como estructuraba tal y cual cosa. Como dije aqui parece que los perros viejos a veces nos conocemos mirandonos a los ojos y al tiempo ya tenia la oferta en firme. Fue curioso que lo que me decidiera a seguir asistiendo a las entrevistas fue la clase de preguntas y las conversaciones que tenia con ellos que iban desde como es posible pintar un mapa con solo cuatro colores hasta lo increiblemente erronea que es la programacion orientada a objetos. Me lo pasaba bien. Empece a trabajar y pase la semana charlando con un compañero sobre macros del mutt, filtros del procmail o de la mejor manera de usar el ion3. Hace tiempo hable de la anomalia de Craigslist y de como una empresa con mas o menos 23 empleados (menos de la mitad de ellso tecnicos) soportan un trafico bastante superior a las 10.000 paginas por segundo. La respuesta es el principio KISS y el personal. Que la prensa no ser sorprenda tanto. Sinceramente cualquiera de estos hijoputas podria llevar la pagina solo con una mano a la espalda.
Como decia curramos del todo horizontal y como he visto en otros entornos, el horizontalismo radical tiene unos problemas de escalabilidad terribles. Los hemos ido supliendo con tecnica y herramientas para coordinarnos el trabajo de la mejor manera posible pero parte de las conversaciones que he tenido con los miembros del equipo en las ultimas semanas es sobre la escalabilidad del equipo humano. Somos pocos y queremos crecer, solo que nos queremos perder nuestro encanto. No quiero verme con lo que pasa en organizaciones mas grandes, lidiando con product managers, project managers, middle managers, business developers y toda la pesca. No quiero ver gente en posiciones intermedias agarrada como una lapa y subiendo por el jijijaja de hoy te la chupo a ti y tu mañana haces los respectivo. Las multinaciones, como dije por aqui otro dia, son enormes maquinas de manejar la complejidad y la manera mas natural de hacerlo es llenarse de posiciones intermedias que no hacen mas que dirigir y crear papeleo o inventarse features horribles muchas veces para justificar su propio puesto y existencia. Además de eso, no creo que necesariamente nos ayude tener una estructura así. El mayor descubrimiento de Google, el que le dio su ventaja competitiva frente a todos lo hicieron dos palomos en un garaje y simplificando mucho (porque han tenido muchos problemas entre medios) han tenido que escalar dos mil veces ese tamaño hasta hacer algo medianamente tan rompedor (como su correo).

La informática (la ciencia) es muy reciente, tiene poco más de medio siglo y cambia cada día. Hay libros sobre el tema que han perdurado después de más de treinta años y a los que hay que acercarse con respeto. El hecho de que los programadores de lisp se crean más que nadie no es por pura arrogancia, es que vienen de un lenguaje de los años 50 y han visto nacer y morir muchas tecnologías rompedoras mientras las que han tenido éxito son las que más se acercan a la elegancia del lenguaje de los paréntesis. En la primera visita que nos hicieron los padres de Justine a nuestra casa cuando nos mudamos juntos su padre (que es profesor de informática teórica en una de las universidades de la zona) vió que en una de las estanteía tenía varios libros de lisp, todos llenos de anotaciones e ideas. Me dijo (medio en broma medio en serio) que estaba contento que su hija “viviera con un hombre de verdad”. Ahora, que Justine esta pensando en aprender programación, tengo una pequeña bronca con su padre sobre el hecho de que quiero que ella aprenda ese lenguaje de principio (aunque mi novia ya ha hecho sus primeros pinitos con el interprete python de su mac). Como decía, hay libros clásicos y nuevos clásicos que se reconocen en la primera página, como el libro The Art of Unix Programming,o el wizard book con el que se aprende a programar en el MIT. Uno de esos libros antiguos y venerables es The Mytical Man Month, escrito en los 60-70 por quien dirigió el proyecto de creación del OS/360 de IBM, proyecto que resultó un desastre porque al estar atrasado, el entonces gigante decidió añadir miles de programadores, lo que aumentó la complejidad por el incremento de la comunicación entre programadores y por consiguiente , hizo que el proyecto finalicese aún más tarde que si se hubiese mantenido el equipo original y con mucha menos calidad de lo esperado (¿le recuerda a alguien a Microsoft y la historia de quien hizo el botón de salida de Windows Vista?). La respuesta de su autor es clara: crear una fuerte jerarquía para que la comunicación fluya solo en una dirección, pero conociendome y conociendo a mi entorno, mejor que ni se nos pase por la cabeza el intentarlo. Leer libros antiguos de informática tiene su gracia, uno ve que desde el principio de los tiempos (desde Alan Turing y las Bombes de Bletchley Park) se repiten los mismos parámetros de geekismo y los mismos modelos optimos de producción. Fred Brooks ya hablaba en los 60 de “nerds en garajes creando empresas informáticas”. Casi como que no hemos avanzado.

Lo que hablaba es de la escalabilidad de equipos humanos y de lo que podemos hacer y no hacer. Cada persona que entra en el equipo, en un entorno horizontal y democrático neutral, añade no solo uno sino n-1 canales de comunicación, el número de canales de comunicación en nuestro modelo se representa como n(n-1)/2 (siendo 23 personas tenemos 253 canales permanentemente abiertos, si doblaramos equipo, tendríamos más de 1000) y manejar toda esa complejidad de forma orgánica, sin una cabeza central que vaya dirigiendo el tráfico puede ser una pesadilla. La cosa es que parece que la conversación sobre la escalabilidad empezó cuando yo entré en escena, quizá por las características de mi proyecto que hace que este de mosca cojonera detrás de todos intentando entender que hacen y añadiendo más tráfico si cabe a los canales de comunicación. Soy la gota que colmó el vaso del modelo. Detectando esto y siguiendo los consejos de Fred Brooks me aislé en una esquina esperando terminar mi proyecto en solitario, anulando al mínimo la comunicación con otros miembros y esperando reducir el overhead mientras voy acabando con lo mio y pensamos que hacer con nuestro modelo de desarrollo. Mi novia, que es socióloga esta más que encantada al asistir a como solucionamos el problema, y tenemos medidas porque dadas las limitaciones de los sistemas que usamos (mysql, apache) estamos empezando a optar por soluciones propias, hechas en casa. Uno de los modelos más interesantes es del un ingeniero que esta trabajando en un reemplazo para nuestra base de datos usando un modelo de almacenamiento en columnas. (un ejemplo de lo que digo). La empresa con los paneles solares más gordos del mundo, que encontró este problema mucho antes que nosotros, tardó siete personas-año en crear su bigtable, tiempo y recursos que, obviamente no tenemos (pese a que este convencido que terminaremos solucionandolo).

¿Y todo esto a que venía? pues que estamos contratando para añadir una gota más al vaso y ver como va, poco a poco evolucionando el modelo. El único requisito es que sea un fuera de serie, que sepa perl y se considere, como decimos, un rock-star. Como se que hay gente que me lee desde San Francisco y como esta de medio-moda el pedir personal por los blogs, pues ahi queda (mi email lo teneis en la pagina de about).