Nadie sabe realmente cómo funciona un producto de software [traducción]

1. La opacidad de los sistemas de las grandes tecnológicas

• Incluso las grandes empresas tecnológicas operan sus propios sistemas dentro de una “niebla de guerra”.
• Solo unas pocas personas dentro de la organización pueden responder incluso preguntas básicas como “¿los usuarios de tipo Y pueden usar la función X?”, “¿qué ocurre exactamente al realizar la acción Z?” o “¿cuántos planes existen actualmente?”.
• En casos extremos, hay que asignar a alguien exclusivamente para investigarlo, aunque la respuesta debería poder obtenerse solo con la documentación pública, pero no es así.

2. El origen de la complejidad: Wicked Features

• El software grande se vuelve extremadamente complejo por funciones como self-hosting, pruebas gratuitas, controles de organización/políticas, localización multilingüe y capacidades de cumplimiento normativo. Estas funciones afectan a cada nueva función.
• Ejemplo: al agregar controles de políticas, hay que aplicarlos cada vez también a las nuevas funciones, y al localizar, las traducciones también deben acompañarlas.
• “Si un cliente enterprise con self-hosting en la región de la UE puede acceder a cierta función” solo puede comprobarse explorando directamente el código o mediante experimentos. Omitir este tipo de funciones implica renunciar a enormes ingresos, y ahí está una de las diferencias entre las empresas grandes y las pequeñas.

3. Los límites de la documentación

• En teoría, al lanzar una nueva función se podrían documentar sus interacciones, pero el sistema cambia más rápido que la documentación.
• En un entorno dinámico, no estático, quien documenta tendría que adelantarse a los cambios, y eso es prácticamente imposible.
• Un problema aún mayor: muchos comportamientos surgen por la interacción entre configuraciones predeterminadas, no por una intención explícita; documentar eso se parece a explorar el sistema real.

4. La clave de las respuestas: el codebase y los ingenieros

• Las respuestas exactas solo salen de mirar directamente el codebase, y esa es la base del poder de los ingenieros.
• La función central de un equipo de ingeniería es la capacidad de responder preguntas sobre el software.
• Se aprovecha el conocimiento tácito que vive en la cabeza de quienes conocen cierto código.
• Cuando se reorganiza un equipo, la pérdida de conocimiento obliga a hacer “cirugía exploratoria” (modificar código, forzar verificaciones, etc.).
• Es fácil escribir código, pero dar respuestas confiables es difícil por un tema de confianza (el riesgo de equivocarse y la necesidad de resumir y comprimir).

5. Conclusión: una capacidad valiosa

• Quienes no son técnicos creen que los ingenieros entienden perfectamente el software, pero nadie comprende por completo los sistemas grandes.
• Incluso las preguntas básicas requieren investigación repetida, y cuando hay cambios aparecen matices y excepciones. La capacidad de dar respuestas precisas tiene un valor enorme.