Pídanle a cualquier lista de “los programas más importantes jamás creados” sus cuatro candidatos, y casi siempre aparecen los mismos: el sistema operativo, el correo electrónico, el procesador de texto y la hoja de cálculo. De los cuatro, la hoja de cálculo es la más extraña. Es, al mismo tiempo, la herramienta más liberadora jamás entregada a alguien sin formación de programador y el repositorio de lógica de negocio más grande y sin gobernanza del planeta. VisiCalc, luego Lotus 1-2-3, luego Excel, lograron algo que ningún compilador ni entorno de desarrollo ha logrado nunca: dejar que un analista financiero, un gerente de operaciones, un administrador escolar codificara conocimiento real de su dominio —modelos de precios, lógica de pronóstico, reglas de inventario— sin pedirle permiso a nadie y sin escribir una sola línea de lo que un programador reconocería como código. Ese es el regalo. Y también, por la ley de Emerson, es exactamente donde llega la factura.

I. La Compensación de Emerson, Aplicada al Software

El ensayo “Compensation” de Ralph Waldo Emerson, incluido en Essays: First Series, sostiene que toda ventaja en la naturaleza está gravada por un costo igual y opuesto: nada se obtiene gratis. La hoja de cálculo es un caso de manual, casi demasiado limpio para necesitar la teoría. Su virtud definitoria es que elimina toda barrera entre una idea y un cálculo funcionando: sin compilador, sin esquema, sin revisión de código, sin proceso de despliegue. Su pasivo definitorio es que elimina toda barrera entre una idea y un cálculo funcionando. La misma ausencia de fricción que le permite a un controller armar un modelo de tres estados financieros funcional en una tarde es la que permite que ese modelo se metastatice, sin comentarios ni control de versiones, hasta convertirse en el sistema de registro real del reconocimiento de ingresos de una división entera. Dan Bricklin construyó VisiCalc en 1979 para borrar el tedio de recalcular un libro contable a mano; no construyó, ni podía construir, nada que impidiera que ese libro contable se volviera silenciosamente crítico. La propuesta de valor completa de la herramienta es cero ceremonia. Su pasivo completo es inseparable de esa misma cero ceremonia. No se puede restar el impuesto sin restar el regalo, que es por lo que cuarenta años de “mejores hojas de cálculo” nunca desplazaron al original: todas intentan reincorporar la gobernanza, y la gobernanza es precisamente la fricción que el formato existe para eliminar.

II. Una Cacofonía de Hojas

Entren a casi cualquier empresa mediana o grande y pregunten dónde vive de verdad la lógica de negocio, y la respuesta honesta rara vez es el ERP ni las herramientas internas construidas por el equipo de ingeniería. Es un drive compartido, o una página de wiki que enlaza a un drive compartido, con cientos de hojas de cálculo: un modelo de precios con catorce pestañas y una cadena de búsquedas que nadie puede rastrear hasta su origen, un plan de dotación con valores pegados a mano sobre las fórmulas porque alguien tenía que “arreglarlo ya” antes de una reunión de directorio, una hoja de conciliación que solo una persona —usualmente alguien a pocos años de jubilarse— entiende de punta a punta. Cada hoja fue un acto razonable, incluso admirable, de iniciativa individual: alguien modeló un problema que nadie más había modelado, con la única herramienta que tenía permiso y formación para usar. La cacofonía no es el fracaso de ninguna hoja en particular. Es la propiedad emergente de miles de decisiones individualmente racionales tomadas sin esquema compartido, sin control de versiones, sin pruebas y sin un dueño único —más cerca de una ciudad que creció sin zonificación que de un sistema diseñado, en el sentido en que lo pensaba Jane Jacobs cuando describía los barrios que funcionan como la acumulación de decisiones individuales descoordinadas, no como un plan maestro.

Lo que está en juego no es hipotético. En 2012, el modelo de riesgo de una mesa de trading de JPMorgan —una hoja de cálculo, copiada y pegada a mano entre distintas pestañas— subestimó el riesgo de un conjunto de posiciones en derivados porque una fórmula dividía por la suma de dos valores en lugar de por su promedio, alimentando lo que terminó siendo conocido como la pérdida de la “Ballena de Londres”, más de seis mil millones de dólares. Un año antes, a un estudiante de posgrado llamado Thomas Herndon le encargaron replicar un paper de economía muy citado, “Growth in a Time of Debt” de Carmen Reinhart y Kenneth Rogoff, y descubrió que la conclusión central del paper sobre un umbral de deuda-crecimiento descansaba en parte sobre una fórmula de Excel que simplemente había excluido cinco países de un promedio, un error de hoja de cálculo que para entonces ya había moldeado años de debate público sobre políticas de austeridad. Ninguno de los dos errores involucró matemática incorrecta. Ambos involucraron una herramienta sin ningún mecanismo para que otra persona pudiera ver qué hacía realmente la fórmula.

III. Por Qué “Reescribirlo Bien” Fracasa

La solución obvia —extraer la lógica, construir una aplicación de verdad, jubilar la hoja de cálculo— es donde el principio de ingeniería sólida choca con un hecho incómodo sobre los tiempos. La hoja de cálculo de un experto de dominio rara vez es estática; se está editando en tiempo real para responder la pregunta de este trimestre, lo que la convierte en un blanco móvil para cualquiera que intente especificarla formalmente. Domain-Driven Design de Eric Evans descansa sobre la premisa de que el dominio debe guiar a la tecnología, que el modelo en el código debe seguir de cerca al modelo en la cabeza del experto de dominio. Esa premisa asume que el modelo del experto cambia a un ritmo que un equipo de desarrollo puede seguir. La hoja de cálculo rompe ese supuesto desde la raíz: para cuando un sistema bien diseñado logra capturar la versión 40 de la lógica de precios, el negocio ya pasó a la versión 47, y la hoja de cálculo “legacy”, todavía abierta en la pestaña del navegador de alguien, vuelve a ser la fuente de verdad real. El desarrollo de software formal corre en ciclos de entrega medidos en semanas. La lógica de negocio que vive en hojas de cálculo corre en la escala de tiempo de una sola reunión. Ese desajuste, más que cualquier deficiencia técnica de Excel en sí, es la razón por la que tantos proyectos de “migración de la hoja de cálculo” fracasan en silencio, consumen un presupuesto de dos años y terminan archivados apenas cambia el ejecutivo que los patrocinaba.

IV. La Decisión, No el Artefacto

El desajuste sugiere que “migrar la hoja de cálculo a un sistema de verdad” puede ser el enfoque equivocado desde el inicio —que trata al artefacto como la unidad de disciplina de ingeniería cuando la unidad real es el proceso de decisión que el artefacto simplemente registra. Un modelo de precios no es peligroso porque viva en un archivo .xlsx en lugar de una base de datos; es peligroso porque la secuencia de juicios que lo produjo —qué supuestos se probaron, qué números se sobreescribieron a mano, sobre qué versión se tomó realmente una decisión— no deja rastro en ningún lado. Un reemplazo bien diseñado que reproduce la lógica de la hoja de cálculo pero no su procedencia simplemente reubicó el cálculo sin tocar el riesgo real, que nunca fue la aritmética. Lo que tendría que cambiar no es el software sino la disciplina: historial de versiones y un registro de quién cambió qué y por qué, atado a la decisión y no atornillado a un formato de archivo diseñado, explícita y exitosamente, para no tener nada de eso. Ninguna herramienta se impuso masivamente sobre esa premisa, lo cual en sí mismo vale la pena notar: sugiere que el mercado, hasta ahora, valoró más el regalo de cero ceremonia que el miedo al costo sin gobernanza, hasta el momento en que una división descubre cuánto de su riesgo estaba sentado, sin auditar, en la pestaña del navegador que solo un analista a punto de jubilarse llegó a entender por completo.

Todavía le tengo una deuda real a Lotus 1-2-3, y no una abstracta. Mi primer trabajo pago como estudiante vino de una empresa chica que necesitaba llevar el control de materiales y costos; no podían pagarse nada parecido a un proceso de desarrollo formal, y su operación, en ese momento, era lo bastante simple como para no necesitarlo. Los convencí de usar una hoja de cálculo en lugar de una aplicación, y fue la decisión correcta, exactamente en la escala donde el regalo supera al costo. La deuda va una herramienta más atrás, hasta quien hizo posible que 1-2-3 existiera en primer lugar. Dan Bricklin, si alguna vez estás por Massachusetts y llegás a leer esto: el café lo pago yo.

Lecturas recomendadas