Con este post se abre una posible serie de posts de retrospectiva semanal sobre el trabajo de nuestro equipo. Las conclusiones que más suenan en mi cabeza pasan a estar escritas en el blog para que cuando las lea con el tiempo compruebe si hemos aprendido la lección o no.
La conclusión que me llevo de esta semana es que para que un equipo pequeño haga grandes cosas, todos deben ser capaces de enfrentar los problemas con la misma visión que el propietario de la empresa, además del punto de vista técnico. Con la visión de querer hacer ganar al equipo y a la empresa, de crecer (sea lo que sea que se entienda por crecimiento). Con una visión de todo el bosque, que no se pierde entre los árboles. A veces los técnicos trabajamos desde la perspectiva equivocada, un punto de partida inadecuado.
A veces porque las personas se creen sin permiso a sugerir propuesta de un calado más profundo y a veces porque no se dan cuenta que no todo tiene que resolverse escribiendo líneas de código.
El ejemplo de la semana:
Nos ha tocado hacer frente a un problema de rendimiento en la aplicación. No sabíamos por qué pero algunos usuarios sufrían ralentización y teníamos que arreglarlo cuanto antes. En la mayoría de los casos que he visto en mi vida, el cuello de botella está en el acceso a datos (yo diría 90%) pero también hay problemas de ancho de banda que salen a relucir cuando hay mala conexión a Internet, así como posibles problemas de renderizado en máquinas antiguas (había alguna CPU al 100%). Algunas personas con más conocimiento de la aplicación sugirieron cambiar la forma en que se renderizan contenidos para reducir la cantidad de información que se envía por la red (quitar algunos controles ASP.NET) ya que no se daba con el problema en base de datos. Empezamos a mirar el código y después de 3 horas vi que el trabajo no sólo era tremendo sino muy propenso a errores. Podíamos tardar semanas en cambiar toda la aplicación y sin garantías de estabilidad. Pero lo peor de todo: sin estar seguros de la ganancia que conseguiríamos. ¿Cómo vamos a invertir semanas sin tener ni la más remota idea del beneficio que podíamos conseguir? ¿sin saber realmente cuál era el cuello de botella? Más de uno se habría pegado tranquilamente los días haciendo ese trabajo sin más (no necesariamente de este equipo), total, como le pagan para programar…
Era mucho más rápido desplazarse hasta el cliente con una conexión 3G potente y un portátil de altas prestaciones para probar 2 cosas: Que ni el hardware ni el ancho de banda son problema. En caso que alguna de estas cosas fuese problema, es muchísimo mejor pagarle a nuestro cliente la conexión a internet y comprarle una máquina más potente para que pueda trabajar, en lugar de invertir semanas de trabajo de desarrollo.
Pero esta perspectiva sólo te viene a la cabeza si estas pensando en el dinero que va a suponer para la empresa tu decisión y tu capacidad resolutiva.
De aquí la importancia de cambiar de dimensión para ver los problemas de otro color. Según desde donde mires, te implicarás de una manera o de otra.
La otra gran lección que ha salido es que nunca nunca nunca se pueden hacer refactorings grandes en solitario, ni tan siquiera por 2 minutos, cuando no hay una gran batería de tests automáticos de respaldo. Llevaba años ya acostumbrado a tener mis tests y a hacer refactorings tranquilote y esta semana, me confié como si tuviera los tests e introduje varios bugs por refactorizar en solitario, a pesar de que fue por apenas unos minutos. Ya tenemos todos los puestos con doble teclado-ratón y doble pantalla y la ergonomía se ha mejorado así que no hay excusa para no sentarse en pareja a hacer refactoring. ¡Prohibido hacerlo en solitario!