Elige tecnología aburrida (2015)

• Para el éxito de largo plazo de una empresa, conviene moderar la adopción de tecnologías nuevas y priorizar la tecnología probada (boring technology)
• Toda empresa tiene solo unos 3 tokens de innovación (innovation tokens), y consume uno cada vez que elige NodeJS, MongoDB o una herramienta emergente
• Las tecnologías probadas tienen bien conocidas tanto sus capacidades (capabilities) como sus modos de falla (failure modes), por lo que el riesgo de desconocidos desconocidos (unknown unknowns) propio de tecnologías nuevas es menor
• La elección tecnológica afecta a todo el equipo y la organización; por la carga operativa y cognitiva, suele convenir más una herramienta razonablemente buena para muchos problemas que la mejor herramienta para el trabajo
• Elegir la tecnología con cuidado les da a los ingenieros la libertad de concentrarse en problemas más grandes, y la tecnología por la tecnología misma no tiene sentido

---

Aceptar lo aburrido (Embrace Boredom)

• Toda empresa tiene alrededor de 3 tokens de innovación (innovation tokens) y su oferta permanece fija por un tiempo; puede aumentar algo cuando se logra estabilidad y madurez, pero existe una tendencia a sobreestimar cuántos se tienen
• Escribir un sitio web con NodeJS, usar MongoDB o adoptar una tecnología de descubrimiento de servicios con menos de un año desde su lanzamiento consume 1 token de innovación cada uno; escribir una base de datos propia es meterse en un gran problema
  • Estas decisiones pueden tener sentido si eres una consultora de JavaScript o una empresa de bases de datos, pero la mayoría de las empresas persiguen misiones mayores, como redefinir el comercio global o reinventar los pagos web; gastar atención limitada en innovaciones en áreas como ssh es el camino más rápido al fracaso o a retrasar el éxito
• "Aburrido (boring)" no es lo mismo que "malo (bad)"; también existen tecnologías aburridas y malas. Ejemplos de tecnologías aburridas y suficientemente buenas: MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• La ventaja de la tecnología aburrida no está solo en que se entienden bien sus capacidades (capabilities), sino también sus modos de falla (failure modes)
• En la elección tecnológica coexisten los known unknowns (por ejemplo, no saber cómo se comportará la base de datos cuando llegue a 100% de CPU) y los unknown unknowns (por ejemplo, no saber que el registro de estadísticas provocaría pausas de GC); cuanto más nueva es una tecnología, mucho mayor es la escala de sus unknown unknowns

Optimizar globalmente (Optimize Globally)

• Preferir tecnologías aburridas es un buen sesgo, pero no es el único factor; la elección tecnológica tiene un alcance (scope) que impacta al equipo, la organización y el sistema completo
• Agregar una tecnología tiene un costo: si ya usas Ruby y sumas Python, la complejidad supera el beneficio marginal, pero en discusiones como Python vs Scala o MySQL vs Redis suele ignorarse esa restricción y se grita "la mejor herramienta para el trabajo (best tool for the job)"
• La esencia del trabajo es mapear problemas de negocio al espacio de soluciones que ofrecen las elecciones de software; si elegir no tuviera costo, podrías escoger la herramienta localmente óptima para cada problema, pero en la realidad sí lo tiene
  • Ese costo es operaciones (operations) y, en menor medida, la carga cognitiva (cognitive overhead): monitoreo, pruebas unitarias, conocimiento necesario para corregir cosas, scripts de init, etc., todo eso se acumula rápido
• El problema con pensar en la "mejor herramienta para el trabajo" es que se mira tanto "mejor" como "trabajo" de forma miope: el trabajo real es mantener viva a la empresa, y la herramienta "mejor" es la que resulta la menos mala (least worst) para la mayor cantidad posible de problemas
• El costo de largo plazo de mantener estable un sistema supera por mucho las incomodidades durante su construcción, y los desarrolladores maduros y productivos entienden esto

A veces elegir tecnología nueva (Choose New Technology, Sometimes)

• Llevar la lógica anterior al extremo implicaría construir un sitio web solo con Java, lo cual no es realista; hace falta una forma de agregar herramientas nuevas a la caja
• Como una tecnología nueva termina teniendo impacto en toda la empresa, agregarla es una decisión que requiere visibilidad a nivel de toda la empresa (company-wide visibility); hace falta establecer la expectativa cultural de que "esto es algo que discutimos entre todos"
• La práctica más recomendable es preguntarse cómo resolveríamos el problema actual sin agregar una tecnología nueva; eso ayuda a detectar situaciones en las que el supuesto "problema" en realidad es solo que alguien quiere usar esa tecnología, y en ese caso hay que frenarlo de inmediato
  • Se puede llegar muy lejos con un conjunto pequeño de decisiones tecnológicas, y la respuesta real rara vez es "no se puede", sino más bien "sí se puede, pero es demasiado difícil"; si sientes que no puedes lograr la meta con los recursos actuales, probablemente no estás pensando con suficiente creatividad
• Ayuda documentar con claridad por qué resolver ese problema con el stack actual es excesivamente caro y difícil
• Elegir una tecnología nueva puede ser una adición pura (por ejemplo, agregar memcached porque no hay caché), o puede superponerse con algo existente o reemplazarlo; si es un reemplazo, hace falta dejar expectativas claras sobre la migración de la funcionalidad existente, y la política suele tomar la forma de comprometerse con una migración junto con un cronograma propuesto
  • La intención es mantener los restos en un nivel manejable y evitar la proliferación de soluciones localmente óptimas
• Este proceso no es pesado: unas cuantas preguntas para llenar como tarea y una reunión para discutirlas; si una tecnología o servicio nuevo pasa ese filtro sin problemas, entonces su incorporación es apropiada

Simplemente lanza (Just Ship)

• La programación políglota (polyglot programming) se vende con la promesa de que, si se les da a los desarrolladores libertad total para elegir herramientas, resolverán mejor los problemas, pero eso en el mejor de los casos es una definición ingenua del problema y, en el peor, razonamiento sincronizado; el toil cotidiano termina aplastando a los desarrolladores
• Justamente una elección tecnológica cuidadosa es lo que les da a los ingenieros la libertad de pensar en preguntas más grandes, y la tecnología por la tecnología misma es aceite de serpiente

Caso Etsy (nota al pie)

• Etsy sufrió mucho con este problema en sus inicios: después de contratar a muchos programadores de Python, trató de encontrarles algo que hacer y terminaron creando una capa intermedia sin sentido; eliminarla tomó años. Al mismo tiempo, la latencia de búsqueda en el percentil 90 era de unos 2 minutos. Etsy no fracasó, pero como no pudo lanzar nada durante años, su éxito se retrasó
• A la intersección entre tecnologías aburridas y malas a menudo se le llama "enterprise software", aunque eso puede ser inexacto
• Caso de los activity feeds de Etsy: se implementaron en una época en la que integraban casi todo con PHP, MySQL, Memcached y Gearman; fue mucho más complejo de implementar que con una herramienta como Redis, pero aun así era totalmente posible construirlo con ese stack
  • En los años siguientes, mientras la atención se movía a otros temas, el uso de activity feeds creció 20 veces, pero gracias a la plataforma compartida siguió funcionando bien sin cambios adicionales: una ventaja de largo plazo de la moderación en las decisiones tecnológicas
  • Pero esto no es absolutismo: consideraron práctico un activity feed basado en memcached, pero no iban a implementar búsqueda especializada con búsqueda facetada en PHP puro, así que Etsy usó Solr