Los ingenieros no pueden cometer errores de startup al construir un ledger

 (news.alvaroduran.com)
1 puntos por GN⁺ 2024-11-30 | 1 comentarios | Compartir por WhatsApp
  • En fintech que maneja dinero real, incluso una diferencia de unos centavos puede destruir la confianza del usuario, y una startup de trading de acciones que registraba transacciones con un esquema de entrada única sufrió el problema de los dancing cents
  • Un ledger de entrada única solo deja registro de entradas y salidas de dinero, por lo que es difícil rastrear la causa de diferencias creadas por factores como divisas, el rounding to even del bróker o comisiones como la FINRA TAF
  • Un ledger de doble entrada asume que el dinero siempre se mueve de una cuenta a otra, y separa Accounts, Entries y Transactions para registrar juntos el origen y el destino
  • Si se definen con claridad los estados pending, discarded y posted de los Entries, así como las condiciones de publicación de las Transactions, se pueden manejar con más seguridad los fallos parciales y los Entries de compensación
  • El ledger es tanto una interfaz para reportes contables como el system of record que preserva la consistencia del dinero, por lo que al escalar crece la tensión entre disponibilidad y consistencia fuerte

Unos centavos de diferencia destruyeron la confianza del usuario

  • Una startup que estaba construyendo una plataforma de trading de acciones siguió el principio “make it work, make it right, make it fast” y no construyó desde el inicio un sistema contable de doble entrada
  • Poco después del lanzamiento, el monto reconocido por el proveedor y el monto reconocido por el sistema interno empezaron a diferir por unos centavos
    • Internamente lo llamaban dancing cents
    • Si un usuario compraba 5 dólares de acciones de Apple pero la orden aparecía como 4.98 dólares, de inmediato contactaba a soporte
  • La esencia del problema no era la pérdida monetaria, sino la confianza y el crecimiento
    • Los usuarios molestos no recomendaban el servicio, y el crecimiento de la startup se frenó
    • El CEO ordenó que, cuando ocurriera una transacción incorrecta, soporte compensara manualmente esos centavos
    • Incluso crearon un bot de Slack para procesarlo

El dinero no solo rastrea el saldo actual, también el valor futuro

  • Un ledger es un sistema para rastrear dinero
  • El dinero no representa solo un saldo actual; también se necesita para expresar valor que se recibirá o que se deberá entregar en el futuro
    • Conceptualmente, el dinero es un activo futuro
  • Registrar solo entradas y salidas como “el usuario pagó 5 dólares” o “el usuario pagó 6 dólares” no basta para explicar el flujo financiero real
  • Las transferencias bancarias son lentas para los estándares de internet, y muchos bancos las liquidan el siguiente día hábil
    • Cuando el pago se completa, aparece la certeza de que el dinero se recibirá en algún momento
    • Pero la acción debe comprarse ahora mismo a través del bróker
    • Hay que poder representar al mismo tiempo un monto pending que se liquidará días después y un monto que sale de inmediato hacia el bróker
  • En un esquema de entrada única, cuando ocurre un error es muy difícil hacer rollback, y en algunos casos límite ni siquiera se puede intentar

Por qué un ledger de entrada única impide depurar

  • Un ledger de entrada única puede mostrar el flujo de fondos, pero no puede explicar por qué ocurrió ese flujo
  • Para encontrar la causa de un movimiento de dinero específico, había que unir datos de varios modelos, y en algunos casos ni eso era posible
  • Un ledger de doble entrada deja registrado tanto lo que pasó como por qué pasó
    • Todo movimiento de dinero ocurre de una cuenta a otra
    • Se registra de qué cuenta salió cada centavo y a qué cuenta fue
  • El problema de los dancing cents era difícil de resolver en un sistema de entrada única
    • Era difícil saber si los centavos desaparecidos se debían al tipo de cambio
    • Podían deberse al rounding to even mechanism del bróker
    • Podían deberse a las FINRA TAF fees cobradas al final del día
  • Si no puedes entender cómo funciona el sistema, también es difícil eliminar los bugs

Modelo de datos del ledger: Accounts, Entries, Transactions

  • Muchos ingenieros, al rastrear dinero por primera vez, colocan el monto dentro del modelo de dominio
    • Por ejemplo, agregan una propiedad price a Order o una columna amount en la tabla expenses
    • Ese es el enfoque de balance as property
  • Este enfoque funciona rápido al principio, pero con el tiempo los reportes se vuelven complejos y lentos, y también se dificulta el procesamiento de pagos y el análisis
    • Si un trabajo nocturno de reportes tarda varias horas, este enfoque podría ser la causa de fondo
  • Conviene tratar el ledger como un modelo de datos separado del que puedan derivarse todas las transacciones financieras del sistema
  • Tres entidades forman la estructura básica
    • Accounts: buckets de valor y una perspectiva para ver cómo cambia ese valor con el tiempo
    • Entries: flujo de fondos entre cuentas, que siempre representa un intercambio de valor
    • Transactions: unidad que garantiza que los Entries estén correctamente emparejados y se procesen como corresponde

Estados e inmutabilidad de los Entries

  • Los Entries pueden tener tres estados: pending, discarded y posted
  • Un Entry siempre se crea en estado pending
    • El valor intercambiado
    • La dirección, ya sea credit o debit
    • La información de la account referenciada
  • Expresar la dirección del monto con valores positivos y negativos es un error común
  • Los Entries son inmutables por defecto, pero un Entry pending puede ser discarded para crear un Entry posted
  • Otra alternativa para revertir un Entry pending es crear un reversal Entry
    • Pero el enfoque de reversal Entry puede ensuciar el historial de la cuenta
    • Si se usa el estado discarded, al ver los Entries actuales basta con excluir los elementos con discarded_at configurado, sin perder el historial
  • En un sistema de doble entrada, la suma total de los credit Entries no descartados y la suma total de los debit Entries no descartados son iguales
    • Conceptualmente, significa que aunque se mueva el dinero dentro de los bolsillos, el total sigue siendo el mismo
  • Algunas cuentas especiales que representan el mundo exterior y se consolidan en el Profit and Loss statement son excepciones y no necesariamente pueden balancearse

Transactions y manejo de fallos parciales

  • Los Entries se crean en pares, y las Transactions garantizan que ese proceso avance según lo previsto
  • Una Transaction solo se marca como posted cuando sus Entries vinculados están en estado posted o discarded y han sido reemplazados por posted Entries
  • Una Transaction con fallo parcial puede revertirse semánticamente mediante compensating Entries
  • Este enfoque encaja bien con el Saga pattern
    • Saga intercambia atomicidad por disponibilidad
    • En lugar de transacciones lentas que bloquean varias tablas, divide el proceso en trabajos individuales más pequeños con checkpoints intermedios
    • Entre esos pasos, otras transacciones pueden trabajar, lo que mejora el throughput

Accounts y normal balance

  • Desde la perspectiva de una sola Account, el ledger se ve como un sistema de entrada única
    • Una Account tiene una relación uno a muchos con varios Entries
    • El saldo total debe coincidir con el valor agregado de los saldos individuales de los Entries vinculados
  • La forma de calcular el total cambia según el normal balance de la Account
  • Desde el punto de vista contable, debe evitarse asociar signos positivos o negativos al monto de un Entry
    • En algunas cuentas, un net credit es lo normal, y en otras, lo normal es un net debit
    • Por ejemplo, una cuenta bancaria de efectivo puede tener como normal un net debit, pero si queda sobregirada puede volverse negativa
  • Un normal credit balance significa que es normal que el total de credit Entries vinculados sea mayor que el total de debit Entries
  • Un normal debit balance significa lo contrario

Tensión entre el sistema contable y el sistema de ingeniería

  • En el ledger coexisten dos sistemas con requerimientos distintos
    • Accounting system: la interfaz del ledger vista desde afuera
    • Engineering system: la implementación con la que el ledger se mira a sí mismo
  • El accounting system expone datos agregados desde múltiples perspectivas
    • Reporting
    • Financial ratios
    • Business Intelligence
  • El engineering system debe garantizar la consistencia y exactitud de los datos
    • En una fintech, el ledger cumple el papel de source of truth, igual que el CRM para el equipo comercial
  • Escalar un ledger es difícil porque los requerimientos de ambos sistemas son distintos
    • El accounting system exige alta disponibilidad y baja latencia
    • El engineering system exige consistencia fuerte y validaciones schema-on-write

Materiales de contabilidad para desarrolladores

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-11-30
Opiniones de Hacker News

  • Me gustaría que se lo dijeran también a los clientes de Synapse. Desaparecieron millones de dólares.
    Los bancos tienen que cuadrar sus libros siguiendo reglas estrictas sobre adónde fue el dinero, pero las fintech normalmente montan su propio ledger encima de una o unas pocas cuentas FBO subyacentes donde agrupan el dinero de los clientes, para rastrear el saldo de cada cliente. En el caso de Synapse, la suma de los saldos de clientes en su propio ledger era mucho mayor que el saldo real de las cuentas FBO.
    Mucha gente sospecha fraude, pero yo apostaría a que simplemente era un ledger desordenado y lleno de bugs. Después de ver cómo es por dentro, creo que nunca pondría dinero en una cuenta de depósito de una fintech; mejor usar un banco de verdad. Aunque una fintech promocione que los depósitos están asegurados por la FDIC, eso solo te protege si quiebra el banco subyacente, no si la fintech deja de poder rastrear tu dinero.
    Referencia: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...

    • Desaparecieron 90 millones de dólares y quedaron congelados 250 millones de dólares. Buena parte de ese dinero podría haber sido la renta de alguien.
      Andreessen Horowitz invirtió en esto, y ellos son de los que libran una guerra total contra toda regulación gubernamental.
      https://finance.yahoo.com/personal-finance/synapse-bankruptc...
    • Cuando trabajaba en una empresa grande, había inconsistencias entre sistemas de transacciones que hacían que el dinero apareciera o desapareciera de la nada.
      Ya antes esperaba que la base de código fuera un desastre tan grande que no pudiéramos rastrear bien estas cosas, y discutí con un jefe que creía que todo funcionaba por arte de magia. Unos días después recibí un correo diciendo que empezaría una auditoría por discrepancias contables.
      JPMC propuso internamente usar criptomonedas para gestionar los flujos de efectivo de forma consistente, pero no sé hasta dónde llegaron realmente.
    • Synapse dice que los errores contables reales estaban del lado de Evolve, el banco. Eso incluía transacciones faltantes, débitos no reportados y casos en los que, al enviar transacciones en curso a Mercury, las descontaron incorrectamente en Synapse.
      https://lex.substack.com/p/podcast-what-really-happened-at-s...
    • Una vez desapareció dinero de mi cuenta de HSBC. Era un pago entre dos cuentas, pero las partidas dobles no cuadraban por una pequeña cantidad y no era fácil conciliarlas en los libros.
      Reclamé durante un tiempo, pero nunca lo reconocieron bien ni lo corrigieron. Sin pruebas, sospeché que quizá era algún robo interno sutil, pero la incompetencia parece una explicación más plausible.
    • Las instituciones bancarias reales también dan miedo. Por ejemplo, Vanguard tercerizó a India gran parte de su trabajo de desarrollo hace unos años.
      Un amigo que trabajó como administrador de sistemas en BoA dijo que tenían que conservar ciertos logs durante 7 años, pero cuando el disco empezaba a llenarse simplemente los borraban.

  • Una de las cosas que me tomó tiempo entender cuando empecé a trabajar en Google fue hacer concesiones de confiabilidad o exactitud en favor de la escalabilidad.
    Antes había creado sistemas de facturación o aplicaciones web OLTP pequeñas, y nunca se me había ocurrido siquiera plantear preguntas como pérdida de datos aceptable o una tasa de error distinta de cero. Más que el hecho de que, si procesas millones de solicitudes por segundo, algunas van a fallar, lo que me impactó fue la diferencia de actitud de ingeniería.
    Incluso en este momento, puede haber miles de personas que abrieron Gmail y no les cargó bien o recibieron un error 500. Nadie rastrea la causa, porque el usuario va a refrescar la página y seguir con su día. Por el contrario, aunque una durabilidad de almacenamiento de 99.99999% al año suene impresionante, si tienes 2,000 millones de clientes, 200 van a tener un día realmente pésimo.
    Pasar del hábito de investigar todos los errores en los logs a una forma de trabajar en la que todo está siempre un poco roto y primero se calcula el costo antes de arreglar algo fue bastante impactante.

    • Un nivel de durabilidad tan bajo ya no es de punta.
      Una regla práctica que he visto mucho a una escala similar es apuntar a 1 caso de pérdida de datos cada 100 años para toda la infraestructura. Normalmente el costo aumenta mucho menos de 10%, pero al diseñar algoritmos de ubicación de datos se necesita alguien que entienda combinatoria.
      Si necesitas entender este tema, el paper de copysets es un buen punto de partida.
    • Esto en general es cierto, pero también he visto a menudo lo contrario. En especial cuando gente de empresas de redes sociales, con una percepción muy laxa del fracaso, entra a trabajar en aplicaciones financieras; por lo general no sale bien.
    • Cuando estaba en Google, me asignaron temporalmente al equipo de Android para trabajar en la sincronización de contactos. El problema que tenía ocurría en una situación extremadamente rara y, al extraer datos agregados de producción, parecía que afectaría al 0.01% de los usuarios.
      Cuando presenté la solución y mencioné esa tasa de error, me preguntaron cómo podrían recuperarse esos 200 mil usuarios de Android. Como no había forma de recuperarlos y la sincronización de contactos simplemente quedaría rota, me dijeron que lo rediseñara.
      El número en sí te vuelve humilde. Sin duda hay ámbitos donde 99.99% es suficiente, pero también hay muchísimos donde no lo es.

  • En estos casos ayuda contratar a la gente correcta desde el principio. No puedes contratar a un montón de expertos en LeetCode y luego no preguntarles si pueden construir lo que realmente quieres construir, más allá de su capacidad para recordar estructuras de datos y algoritmos
    Si la gente sabe cómo se debe construir eso, no hace falta sacrificar el crecimiento y se hace bien desde el inicio
    A veces necesitas ingenieros con otra formación, como contabilidad, finanzas o biología. La parte más importante de mi carrera fue entender a fondo la industria de lo que estaba construyendo y conocer expertos del área capaces de hacer las preguntas que de verdad importan. Eso es resolver problemas y eso es ingeniería; el resto es programar/escribir código

    • Nunca había visto en HN un comentario que describiera mi día a día actual con una precisión tan aterradora y con el que estuviera totalmente de acuerdo
      Pasé la mayor parte de mi carrera en la intersección entre tecnología y finanzas, sobre todo en cumplimiento de impuestos sobre ventas y uso. En ese proceso no me di suficiente cuenta de cuánto me influyeron contadores, controllers y abogados
      Hace poco asesoré sobre el sistema de libro mayor de una startup bastante antigua, y me horrorizó ver cómo se ve un sistema contable cuando lo construyen ingenieros sin formación en finanzas ni contabilidad
      No hace falta encontrar a un contador-ingeniero mágico. Basta con sentar a un contador real junto al equipo de ingeniería durante el proceso de diseño. Después de terminar el diseño de la reestructuración completa, le pedí a un amigo CPA que lo revisara por completo; encontró huecos en algunos escenarios, pero en general estaba bien
      El dinero es un problema de ingeniería difícil. Porque el dinero trae consigo toda clase de rarezas humanas a su alrededor
    • Exacto. El libro mayor es conocimiento de dominio. Todo lo demás, incluida la optimización para alta carga, debe construirse encima de eso
    • En ciertos grupos hay una tendencia irritante a creer que la tecnología puede resolver todos los problemas. Como se valora la innovación por encima de todo, se alejan de los expertos

  • Esto vuelve a confirmar la importancia del conocimiento de dominio en el liderazgo de ingeniería. Si trabajas en una empresa financiera, necesitas entender algo de finanzas para tomar las decisiones técnicas y los compromisos correctos; lo mismo aplica al periodismo o al comercio
    Las organizaciones exitosas en las que trabajé siempre incluían preguntas no técnicas específicas del dominio en las entrevistas del equipo técnico. En cambio, algunos equipos técnicamente muy fuertes se tambaleaban por falta de perspectiva del dominio

    • Soy ingeniero de software y además CPA, así que tengo conocimiento de dominio. Pero no sé cómo encontrar trabajo donde pueda aplicarlo
      Donde sea que mire, parecen preferir mucho más a alguien con el doble de experiencia como ingeniero de software, aunque no tenga ningún conocimiento de dominio, que a alguien como yo con experiencia contable y una carrera relativamente corta en ingeniería de software. Me pregunto si habrá una forma de aprovechar esto de manera efectiva
    • Estoy de acuerdo con la idea, pero ayuda ver esas preguntas específicas del dominio simplemente como preguntas técnicas de otro campo técnico
      Las finanzas también son técnicas, la ingeniería mecánica también es técnica, y la gestión deportiva o la sociología también tienen un gran componente técnico. Mirar de forma amplia qué es la capacidad técnica genera la humildad necesaria para colaborar en distintos dominios
    • Desde que empecé a trabajar en una aseguradora, me di cuenta de que entender la industria de seguros es mucho más difícil que entender el codebase. Si el codebase se comporta raro, al menos puedes seguirlo con un debugger
    • No estoy tan seguro de eso. Siempre entendí que tener todo el conocimiento de dominio es función del product manager
      El trabajo del PM es verificar junto con ingeniería que los requisitos sean correctos y que el producto construido los cumpla. En un entorno ágil, esas conversaciones y validaciones ocurren en cada sprint, así que es difícil que algo pase demasiado tiempo sin filtrarse
      Si no hay PM, entonces el equipo de ingeniería necesita conocimiento profundo del dominio; pero si lo hay, no es responsabilidad de ingeniería. Es responsabilidad de la organización de producto

  • Para contar una historia vieja: nunca construí un sistema de contabilidad de partida doble, pero hace décadas construí un sistema de facturación en una startup de internet/telecomunicaciones cuyos ingresos crecieron hasta ocho cifras
    Como desarrollador joven, no sabía mucho y, por casualidad, desde el primer día terminé construyendo la lógica de facturación; para bien o para mal, la hice en dos lugares del sistema. Una página web de facturación para consumidores y un proceso backend separado que generaba facturas y procesaba pagos con tarjeta de crédito
    Mantener ambos sincronizados fue sorprendentemente difícil. Seguíamos iterando mientras quemábamos capital para encontrar respuesta del mercado, y se iban agregando nuevos productos y servicios, nuevos esquemas de descuentos y precios, cobro por uso, cobro mensual, primeras X veces gratis, pagador principal/subcuentas en cuentas empresariales, centros de costo definidos por el usuario, asignación de impuestos a esos centros de costo y distribución hasta el centavo. Cada vez aparecían nuevos pliegues y excepciones, y los números de las dos pantallas/formas no coincidían
    Como yo era el responsable de facturación, cada mes pasaba varios días revisando manualmente todas las facturas para comprobar, como revisión final antes de cobrar tarjetas de crédito y enviar facturas en papel, que los números cuadraran. Siempre, o al menos con frecuencia, encontraba algún problema nuevo que afectaba a uno o a unos pocos clientes, y corregía el código antes de la facturación real. Siempre me daba ansiedad soltarlo sin volver a verificar todo a mano
    Pensé en refactorizar la lógica de facturación para dejarla en un solo lugar y eliminar las discrepancias y la validación cruzada manual, pero después de darle muchas vueltas me di cuenta de que un único codebase me incomodaba y que, en realidad, tener dos codebases me ayudaba a detectar mis errores. Después fui haciendo cada vez más fácil la ejecución automática y la validación cruzada entre ambas implementaciones
    El código de facturación era algo desordenado como para presumirlo, pero estaba muy orgulloso de la precisión de la facturación, de la escasez de quejas y de los errores aterradores que evitamos durante años. Siento algo de culpa por la complejidad que dejé a mis sucesores, pero aún hoy no me arrepiento demasiado
    Después de esa experiencia, siempre entendí bien la motivación de la contabilidad de partida doble. Para evitar que mis errores perjudicaran a los clientes, terminé reinventando de forma rudimentaria un código de facturación con lógica doble

    • Cualquier cosa relacionada con facturación o dinero es demasiado fácil de hacer mal
      En una empresa anterior, el equipo de datos que me tocó liderar tenía la desafortunada costumbre de “perder” dinero. No era que el dinero real desapareciera mientras se movía a otro lugar; era que desaparecían los registros de lo que debíamos cobrar a los clientes
      Cuando no perdíamos ingresos, hacíamos cobros duplicados, y esto seguía ocurriendo. Recuperar la confianza de la dirección tomó 3 años de trabajo duro
    • Sin mala intención, pero suena como una pesadilla. Al mismo tiempo, lograr precisión pese a la complejidad del sistema es realmente excelente. Puedes sentirte orgulloso
    • Esto también se parece mucho a N-version programming

  • ¿Ni siquiera había pruebas? Si están perdiendo dinero en cada transacción al punto de dar el ejemplo de que “cada vez que se compraban 5 dólares, quedaban 4.98 dólares en el registro de transacciones”, el problema es mucho más grande que la ausencia de contabilidad por partida doble.
    ¿Quién construye un sistema financiero así y lo considera normal? La compensación también es un problema, pero si ese es el servicio, habría que salir corriendo lo antes posible.

    • Precisamente estas personas lo hicieron. Ellas mismas dijeron: “podríamos haberlo hecho bien, pero no lo hicimos”. No fue un accidente, fue una elección.
      Hacían bromas como “centavos bailarines”, y lo hicieron porque sabían que no tendrían que asumir consecuencias significativas. Se movieron rápido, rompieron algo —algo relacionado con dinero— y se rieron.
      Ahora intentan aleccionar a otros como si tuvieran autoridad moral y técnica por haber tomado deliberadamente esas decisiones. Es una basura increíblemente arrogante de cultura startup VC.
    • Todavía no entendieron cómo se perdió el dinero. La contabilidad por partida doble habría ayudado con el diagnóstico, pero ¿cómo desapareció realmente?
    • Pensé lo mismo. Un libro mayor tiene muchas ventajas, pero no corrige el problema de los centavos bailarines. Solo acabarían subiendo números incorrectos al libro mayor.
      Claro, podría dar pistas para encontrar el bug, pero escribir pruebas básicas habría hecho lo mismo.
    • Un buen principio de diseño vale tanto como 1000 pruebas.
    • ¿Cómo se determina si esa historia es cierta?

  • No entiendo por qué el autor presenta de forma negativa el dicho “make it work, make it right, make it fast”. Probablemente entendió mal dónde entra “make it fast”.
    “Make it right” es la segunda etapa, y el trabajo debería detenerse ahí antes de hacer que funcione correctamente. El sistema debe operar de manera sana. “Make it fast”, es decir, la optimización, solo empieza después de que los problemas de corrección y solidez estén completamente resueltos.
    Esto no tiene nada que ver con la velocidad de entrega ni con trabajar rápido; significa postergar la optimización hasta la etapa final.
    Dicho eso, si lo que el autor quería decir es que, aunque algo “funcione” a medias, puede estar tan lejos de ser “correcto” que después no se pueda volver atrás para arreglarlo, y que hay que hacerlo “bien” desde el principio antes incluso de que apenas empiece a funcionar, entonces se entiende.

    • Creo que la última oración es la correcta. El autor parece decir que en los sistemas de pagos no se puede hacer que primero funcione y luego hacerlo bien.
      Pienso lo mismo, y he participado en auditorías de sistemas fintech. Los auditores tenían que descargar todo a hojas de cálculo de Excel antes de aprobar los libros y cuadrar los números. Costó mucho tiempo y dinero, y sospecho que tres años después marcó una diferencia de al menos 0.1 unicornio en un evento de liquidez.
    • Creo que el autor eligió el dicho equivocado.
      En una startup que se mueve rápido se lanza, en la práctica, un MVP lo antes posible. Como hay que construir la base de clientes, las finanzas, etc., se quedan atorados en la etapa de “make it work”.
      Un mejor dicho habría sido el de Facebook: “move fast and break things”. Pero eso solo funciona cuando puedes arreglarlo después. Por ejemplo, si estuvieras construyendo aviones, no lo harías así.
    • Dijeron que el equipo de ingeniería seguía este dicho, y dentro de él está “make it right”. Pero no lo hicieron. Ni siquiera intentaron averiguar qué no sabían sobre fintech antes de construir el producto.
      Visto ese contexto, el malentendido mencionado en la primera oración parece lo más plausible. Justo después habla de la presión de tiempo que reciben las startups.

  • La mayoría de los comentarios aquí repiten exactamente lo que el artículo critica. Se ven innumerables discusiones largas defendiendo la contabilidad por partida simple.
    La partida simple puede ser más fácil y estar más generalizada, pero a veces es buena idea simplemente seguir sistemas y abstracciones que se desarrollaron a lo largo de siglos.
    Si no necesitas necesariamente otra cosa, es mejor usar contabilidad por partida doble. Puede incomodar al instinto de programador, pero lo agradecerás cuando llegue el momento de llamar a un contador real para ordenar las discrepancias.
    Relacionado con eso, ¿alguien conoce buenos recursos para programadores en pagos o áreas cercanas? Algo como “contabilidad para programadores”.

  • Si alguien te dijera que usa un sistema de base de datos en el que desaparece el 1% de los datos cada 10 transacciones, ¿podrías tomarte en serio estos consejos de blog de ingeniería? Este tipo de texto se siente menos como una introducción conceptual y más como un anuncio promocional de una persona o grupo específico, presentado con calma.

  • Para ver qué consecuencias tiene en personas reales esta actitud descuidada hacia el software que mueve dinero, basta mirar el escándalo de Post Office.
    https://en.wikipedia.org/wiki/British_Post_Office_scandal
    Todo lo que mueve dinero debe tratarse con la máxima seriedad, y hay que conocer tantos fracasos históricos como sea posible.