Como desarrolla software Facebook

Kent Beck se fue a trabajar a Facebook. Kent Beck es mundialmente conocido por ser el co-inventor de conceptos tas importantes como el Extreme Programming o el Test-Driven Development (primero crea los tests y después el código que tiene que pasarlos), dos pilares de toda metodología ágil.

Cuando llegó vió rápidamente que el proceso de desarrollo de Facebook era caótico y no tenía nada que ver con las buenas prácticas que él promulgaba. Con lo que pensó, aquí estoy yo para arreglarlo. Como él mismo cuenta con todos los detalles en este podcast, la realidad fue muy diferente y sirvió (a él y a nosotros) para entender mejor el proceso de desarrollo en entornos tan masivos como Facebook. Os hago un resumen de lo que Kent Beck aprendió en Facebook.

Las dificultades de todo proceso de desarrollo en una gran empresa

Kent se esperaba encontrar un caos donde el proceso de desarrollo fuera cada vez peor. Cuando Kent Beck se unió a Facebook (2011), FB ya estaba en una fase de gran expansión, incluyendo su fuerza laboral.

Según Kent en contextos con un gran nombre de nuevas contrataciones lo que normalmente pasa es que se acaban adoptando las prácticas que todo el mundo conoce. Y eso significa acabar en un método muy tradicional, con ciclos de desarrollo largos, mucha planificación,… que acaba matando la eficiencia.

Esto es lo que Kent quería evitar con sus prácticas ágiles y de test-driven development.

Fases exploratorias y expansivas en el software a gran escala

Kent se dió rápidamente cuenta que a nadie le interesaban sus teorías pero que al mismo tiempo, el desarrollo en Facebook no era ni de lejos el desastre que él había predicho. Con lo que se dedicó a intentar entender qué hacía Facebook tan especial. Empezó un programa de coaching interno que le permitió concer ingenieros software de todas las áreas de Facebook.

Y al final llegó a la conclusión que la cultura ingenieril en Facebook era muy buena en organizar (y evaluar) equipos de desarrollo en función de la etapa en la qué se encontraba la funcionalidad que estaban implementando.

En concreto, Kent habla de tres fases:

• Fase exploratoria. El objetivo es probar si una nueva funcionalidad genera interés en los usuarios de Facebook. La mayoría no lo harán pero a veces una da en el clavo y puede llegarse a convertir en una de las grandes atracciones del Facebook futuro (ejemplo, la introducción de vídeos). Esta es la parte “barata” (no hay que dar soporte a los millones de usuarios de Facebook) sinó como mucho a grupos piloto con lo que no hace falta desarrollar un código bonito y eficiente.
• Fase expansiva. Fase del crecimiento vertical (todo el mundo quiere publicar y ver vídeos). Se trata de crecer tan rápido como sea posible para satisfacer la demanda de los usuarios que están descubriendo la nueva funcionalidad y la están adoptando masivamente. En esta fase hay que ser capaz de poner suficientes recursos en el proyecto para evitar morir de éxito
• Fase de consolidación. Una vez el crecimiento vertical acaba (siguiendo el ejemplo anterior, ya casi todos los usuarios han probado los vídeos con lo que no hay más incrementos masivos sinó más bien decrecimiento, estancamiento o como mucho un crecimiento más lineal) se trata de optimizar y conseguir maximizar el beneficio de esta nueva funcionalidad y hacerla sostenible en el tiempo.

En lugar de tener un único conjunto de métodos para todos los equipos, las métricas, métodos y técnicas a aplicar dependían de la fase del proyecto. Incluso la gente podía cambiar dependiendo de esto ya que algunos ingenieros eran muy buenos en las etapas iniciales donde había que “ir rápido y romper cosas” mientras que otros eran grandes optimizadores para ese momento en que ganar un 1% de eficiencia era vital.

Testing de código en Facebook

Como “evangelista” del testing, este aspecto (más que nada la poca importancia que se le daba al testing en Facebook) fue el que más le sorprendió.

En un producto de la magnitud de Facebook (en número de usuarios)  hay muchos problemas que sólo pasan en producción. Con lo que no vale la pena escribir tests ya que no servirán para detectar esos errores. En Facebook, si la mayor parte de tests para una funcionalidad sólo fallarían en producción simplemente se decide no escribir los tests. 

A cambio Facebook utiliza intensivamente otras técnicas para asegurar la calidad del código. Empezando por el code review, siguiendo por el despliegue incremental de la nueva funcionalidad (primero en algunos servidores, para que esté sólo disponible para un subconjunto de usuarios, que se van ampliando progresivamente) y acabando con un buen “monitoring” que permite saber con todo lujo de detalles como se comporta la funcionalidad en producción.

Además se obliga a que todas las funcionalidades se pueden desactivar muy fácilmente. Como es imposible testear la funcionalidad con todos los condicionantes que se pueden dar en producción se queire que, si se detecta que falla, se pueda anular immediatamente sin afectar nada más.

No hay recetas universales para el buen desarrollo de software

La experiencia ayudó a entender a Kent que él puede escribir buenas historias de buenas prácticas de desarrollo en contextos determinadas pero son eso, historias y no recetas que haya que seguir al pie de la letra.