Encontré un enlace a Choose Boring Technology de Dan McKinley a través de uno de los canales de Slack de mi comunidad. Me hizo pensar en la interconexión de: complejidad y deuda tecnológica, productividad y velocidad del desarrollador, cultura de ingeniería y toma de decisiones. En última instancia, llegué a la conclusión de que la cultura de la toma de decisiones (cómo se toman las decisiones) tiene una gran influencia en la productividad a largo plazo de la organización de ingeniería.

Primero, algunos aspectos destacados de Boring Technology. Los tres elementos clave que resuenan conmigo:

1. El costo de mantenimiento a largo plazo de una tecnología domina el costo total y supera con creces el beneficio de velocidad a corto plazo.

Tendemos a centrarnos en los beneficios de una nueva tecnología sin reconocer siempre por completo los costos continuos de mantenimiento, que a menudo dominan a largo plazo.

La forma en que nos comportamos realmente depende de lo que creas sobre qué término domina esta ecuación en el mundo real.

Si la tecnología es realmente costosa de operar, los costos dominan. Si la tecnología realmente hace una gran diferencia en lo fácil que es su trabajo, los beneficios dominan.

#48

2. La gente (a menudo) se vuelve muy obstinada sobre la elección de la base de datos...

Estoy incluido en esa lista de personas que son muy obstinadas, pero más por razones relacionadas con el hecho de que entiendo perfectamente cuánto tiempo y esfuerzo se necesita para desarrollar el conocimiento especializado requerido para comprender realmente un RDBMS en particular o una tecnología de almacenamiento de datos.

En mi experiencia es por aquí donde se salen las ruedas. La gente se vuelve loca y empieza a hacer sonar sus tambores de programador políglota. Hay algo en la idea de agregar una nueva base de datos que hace que la gente asalte la Bastilla, diciendo "no puedes impedir que usemos la mejor herramienta para el trabajo, hombre".

Y cuando las personas sucumben a este instinto, se dicen a sí mismas que les están dando libertad a los desarrolladores. Y claro, es libertad, pero es una definición muy estrecha de lo que es la libertad. #36

El punto aquí es que la opinión y la noción de libertad y/o satisfacción pueden dominar la narrativa de la elección de tecnología si no hay un proceso sólido para tomar decisiones.

3. En última instancia, nuestro objetivo al crear y mantener productos (sistemas) es respaldar un resultado comercial exitoso. No para construir tecnología sofisticada.

Volviendo a mi primera experiencia de puesta en marcha de SaaS: construimos Eloqua con tecnología aburrida: Visual Basic (no es broma, era el año 2000), SQL Server, IIS.

En esos primeros años, construí algunas herramientas aburridas (adivinaste, también en Visual Basic) para automatizar implementaciones y realizar monitoreo básico de puntos finales. (¡Era antes de la nube pública, gente!). Mi objetivo principal era ahorrarme tiempo y reducir los errores en las implementaciones: teníamos un equipo muy reducido y estas herramientas mejoraron sustancialmente nuestra eficiencia.

En 2008, ocho años después del ciclo de vida de la empresa, mi equipo de "Operaciones de producción" de nueve personas apoyó el centro de datos, todo el hardware y la experiencia en infraestructura, redes y bases de datos. Diariamente, vimos algunas decenas de millones de transacciones. En el cuarto trimestre de 2008, mantuvimos un tiempo de actividad del 99,998 %, y lo hicimos mientras reducíamos los costos, en esta pila de tecnología realmente aburrida.

Obviamente, esta pila aburrida en Eloqua se habría visto muy diferente si la hubiéramos construido con las tecnologías disponibles en los últimos cinco a diez años. Y habría habido beneficios significativos que podríamos haber visto con algunas tecnologías específicas. Pero con las tecnologías actuales disponibles, la facilidad de poner en marcha un nuevo servicio administrado debe sopesarse frente al costo total de propiedad a largo plazo.

Por lo tanto:

Debe tener un proceso para agregar tecnología a su pila que implique hablar con otras personas. #86

¿Cómo haces para tomar estas decisiones a escala de más de 20 equipos?

En FreshBooks, pasamos mucho tiempo trabajando en estas preguntas y, en última instancia, trabajamos para aportar claridad y sustancia al proceso de toma de decisiones utilizando:

• Documentación de ingeniería para documentar claramente la información y los procesos importantes que cambian lentamente y que son importantes para la organización.
• Un marco de toma de decisiones para ayudar a los equipos a comprender qué decisiones se pueden tomar a nivel de equipo frente a nivel organizacional y dónde ir para obtener documentación.
• Un Tech Radar interno que describe las herramientas, tecnologías que deben y no deben adoptarse
• Un proceso de solicitud de comentarios (RFC) para un marco para evaluar y recomendar nuevos enfoques o tecnologías
• Registros de decisiones de arquitectura (ADR) para documentar decisiones

Hace poco decidí dejar FreshBooks, pero tengo la esperanza de que estos enfoques colectivos conduzcan a decisiones duraderas, menor complejidad y mayor productividad. ( Amigos de FreshBooks: sean honestos y háganme saber cómo funciona... )

De vuelta a Eloqua. Hicimos nuestras aburridas elecciones tecnológicas por necesidad durante la mayor parte de la historia de la empresa. Creamos una nueva categoría, Automatización de marketing, pero teníamos una cultura que se percibía como (y probablemente era) baja en innovación técnica. No teníamos un sólido proceso de toma de decisiones, pero nuestras decisiones estaban fuertemente influenciadas por la necesidad de respaldar un flujo de ingresos empresarial B2B.

En última instancia, vendimos Eloqua y su pila de tecnología aburrida a Oracle por cerca de $ 900 millones. Estoy bastante seguro de que los ingresos recurrentes y la tasa de crecimiento de los ingresos fueron su interés clave en este acuerdo... y nuestras aburridas opciones tecnológicas simplemente pasaron la diligencia debida.