He encontrado un interesante post en el blog FrameThink, en el cuál su autor que usa un pseudónimo "yeeguy", dice que ha tenido contacto directo con los ingenieros de Facebook por más de seis meses y ha logrado compilar unas notas sobre la metodología de desarrollo de software dentro del gigante de las redes sociales. Dado que el autor del post no puede ser claramente identificado y sus colaboradores "epriest" y "fryfrog" tampoco, debemos tomar todo esto pon pinzas. Pero hay cosas que me han llamado la atención y por ello las he incluído en este post.

He aquí algunas notas interesantes sobre el proceso de desarrollo de software en Facebook:

• Los dos departamentos más grandes de la compañía son Ingeniería (desarrollo de software) y Operaciones (administración de sistemas), con 400 a 500 empleados cada uno. Justos estos departamentos suman más de la mitad de los empleados de Facebook.
• La relación entre gerentes de producto e ingenieros está entre 7 a 1 y 10 a 1.
• Todos los ingenieros que se unen a Facebook pasan por un "campamento de entrenamiento" que dura entre 4 a 6 semanas, en donde son entrenados sobre las peculiaridades del sistema corriendo errores y atendiendo clases y charlas de ingenieros seniors. Se estima que el 10% de los participantes de estos campamentos no los aprueban y por lo tanto no son admitidos en la compañía.
• Después del campamento de entrenamiento, "todos" los ingenieros ganan acceso a la base de datos de Facebook. Según Facebook hay políticas internas muy estrictas que definen que es causal de despido. Ciertamente si esto es así, es una razón más para no poner información personal en Facebook, ya que por la famosa "cultura del encubrimiento" en las grandes organizaciones, nunca se sabrá de los malos manejos hasta que hayan causado un gran daño.
• Cualquier ingeniero puede editar cualquier parte del código de Facebook a voluntad. ¡Uy!, si eso es cierto para mi es un milagro inexplicable todo el servicio no ha colapsado completamento.
• Es una cultura basada en la ingeniería, según uno de los ingenieros entrevistados: "Los gerentes de son básicamente inútiles aquí". Como ideal me parece bueno, pero en la práctica, poner a un grupo de seres humanos a trabajar juntos, sin ningún tipo de supervisión y coordinación es simplemente imposible.
• Durante las reuniones interdepartamentales de cada mes, son los ingenieros quienes llevan el hilo conductor, los que presentan los reportes de progreso de productos. Si alguién de marketing o de gerencia de productos hace muchas preguntas, entonces recibe sus gerentes reciben un feedback de que esa persona ha hablado demasiado en la reunion. Otra vez, esto parecen los sueños de algún desarrollador, pero no es la forma como operan grandes compañías, es más ni Google que es una empresa mucho más posicionada en el mercado y con una larga tradición de gerencia orientada a la ingeniería, opera de esta manera.
• Las disputas de si una nueva idea vale la pena ser implementada, es usualmente resuelta invirtiendo una semana en desarrollarla y luego probandola en un pequeño grupo de usuarios, por ejemplo implementar esta nueva característica en el 1% de los usuarios de Nevada.
• Los ingenieros están interesados en resolver los problemas relacionados a la infraestructura como la escalabilidad. Debido a que son problemas más "difíciles", estos generan más prestigio entre los compañeros. Esto me parece el clásico "macho men" en versión geek, donde las cosas no se hacen pensando en su necesidad, sino en el prestigio que se obtendrá.
• Es mandatorio que el código implementado sea revisado por varios ingenieros antes de ser puesto en funcionamiento. Rumores de que Zuckerberg personalmente revisa todo cambio asociado con los feed news.
• Por defecto todo cambio en el código es aplicado semanalmente (los martes).
• Facebook tienen 60,000 servidores. Existen 9 niveles para implementar nuevo código. El nivel de implementación más pequeño sólo afecta a 6 servidores. Si se detecta algún error durante la implementación del nuevo código se detiene inmediatamente el proceso se repara el error y se incia otra vez desde el primer nivel de implementación.

Bueno, el artículo es bastante largo y ofrece algunas ideas que pueden parecer buenas, pero suenan utópicas en el mundo real. Pero al menos para lo que sirve todo esto, es para cuestionarnos si la forma como desarrollamos software dentro de nuestras empresas es la correcta. Cuantas veces no hemos querido enviar al de marketing bien lejos porque propone cosas absurdas o imposibles de implementar, pero en el mundo real es la gente de marketing la que tiene la sartén por el mango y no el departamento de ingeniería.