Engineer Tidak Bisa Melakukan Kesalahan ala Startup Saat Membangun Ledger

 (news.alvaroduran.com)
1 poin oleh GN⁺ 2024-11-30 | 1 komentar | Bagikan ke WhatsApp
  • Dalam fintech yang menangani uang sungguhan, selisih beberapa sen saja dapat meruntuhkan kepercayaan pengguna; sebuah startup perdagangan saham yang mencatat transaksi dengan metode single-entry mengalami masalah dancing cents
  • Karena ledger single-entry hanya menyisakan catatan uang masuk dan keluar, sulit melacak penyebab selisih seperti valuta asing, rounding to even oleh broker, atau biaya FINRA TAF
  • Ledger double-entry memandang uang selalu berpindah dari satu akun ke akun lain, dan memisahkan Accounts, Entries, serta Transactions untuk mencatat sumber dan tujuan sekaligus
  • Dengan menetapkan secara jelas status pending, discarded, posted pada Entries serta syarat posting untuk Transactions, kegagalan parsial dan Entries kompensasi dapat ditangani dengan lebih aman
  • Ledger adalah antarmuka untuk pelaporan akuntansi sekaligus system of record yang menjaga konsistensi uang, sehingga saat diskalakan, ketegangan antara ketersediaan dan konsistensi kuat semakin besar

Selisih Beberapa Sen yang Meruntuhkan Kepercayaan Pengguna

  • Sebuah startup yang membangun platform perdagangan saham mengikuti prinsip “make it work, make it right, make it fast” dan tidak membangun sistem akuntansi double-entry sejak awal
  • Tak lama setelah peluncuran, jumlah yang dikenali vendor dan jumlah yang dikenali sistem internal meleset beberapa sen
    • Secara internal, mereka menyebutnya dancing cents
    • Jika pengguna membeli saham Apple senilai 5 dolar tetapi pesanannya terlihat sebagai 4,98 dolar, mereka langsung menghubungi dukungan pelanggan
  • Inti masalahnya bukan pada jumlah kerugian, melainkan kepercayaan dan pertumbuhan
    • Pengguna yang marah tidak merekomendasikan layanan, dan pertumbuhan startup pun terhambat
    • CEO menginstruksikan agar dukungan pelanggan memberi kompensasi manual beberapa sen ketika terjadi transaksi yang salah
    • Mereka juga membuat bot Slack untuk menanganinya

Uang Melacak Bukan Hanya Saldo Saat Ini, tetapi Juga Nilai di Masa Depan

  • Ledger adalah sistem untuk melacak uang
  • Uang diperlukan bukan hanya sebagai saldo saat ini yang sederhana, tetapi juga saat mengekspresikan nilai yang akan diterima atau diberikan di masa depan
    • Secara konseptual, uang adalah aset masa depan
  • Jika hanya mencatat uang masuk dan keluar seperti “pengguna membayar 5 dolar” atau “pengguna membayar 6 dolar”, itu tidak cukup untuk menjelaskan alur keuangan yang sebenarnya
  • Transfer bank lambat menurut standar internet, dan banyak bank menyelesaikan transfer pada hari kerja berikutnya
    • Setelah pembayaran selesai, ada keyakinan bahwa uang akan diterima suatu saat nanti
    • Namun saham harus dibeli sekarang melalui broker
    • Jumlah pending yang akan diselesaikan beberapa hari kemudian dan jumlah yang langsung keluar ke broker harus dapat diekspresikan secara bersamaan
  • Dalam metode single-entry, rollback sangat sulit saat terjadi kesalahan, dan pada beberapa corner case, rollback bahkan tidak dapat dicoba

Mengapa Ledger Single-Entry Menghambat Debugging

  • Ledger single-entry dapat menunjukkan arus dana, tetapi tidak dapat menjelaskan sampai ke alasan mengapa arus itu terjadi
  • Untuk menemukan penyebab pergerakan uang tertentu, data dari beberapa model harus dirangkai, dan dalam sebagian kasus hal itu pun tidak mungkin
  • Ledger double-entry menyimpan apa yang terjadi dan mengapa itu terjadi secara bersamaan
    • Semua perpindahan uang terjadi dari satu akun ke akun lain
    • Setiap sen dicatat keluar dari akun mana dan masuk ke akun mana
  • Masalah dancing cents sulit diselesaikan dalam sistem single-entry
  • Jika tidak bisa memahami bagaimana sistem bekerja, bug juga sulit dihilangkan

Model Data Ledger: Accounts, Entries, Transactions

  • Banyak engineer, saat pertama kali melacak uang, memasukkan jumlah uang ke dalam model domain
    • Misalnya menaruh atribut price pada Order atau kolom amount pada tabel expenses
    • Ini adalah pendekatan balance as property
  • Pendekatan ini bekerja cepat pada awalnya, tetapi seiring waktu pelaporan menjadi rumit dan lambat, dan pemrosesan pembayaran serta analitik juga menjadi sulit
    • Jika pekerjaan laporan malam hari memakan waktu berjam-jam, pendekatan ini bisa menjadi akar masalahnya
  • Ledger sebaiknya diperlakukan sebagai model data terpisah yang dapat menurunkan semua transaksi keuangan dalam sistem
  • Tiga entitas membentuk struktur dasarnya
    • Accounts: bucket nilai sekaligus sudut pandang untuk melihat bagaimana nilai berubah dari waktu ke waktu
    • Entries: arus dana antar akun, dan selalu merepresentasikan pertukaran nilai
    • Transactions: unit yang memastikan Entries dipasangkan dan diproses dengan benar

Status dan Imutabilitas Entries

  • Entries dapat memiliki tiga status: pending, discarded, posted
  • Entry selalu dibuat dalam status pending
    • Nilai yang dipertukarkan
    • Arah, yaitu credit atau debit
    • Informasi account yang dirujuk
  • Mengekspresikan arah jumlah uang dengan angka positif dan negatif adalah kesalahan umum
  • Entries pada dasarnya immutable, tetapi Entry pending dapat dibuat discarded untuk membuat Entry posted
  • Ada juga alternatif membuat reversal Entry untuk membatalkan Entry pending
    • Namun metode reversal Entry dapat membuat riwayat akun menjadi berantakan
    • Dengan menggunakan status discarded, saat melihat Entries saat ini cukup mengecualikan item yang memiliki discarded_at, tanpa kehilangan riwayat
  • Dalam sistem double-entry, total credit Entries yang tidak discarded sama dengan total debit Entries yang tidak discarded
    • Secara konseptual, ini berarti berapa pun cara uang dipindahkan di dalam kantong, totalnya tetap sama
  • Beberapa akun khusus yang merepresentasikan dunia eksternal dan digabungkan ke dalam Profit and Loss statement merupakan pengecualian yang tidak bisa diseimbangkan

Transactions dan Penanganan Kegagalan Parsial

  • Entries dibuat berpasangan, dan Transactions memastikan proses tersebut berjalan sesuai maksud
  • Transaction hanya menjadi posted jika Entries terkait berada dalam status posted atau discarded dan telah digantikan oleh Entries posted
  • Transaction yang mengalami kegagalan parsial dapat dibalik secara semantik dengan compensating Entries
  • Pendekatan ini cocok dengan Saga pattern
    • Saga menukar atomicity dengan availability
    • Alih-alih transaksi lambat yang mengunci banyak tabel, proses dipecah menjadi pekerjaan individual yang lebih kecil dan checkpoint perantara
    • Di antaranya, transaksi lain dapat bekerja sehingga throughput meningkat

Accounts dan Normal Balance

  • Dari sudut pandang satu Account, Ledger terlihat seperti sistem single-entry
    • Satu Account memiliki relasi one-to-many dengan banyak Entries
    • Total saldo harus cocok dengan hasil agregasi saldo individual dari Entries yang terhubung
  • Cara menghitung total berbeda sesuai normal balance Account
  • Mengikat tanda positif/negatif pada jumlah Entry sebaiknya dihindari secara akuntansi
    • Untuk sebagian akun, net credit adalah kondisi normal; untuk akun lain, net debit adalah kondisi normal
    • Misalnya, akun kas bank dapat memiliki net debit sebagai kondisi normal, tetapi bisa menjadi negatif jika terjadi overdraft
  • Normal credit balance berarti kondisi dianggap normal ketika total credit Entries yang terhubung lebih besar daripada total debit Entries
  • Normal debit balance adalah kebalikannya

Ketegangan antara Sistem Akuntansi dan Sistem Engineering

  • Di dalam Ledger, dua sistem dengan kebutuhan berbeda hidup berdampingan
    • Accounting system: antarmuka Ledger yang dilihat dari luar
    • Engineering system: implementasi tentang bagaimana Ledger melihat dirinya sendiri
  • Accounting system mengekspos data yang diagregasi dari berbagai sudut pandang
    • Reporting
    • Financial ratios
    • Business Intelligence
  • Engineering system harus menjamin konsistensi dan akurasi data
    • Di perusahaan fintech, Ledger berperan sebagai source of truth, seperti CRM bagi tim sales
  • Alasan Ledger sulit diskalakan adalah karena kebutuhan kedua sistem tersebut berbeda
    • Accounting system menuntut availability tinggi dan latensi rendah
    • Engineering system menuntut konsistensi kuat dan pemeriksaan schema-on-write

Materi Akuntansi untuk Referensi Developer

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-30
Opini Hacker News

  • Saya ingin mengatakan hal yang sama kepada para pelanggan Synapse. Jutaan dolar lenyap
    Bank harus merekonsiliasi pembukuannya sesuai aturan ketat tentang ke mana uang pergi, tetapi fintech biasanya menaruh ledger mereka sendiri di atas satu atau beberapa rekening dasar FBO yang menampung uang nasabah secara gabungan, lalu melacak saldo tiap nasabah. Dalam kasus Synapse, total saldo nasabah di ledger mereka sendiri jauh lebih besar daripada saldo rekening FBO yang sebenarnya
    Banyak orang mencurigai penipuan, tetapi saya lebih berani bertaruh bahwa itu hanya ledger yang berantakan dan penuh bug. Setelah melihat bagian dalamnya, rasanya saya tidak akan pernah menaruh uang di rekening simpanan fintech; lebih baik memakai bank sungguhan. Meskipun fintech mengiklankan bahwa simpanannya diasuransikan FDIC, itu hanya melindungi ketika bank dasarnya bangkrut, bukan ketika fintech tidak lagi mampu melacak uang saya
    Referensi: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...

    • 90 juta dolar lenyap dan 250 juta dolar dibekukan. Sebagian besar uang itu mungkin adalah uang yang dibutuhkan seseorang untuk membayar sewa bulanan
      Andreessen Horowitz berinvestasi di sana, dan mereka adalah pihak yang memilih perang total terhadap semua regulasi pemerintah
      https://finance.yahoo.com/personal-finance/synapse-bankruptc...
    • Saat bekerja di perusahaan besar, pernah ada kejadian uang muncul atau hilang begitu saja karena ketidakkonsistenan antar sistem transaksi
      Sebelumnya saya sudah menduga codebase-nya terlalu berantakan sehingga hal-hal seperti ini tidak akan bisa dilacak dengan benar, dan saya berdebat dengan atasan yang percaya semuanya berjalan secara ajaib. Beberapa hari kemudian, saya menerima email bahwa audit atas ketidaksesuaian akuntansi akan dimulai
      JPMC pernah mengusulkan penggunaan cryptocurrency secara internal untuk mengelola arus kas secara konsisten, tetapi saya tidak tahu sejauh mana itu benar-benar berjalan
    • Synapse mengatakan kesalahan akuntansi yang sebenarnya ada di pihak bank, yaitu Evolve. Ini mencakup transaksi yang hilang, debit yang tidak dilaporkan, dan transaksi yang sedang berlangsung yang dikirim ke Mercury tetapi keliru didebitkan ke Synapse
      https://lex.substack.com/p/podcast-what-really-happened-at-s...
    • Saya pernah mengalami uang hilang dari rekening HSBC. Itu pembayaran antara dua rekening, tetapi entri ganda tidak cocok dengan selisih kecil, dan di pembukuan tidak bisa direkonsiliasi dengan mudah
      Saya mempermasalahkannya cukup lama, tetapi mereka tidak benar-benar mengakuinya dan juga tidak memperbaikinya. Tanpa dasar, saya sempat curiga itu mungkin pencurian halus dari orang dalam, tetapi ketidakmampuan tampaknya penjelasan yang lebih masuk akal
    • Institusi bank sungguhan pun sama-sama mengkhawatirkan. Misalnya, Vanguard beberapa tahun lalu mengalihdayakan sebagian besar pekerjaan pengembangannya ke India
      Seorang teman yang bekerja sebagai administrator sistem di BoA mengatakan bahwa log tertentu seharusnya disimpan selama 7 tahun, tetapi ketika disk mulai penuh, mereka langsung menghapusnya begitu saja

  • Salah satu hal yang butuh waktu untuk saya pahami ketika mulai bekerja di Google adalah kompromi antara keandalan atau akurasi demi skalabilitas
    Sebelumnya saya membuat sistem penagihan atau aplikasi web OLTP skala kecil, dan pertanyaan seperti kehilangan data yang dapat diterima atau tingkat kesalahan yang tidak nol tidak pernah terpikirkan. Yang lebih mengejutkan daripada fakta bahwa sebagian request akan gagal ketika menangani jutaan request per detik adalah perbedaan sikap engineering-nya
    Pada saat ini juga, mungkin ada sekitar ribuan orang yang membuka Gmail tetapi tidak termuat dengan benar atau menerima error 500. Tidak ada yang melacak penyebabnya, karena pengguna akan me-refresh dan melanjutkan hari mereka. Sebaliknya, meskipun durabilitas storage 99,99999% per tahun terdengar mengesankan, jika ada 2 miliar pelanggan, 200 orang akan benar-benar mengalami hari yang sangat buruk
    Peralihan dari kebiasaan menyelidiki setiap error di log ke cara berpikir bahwa semuanya selalu sedikit rusak dan biaya harus dihitung lebih dulu sebelum memperbaiki sesuatu terasa cukup mengejutkan

    • Tingkat durabilitas serendah itu sekarang bukan lagi tingkat modern
      Kaidah praktis yang sering saya lihat pada skala serupa adalah menargetkan 1 kejadian kehilangan data dalam 100 tahun untuk seluruh infrastruktur. Biasanya biayanya bertambah jauh kurang dari 10%, tetapi Anda membutuhkan orang yang memahami kombinatorika saat merancang algoritme penempatan data
      Jika perlu memahami bidang ini, paper copyset adalah titik awal yang bagus
    • Pernyataan ini umumnya benar, tetapi saya juga sering melihat kebalikannya. Terutama ketika orang-orang dari perusahaan media sosial yang punya rasa sangat longgar terhadap kegagalan masuk ke aplikasi finansial, dan biasanya hasilnya tidak berjalan baik
    • Saat di Google, saya pernah diperbantukan ke tim Android dan mengerjakan sinkronisasi kontak. Masalah yang saya hadapi adalah situasi yang sangat langka, dan ketika saya menarik data agregat produksi, tampaknya akan berdampak pada 0,01% pengguna
      Ketika saya mempresentasikan solusinya dan menyebutkan tingkat error itu, saya ditanya bagaimana 200 ribu pengguna Android tersebut bisa memulihkannya. Karena tidak ada cara untuk memulihkannya dan sinkronisasi kontak akan begitu saja rusak, saya diminta mendesain ulang
      Angka itu sendiri membuat saya rendah hati. Jelas ada area di mana 99,99% sudah cukup, tetapi ada sama banyaknya area di mana itu belum cukup

  • Hal seperti ini terbantu jika sejak awal merekrut orang yang tepat. Jangan merekrut banyak pakar LeetCode lalu hanya menanyakan kemampuan mereka membayangkan struktur data dan algoritma di kepala, tanpa menanyakan apakah mereka benar-benar bisa membangun sesuatu yang ingin dibangun
    Jika orang-orang tahu bagaimana objek itu seharusnya dibuat, pertumbuhan tidak perlu dikorbankan, dan sejak awal akan dibangun dengan benar
    Kadang kita membutuhkan engineer dengan latar pendidikan lain seperti akuntansi, keuangan, atau biologi. Bagian terpenting dalam karier saya adalah memahami secara mendalam industri dari hal yang saya bangun, dan mengenal pakar di bidang itu yang bisa mengajukan pertanyaan yang benar-benar penting. Itulah pemecahan masalah dan engineering; sisanya adalah programming/coding

    • Ini pertama kalinya saya melihat tulisan di HN yang menggambarkan keseharian saya saat ini dengan begitu menakutkan akurat, sekaligus membuat saya sepenuhnya setuju
      Sebagian besar karier saya dihabiskan di area pertemuan teknologi dan keuangan, terutama seputar kepatuhan pajak penjualan dan pajak penggunaan. Dalam proses itu, saya belum cukup menyadari seberapa besar akuntan, controller, dan pengacara memengaruhi saya
      Baru-baru ini saya memberi konsultasi untuk sistem ledger di sebuah startup yang sudah cukup lama berdiri, dan saya terkejut melihat seperti apa jadinya ketika engineer tanpa latar keuangan atau akuntansi membangun sistem akuntansi
      Tidak perlu mencari sosok ajaib yang sekaligus akuntan dan engineer. Cukup dudukkan akuntan sungguhan di samping tim engineering dalam proses desain. Setelah menyelesaikan rancangan perombakan total, saya meminta seorang teman CPA meninjaunya sepenuhnya; ia menemukan celah di beberapa skenario, tetapi secara umum cukup baik
      Uang adalah masalah engineering yang sulit. Karena uang membawa serta segala macam keanehan manusia di sekelilingnya
    • Benar. Ledger adalah pengetahuan domain. Semua hal lain, termasuk optimasi beban tinggi, harus dibangun di atasnya
    • Di sebagian kelompok ada kecenderungan menjengkelkan untuk percaya bahwa teknologi bisa menyelesaikan semua masalah. Karena inovasi dihargai di atas segalanya, mereka menjauh dari para ahli

  • Ini kembali menegaskan pentingnya pengetahuan domain dalam kepemimpinan engineering. Jika bekerja di perusahaan keuangan, Anda perlu memahami keuangan sampai tingkat tertentu agar bisa membuat keputusan teknis dan trade-off yang tepat; begitu juga dengan jurnalisme atau perdagangan
    Organisasi sukses tempat saya pernah bekerja selalu memasukkan pertanyaan nonteknis yang spesifik domain dalam wawancara tim teknis. Sebaliknya, beberapa tim yang secara teknis sangat hebat tersendat karena kurang wawasan domain

    • Saya software engineer sekaligus CPA, jadi saya punya pengetahuan domain. Namun saya tidak tahu bagaimana menemukan pekerjaan yang bisa menerapkannya
      Ke mana pun saya melihat, tampaknya mereka jauh lebih menyukai orang dengan pengalaman software engineering dua kali lebih lama, meski sama sekali tidak punya pengetahuan domain, dibanding saya yang punya karier akuntansi dan pengalaman software engineering yang relatif singkat. Saya penasaran apakah ada cara untuk memanfaatkannya secara efektif
    • Saya setuju dengan maksudnya, tetapi akan lebih membantu jika pertanyaan spesifik domain seperti itu juga dipandang sebagai pertanyaan teknis di area teknis lain
      Keuangan itu teknis, teknik mesin juga teknis, dan manajemen olahraga atau sosiologi pun memiliki unsur teknis yang besar. Jika kita memandang kompetensi teknis secara lebih luas, akan muncul kerendahan hati yang dibutuhkan untuk berkolaborasi di berbagai domain
    • Setelah mulai bekerja di perusahaan asuransi, saya menyadari bahwa memahami industri asuransi jauh lebih sulit daripada memahami codebase. Jika codebase berperilaku aneh, setidaknya kita bisa menelusurinya dengan debugger
    • Saya tidak yakin soal itu. Saya selalu memahami bahwa memiliki seluruh pengetahuan domain adalah peran product manager
      Tugas PM adalah memastikan bersama engineering bahwa requirement-nya benar dan produk yang dibuat memenuhi requirement tersebut. Dalam lingkungan agile, percakapan dan validasi seperti itu terjadi di setiap sprint, jadi sulit bagi sesuatu untuk lolos tanpa tersaring terlalu lama
      Jika tidak ada PM, tim engineering memang membutuhkan pengetahuan domain yang mendalam; tetapi jika ada, itu bukan tanggung jawab engineering. Itu tanggung jawab organisasi produk

  • Untuk cerita lama, saya memang belum pernah membuat sistem pembukuan berpasangan, tetapi puluhan tahun lalu saya pernah membangun sistem penagihan di startup internet/telekomunikasi yang pendapatannya tumbuh hingga delapan digit
    Sebagai developer muda saya tidak begitu paham, dan kebetulan sejak hari pertama saya langsung membuat logika penagihan; baik atau buruk, saya membuatnya di dua tempat dalam sistem. Satu adalah halaman web penagihan untuk konsumen, dan satu lagi proses backend terpisah yang membuat invoice serta menjalankan pembayaran kartu kredit
    Menjaga keduanya tetap selaras ternyata sangat sulit. Kami terus melakukan iterasi sambil membakar modal untuk mencari respons pasar, dan fitur-fitur baru terus ditambahkan: produk dan layanan baru, diskon dan skema harga baru, penagihan berbasis penggunaan, penagihan bulanan, X kali pertama gratis, pembayar utama/sub-akun untuk akun perusahaan, cost center yang ditentukan pengguna, alokasi pajak dan pembagian sampai satu sen ke cost center tersebut. Setiap kali, muncul kerumitan dan pengecualian baru sehingga angka di dua layar/cara itu tidak cocok
    Karena saya yang bertanggung jawab atas penagihan, setiap bulan saya menghabiskan beberapa hari menelusuri semua invoice secara manual, memeriksa apakah angkanya cocok sebagai pemeriksaan akhir sebelum pembayaran kartu kredit dan pengiriman invoice kertas. Selalu, atau setidaknya sering, saya menemukan masalah baru yang memengaruhi satu atau segelintir pelanggan, lalu memperbaiki kodenya sebelum penagihan benar-benar dilakukan. Saya selalu cemas untuk melepasnya tanpa mengecek ulang semuanya secara manual
    Saya sempat mempertimbangkan untuk me-refactor logika penagihan menjadi satu tempat demi menghilangkan ketidaksesuaian dan validasi silang manual, tetapi setelah lama memikirkannya saya menyadari bahwa satu codebase membuat saya tidak nyaman, dan justru dua codebase membantu menangkap kesalahan saya. Setelah itu, saya semakin mempermudah eksekusi otomatis dan validasi silang antara dua implementasi tersebut
    Kode penagihannya memang agak berantakan untuk dibanggakan, tetapi saya sangat bangga pada akurasi penagihan, minimnya keluhan, dan kesalahan-kesalahan mengerikan yang berhasil dihindari selama bertahun-tahun. Saya sedikit merasa bersalah atas kompleksitas yang saya tinggalkan kepada penerus, tetapi sampai sekarang saya tidak terlalu menyesal
    Setelah pengalaman itu, saya selalu memahami motivasi di balik pembukuan berpasangan. Dengan cara yang payah, saya seolah menemukan kembali kode penagihan berlogika ganda untuk mencegah kesalahan saya merugikan pelanggan

    • Penagihan atau apa pun yang melibatkan uang terlalu mudah salah
      Tim data yang pernah saya pimpin di perusahaan lama punya kebiasaan sial “menghilangkan” uang. Bukan berarti uang sungguhan lenyap saat berpindah ke tempat lain, melainkan catatan yang seharusnya digunakan untuk menagih pelanggan yang hilang
      Ketika tidak kehilangan pendapatan, mereka justru melakukan penagihan ganda, dan hal seperti ini terus terjadi. Butuh kerja keras selama 3 tahun untuk merebut kembali kepercayaan manajemen
    • Tanpa bermaksud buruk, itu terdengar seperti mimpi buruk. Pada saat yang sama, mencapai akurasi meski kompleksitas sistem seperti itu benar-benar luar biasa. Anda boleh bangga
    • Ini juga sangat mirip dengan N-version programming

  • Tidak ada pengujian juga? Kalau sampai kehilangan uang di setiap transaksi, misalnya “setiap kali membeli 5 dolar, log transaksi menyisakan 4,98 dolar”, masalahnya jauh lebih besar daripada tidak adanya pembukuan berpasangan.
    Siapa yang membangun sistem finansial seperti itu lalu menganggapnya normal? Kompensasi memang masalah, tetapi kalau layanannya seperti itu, sebaiknya kabur secepat mungkin.

    • Ya, orang-orang inilah yang melakukannya. Mereka sendiri berkata, “kami bisa saja membuatnya dengan benar, tetapi tidak melakukannya.” Itu bukan kecelakaan, melainkan pilihan.
      Mereka membuat lelucon seperti “sen yang menari”, dan melakukannya karena tahu mereka tidak perlu menanggung konsekuensi yang berarti. Mereka bergerak cepat, merusak sesuatu—sesuatu yang terkait uang—lalu menertawakannya.
      Sekarang mereka mencoba mengajari orang lain seolah-olah memiliki otoritas moral dan teknis justru karena mereka sengaja mengambil keputusan seperti itu. Ini omong kosong ala budaya startup VC yang luar biasa arogan.
    • Mereka masih belum memahami bagaimana uang itu hilang. Pembukuan berpasangan mungkin membantu diagnosis, tetapi secara nyata bagaimana uangnya bisa menghilang?
    • Saya juga berpikir begitu. Ledger punya banyak kelebihan, tetapi tidak memperbaiki masalah sen yang menari. Angka yang salah hanya akan masuk ke ledger.
      Tentu saja itu bisa menjadi petunjuk untuk menemukan bug, tetapi menulis pengujian dasar pun seharusnya memberi hasil yang sama.
    • Satu prinsip desain yang baik bernilai setara dengan 1000 pengujian.
    • Bagaimana cara menilai apakah cerita itu benar?

  • Saya tidak mengerti mengapa penulis membawa pepatah “make it work, make it right, make it fast” dalam nada negatif. Mungkin ia salah memahami di mana posisi “make it fast”.
    “Make it right” adalah tahap kedua, dan pekerjaan harus berhenti di sana sebelum sistem dibuat berjalan dengan benar. Sistem harus beroperasi secara sehat. “Make it fast”, yaitu optimisasi, baru dimulai setelah masalah akurasi dan kesehatan sistem benar-benar terselesaikan.
    Ini tidak ada hubungannya dengan kecepatan pengiriman atau bekerja cepat; maksudnya adalah menunda optimisasi ke tahap terakhir.
    Namun, jika yang ingin dikatakan penulis adalah bahwa untuk sesuatu tertentu, meskipun secara kasar “berfungsi”, ia bisa terlalu jauh dari “benar” sehingga tidak bisa diperbaiki belakangan, dan harus dibuat “benar” sejak awal bahkan sebelum mulai sekadar berfungsi, saya bisa memahaminya.

    • Menurut saya kalimat terakhir itu benar. Sepertinya penulis mengatakan bahwa dalam sistem pembayaran, Anda tidak bisa membuatnya berfungsi dulu lalu membuatnya benar belakangan.
      Saya juga sependapat, dan pernah terlibat dalam audit sistem fintech. Para auditor harus mengunduh semuanya ke spreadsheet Excel sebelum menyetujui pembukuan dan mencocokkan angkanya. Itu memakan banyak waktu dan uang, dan saya menduga tiga tahun kemudian pada event likuiditas, dampaknya setidaknya sekitar 0,1 unicorn.
    • Menurut saya penulis memilih pepatah yang salah.
      Di startup yang bergerak cepat, mereka merilis MVP secara de facto secepat mungkin. Karena harus membangun basis pelanggan, keuangan, dan sebagainya, mereka berhenti di tahap “make it work”.
      Pepatah yang lebih tepat mungkin milik Facebook: “move fast and break things”. Namun itu hanya berhasil jika hal yang rusak bisa diperbaiki nanti. Misalnya, kalau membuat pesawat, Anda tidak akan melakukannya begitu.
    • Mereka mengatakan tim engineering mengikuti pepatah ini, dan di dalamnya ada “make it right”. Namun mereka tidak melakukannya. Bahkan mereka tidak mencoba mencari tahu apa yang tidak mereka ketahui tentang fintech sebelum membangun produk.
      Melihat konteksnya, kesalahpahaman yang disebut pada kalimat pertama tampak paling mungkin. Sebab tepat setelah itu mereka membahas tekanan waktu yang diterima startup.

  • Sebagian besar komentar di sini justru mengulangi hal yang dikritik artikel tersebut. Saya melihat banyak perdebatan panjang yang membela pembukuan tunggal.
    Pembukuan tunggal mungkin lebih mudah dan lebih umum, tetapi terkadang mengikuti sistem dan abstraksi yang telah berkembang selama berabad-abad adalah ide yang baik.
    Kalau tidak benar-benar membutuhkan sesuatu yang berbeda, lebih baik gunakan pembukuan berpasangan. Naluri programmer mungkin merasa tidak nyaman, tetapi ketika tiba saatnya Anda harus memanggil akuntan sungguhan untuk membereskan ketidaksesuaian, Anda akan berterima kasih.
    Terkait hal ini, apakah ada yang tahu sumber bagus untuk programmer di bidang pembayaran atau bidang yang berdekatan? Semacam “akuntansi untuk programmer”.

  • Kalau seseorang mengatakan mereka memakai sistem database yang menghilangkan 1% data setiap 10 transaksi, apakah Anda bisa menganggap serius saran di blog engineering seperti ini? Tulisan seperti ini terasa lebih seperti iklan promosi untuk individu atau kelompok tertentu yang dikemas dengan tenang, bukan pengantar konsep.

  • Untuk melihat akibat nyata dari sikap ceroboh seperti ini terhadap perangkat lunak yang memindahkan uang, lihat skandal Post Office.
    https://en.wikipedia.org/wiki/British_Post_Office_scandal
    Segala sesuatu yang memindahkan uang harus diperlakukan seserius mungkin, dan kita harus mengetahui sebanyak mungkin kegagalan historis.