Mühendisler Ledger oluştururken startup tarzı hatalar yapamaz

 (news.alvaroduran.com)
1 puan yazan GN⁺ 2024-11-30 | 1 yorum | WhatsApp'ta paylaş
  • Gerçek parayla çalışan fintech’lerde birkaç sentlik fark bile kullanıcı güvenini sarsar; işlemleri tek giriş yöntemiyle kaydeden bir hisse alım satım startup’ı dancing cents sorununu yaşadı
  • Tek girişli ledger, yalnızca paranın giriş ve çıkışını bıraktığı için döviz, broker’ın rounding to even uygulaması, FINRA TAF ücretleri gibi farkı yaratan nedenleri izlemek zordur
  • Çift girişli ledger, paranın her zaman bir hesaptan başka bir hesaba hareket ettiğini kabul eder ve Accounts, Entries, Transactions yapılarını ayırarak kaynak ile hedefi birlikte kaydeder
  • Entries için pending, discarded, posted durumları ve Transactions için yayımlanma koşulları net tanımlanırsa kısmi hatalar ve telafi edici Entries daha güvenli ele alınabilir
  • Ledger, muhasebe raporlaması için bir arayüz olduğu kadar paranın tutarlılığını koruyan bir system of record olduğundan, ölçeklenme sürecinde erişilebilirlik ile güçlü tutarlılık arasındaki gerilim artar

Birkaç sentlik farkın yıktığı kullanıcı güveni

  • Bir hisse alım satım platformu geliştiren startup, “make it work, make it right, make it fast” ilkesini izledi ve en baştan çift girişli muhasebe sistemi kurmadı
  • Lansmandan hemen sonra tedarikçinin gördüğü tutarlar ile iç sistemin gördüğü tutarlar birkaç sent sapmaya başladı
    • Şirket içinde buna dancing cents deniyordu
    • Kullanıcı Apple hissesinden 5 dolarlık aldığında sipariş 4,98 dolar görünürse hemen müşteri desteğine yazıyordu
  • Sorunun özü kaybedilen tutardan çok güven ve büyüme idi
    • Öfkeli kullanıcılar servisi tavsiye etmiyordu ve startup’ın büyümesi tıkanıyordu
    • CEO, hatalı işlem olduğunda müşteri desteğinin birkaç senti manuel olarak telafi etmesini istedi
    • Bunu yönetmek için bir Slack botu da yapıldı

Para yalnızca mevcut bakiyeyi değil gelecekteki değeri de izler

  • Ledger, parayı izleyen bir sistemdir
  • Para, yalnızca mevcut bakiye değil, gelecekte alınacak veya verilecek değeri ifade etmek için de gerekir
    • Kavramsal olarak para gelecekteki bir varlıktır
  • “Kullanıcı 5 dolar ödedi”, “kullanıcı 6 dolar ödedi” gibi yalnızca giriş-çıkış kaydetmek gerçek finansal akışı açıklamak için yetersizdir
  • Banka transferleri internet standartlarına göre yavaştır ve birçok banka transferi bir sonraki iş gününde mutabakata bağlar
    • Ödeme tamamlanınca bir gün paranın alınacağına dair güven oluşur
    • Ancak hisse senedinin broker üzerinden şimdi alınması gerekir
    • Birkaç gün sonra mutabakata bağlanacak pending tutar ile broker’a hemen çıkan tutarı aynı anda ifade etmek gerekir
  • Tek girişli yöntemde hata olduğunda rollback çok zordur ve bazı köşe durumlarında rollback denemesi bile yapılamaz

Tek girişli ledger neden debugging’i engeller?

  • Tek girişli ledger fon akışını gösterebilir, ancak bu akışın neden gerçekleştiğini açıklayamaz
  • Belirli bir para hareketinin nedenini bulmak için birden fazla modeldeki verileri birleştirmek gerekiyordu; bazı durumlarda bu bile mümkün değildi
  • Çift girişli ledger, ne olduğunu ve neden olduğunu birlikte saklar
    • Her para hareketi bir hesaptan başka bir hesaba gerçekleşir
    • Her sentin hangi hesaptan çıkıp hangi hesaba gittiği kaydedilir
  • dancing cents sorununu tek girişli sistemde çözmek zordu
    • Kaybolan birkaç sentin dövizden kaynaklanıp kaynaklanmadığını bilmek zordu
    • Broker’ın rounding to even mechanism nedeniyle olabilir
    • Gün sonunda tahsil edilen FINRA TAF fees nedeniyle olabilir
  • Sistemin nasıl çalıştığı anlaşılamazsa hataları ortadan kaldırmak da zordur

Ledger veri modeli: Accounts, Entries, Transactions

  • Birçok mühendis parayı ilk izlemeye başladığında tutarı domain modelinin içine koyar
    • Order’a price özelliği koymak veya expenses tablosuna amount sütunu eklemek gibi
    • Bu, balance as property yaklaşımıdır
  • Bu yöntem başlangıçta hızlı çalışır; ancak zamanla raporlama karmaşık ve yavaş hale gelir, ödeme işleme ve analiz de zorlaşır
    • Gece çalışan rapor işleri saatler sürüyorsa temel neden bu yaklaşım olabilir
  • Ledger’ı, sistemdeki tüm finansal işlemlerin türetilebildiği ayrı bir veri modeli olarak ele almak daha iyidir
  • Üç entity temel yapıyı oluşturur
    • Accounts: Değer kovalarıdır ve değerin zaman içinde nasıl değiştiğine bakılan perspektiftir
    • Entries: Hesaplar arasındaki fon akışıdır ve her zaman değer değişimini temsil eder
    • Transactions: Entries’nin doğru eşleşmesini ve işlenmesini güvence altına alan birimdir

Entries durumları ve değişmezlik

  • Entries, pending, discarded, posted olmak üzere üç duruma sahip olabilir
  • Entry her zaman pending durumunda oluşturulur
    • Değiştirilen değer
    • Yön olan credit veya debit
    • Referans verdiği account bilgisi
  • Tutarın yönünü pozitif ve negatif sayılarla ifade etmek yaygın bir hatadır
  • Entries temelde değişmezdir; ancak pending Entry, posted Entry oluşturmak için discarded yapılabilir
  • pending Entry’yi geri almak için reversal Entry oluşturmak da bir alternatiftir
    • Ancak reversal Entry yaklaşımı hesap geçmişini dağınık hale getirebilir
    • discarded durumu kullanılırsa mevcut Entries görüntülenirken discarded_at ayarlanmış öğeleri hariç tutmak yeterlidir ve geçmiş de kaybolmaz
  • Çift girişli sistemde discarded edilmemiş credit Entries toplamı ile discarded edilmemiş debit Entries toplamı eşittir
    • Kavramsal olarak bu, parayı cebinizin içinde nasıl taşırsanız taşıyın toplam tutarın aynı kalması demektir
  • Dış dünyayı temsil eden ve Profit and Loss statement içinde birleştirilen bazı özel hesaplar istisnai olarak dengelenemeyebilir

Transactions ve kısmi hata yönetimi

  • Entries çiftler halinde oluşturulur ve Transactions bu sürecin amaçlandığı gibi ilerlemesini sağlar
  • Transaction, bağlı Entries posted veya discarded durumundaysa ve posted Entries ile değiştirilmişse ancak o zaman posted olur
  • Kısmi hata yaşayan bir Transaction, compensating Entries ile anlamsal olarak geri alınabilir
  • Bu yaklaşım Saga pattern ile iyi uyumludur
    • Saga, atomikliği erişilebilirlikle takas eder
    • Birden fazla tabloyu kilitleyen yavaş transaction’lar yerine süreci daha küçük bağımsız işlere ve ara kontrol noktalarına böler
    • Bu arada başka transaction’lar çalışabildiği için throughput artar

Accounts ve normal balance

  • Tek bir Account açısından bakıldığında Ledger tek girişli sistem gibi görünür
    • Bir Account, birçok Entries ile bire-çok ilişkiye sahiptir
    • Toplam bakiye, bağlı Entries’nin ayrı bakiyelerinin toplamıyla uyuşmalıdır
  • Account’un normal balance değerine göre toplam tutarın hesaplanma yöntemi değişir
  • Entry tutarına pozitif/negatif işaret bağlamak muhasebe açısından kaçınılması gereken bir şeydir
    • Bazı hesaplarda net credit normaldir, bazılarında net debit normaldir
    • Örneğin banka nakit hesabında net debit normal olabilir; ancak hesap aşırı çekilirse negatif olabilir
  • normal credit balance, bağlı credit Entries toplamının debit Entries toplamından büyük olmasının normal olduğu anlamına gelir
  • normal debit balance bunun tersidir

Muhasebe sistemi ile mühendislik sistemi arasındaki gerilim

  • Ledger içinde farklı gereksinimlere sahip iki sistem bir arada bulunur
    • Accounting system: Ledger’ın dışarıdan görünen arayüzü
    • Engineering system: Ledger’ın kendisini gördüğü uygulama
  • Accounting system, çeşitli perspektiflerden toplanmış verileri sunar
    • Reporting
    • Financial ratios
    • Business Intelligence
  • Engineering system, verinin tutarlılığını ve doğruluğunu güvence altına almalıdır
    • Fintech şirketlerinde Ledger, satış ekibinin CRM’i gibi source of truth rolü üstlenir
  • Ledger’ı ölçeklemenin zor olmasının nedeni, iki sistemin gereksinimlerinin birbirinden farklı olmasıdır
    • Accounting system yüksek erişilebilirlik ve düşük gecikme ister
    • Engineering system güçlü tutarlılık ve schema-on-write kontrolleri ister

Geliştiricilerin bakabileceği muhasebe kaynakları

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-30
Hacker News yorumları

  • Bunu bir de Synapse müşterilerine söylemeyi denesinler. Milyonlarca dolar kayboldu.
    Bankalar, paranın nereye gittiğini katı kurallara göre defterlerinde mutabık kılmak zorunda; ancak fintech’ler genellikle müşteri parasını topladıkları bir veya birkaç temel FBO hesabının üzerine kendi ledger’larını koyup her müşterinin bakiyesini izler. Synapse vakasında, kendi ledger’ındaki müşteri bakiyelerinin toplamı gerçek FBO hesap bakiyesinden çok daha yüksekti.
    Pek çok kişi dolandırıcılıktan şüpheleniyor ama ben bunun sadece berbat ve bol hatalı bir ledger olma ihtimaline para yatırırdım. İçini gördükten sonra bir fintech mevduat hesabına asla para koymam herhalde; gerçek bir banka kullanmak daha iyi. Fintech, mevduatların FDIC sigortası kapsamında olduğunu söylese bile bu yalnızca alttaki banka batarsa korur; fintech’in paramı takip edemez hâle gelmesi durumunu korumaz.
    Referans: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...

    • 90 milyon dolar kayboldu ve 250 milyon dolar donduruldu. O paranın önemli bir kısmı, birilerinin kirası için ihtiyaç duyduğu para olabilir.
      Andreessen Horowitz yatırım yapmıştı; bunlar tüm hükümet düzenlemelerine karşı topyekûn savaş yürütme tarafında.
      https://finance.yahoo.com/personal-finance/synapse-bankruptc...
    • Büyük bir şirkette çalışırken işlem sistemleri arasında tutarsızlık yüzünden paranın yoktan var olduğu ya da ortadan kaybolduğu durumlar vardı.
      Ondan önce kod tabanının o kadar dağınık olduğunu, bu tür şeyleri düzgün izleyemeyeceklerini tahmin etmiş ve her şeyin sihirli biçimde çalıştığına inanan yöneticimle tartışmıştım. Birkaç gün sonra muhasebe tutarsızlıklarına ilişkin bir denetimin başlayacağına dair e-posta aldım.
      JPMC, nakit akışını içeride tutarlı yönetmek için kripto para kullanımını önermişti; ama gerçekte ne kadar ilerlediler bilmiyorum.
    • Synapse, asıl muhasebe hatasının banka olan Evolve tarafında olduğunu söylüyor. Eksik işlemler, raporlanmamış borç kayıtları, devam eden işlemleri Mercury’ye gönderirken Synapse’e yanlış şekilde borç yazılması gibi şeyler buna dahil.
      https://lex.substack.com/p/podcast-what-really-happened-at-s...
    • HSBC hesabımdan para kaybolduğu olmuştu. İki hesap arasındaki bir ödemeydi; çift kayıt küçük bir tutar kadar tutmuyordu ve defterlerde kolayca mutabakatı yapılamıyordu.
      Bir süre itiraz ettim ama doğru dürüst kabul etmediler de düzeltmediler de. Kanıt olmadan, içeriden ince bir hırsızlık olabilir diye şüphelendim; ama beceriksizlik daha makul açıklama gibi duruyor.
    • Gerçek bankacılık kurumları da aynı derecede tedirgin edici. Örneğin Vanguard birkaç yıl önce geliştirme işlerinin önemli bir bölümünü Hindistan’a dış kaynakla verdi.
      BoA’da sistem yöneticisi olarak çalışan bir arkadaşım, belirli logları 7 yıl saklamaları gerektiğini ama disk dolmaya başlayınca bunları öylece sildiklerini söylemişti.

  • Google’da çalışmaya başladığımda anlamam zaman alan şeylerden biri, ölçeklenebilirlik için güvenilirlikten veya doğruluktan ödün verilmesiydi.
    Daha önce faturalama sistemleri ya da küçük ölçekli OLTP web uygulamaları yapmıştım; kabul edilebilir veri kaybı veya sıfır olmayan hata oranı gibi sorular aklıma bile gelmemişti. Saniyede milyonlarca isteği işlediğinizde bazılarının başarısız olacağı gerçeğinden çok, mühendislik yaklaşımındaki fark daha sarsıcıydı.
    Şu anda bile Gmail’i açıp düzgün yükleyemeyen ya da 500 hatası alan birkaç bin kişi olabilir. Kimse bunun nedenini izlemiyor; çünkü kullanıcı yenileyip gününe devam edecek. Öte yandan depolama dayanıklılığı yılda %99,99999 gibi etkileyici bir sayı olsa bile 2 milyar müşteriniz varsa 200 kişi gerçekten berbat bir gün geçirir.
    Loglardaki her hatayı araştırma alışkanlığından, her şeyin her zaman biraz bozuk olduğu ve bir şeyi düzeltmeden önce önce maliyetinin tartıldığı bir yaklaşıma geçiş oldukça sarsıcıydı.

    • Bu kadar düşük bir dayanıklılık seviyesi artık güncel seviye değil.
      Benzer ölçekte sık gördüğüm pratik kural, tüm altyapı genelinde 100 yılda 1 veri kaybı hedeflemektir. Maliyet genellikle %10’dan çok daha az artar; ancak veri yerleştirme algoritmasını tasarlarken kombinatoriği anlayan birine ihtiyaç vardır.
      Bu alanı anlamanız gerekiyorsa copyset makalesi iyi bir başlangıç noktasıdır.
    • Bu genel olarak doğru; ama ters yönde olanı da sık gördüm. Özellikle başarısızlık konusunda çok gevşek bir sezgiye sahip sosyal medya şirketi kökenlilerin finans uygulamalarına girmesi durumunda; genelde iyi sonuçlanmıyor.
    • Google’dayken Android ekibine geçici olarak atanıp kişi senkronizasyonu üzerinde çalışmıştım. Yaşadığım sorun son derece nadir bir durumdu ve prodüksiyon toplu verilerini çekince kullanıcıların %0,01’ini etkileyecek gibi görünüyordu.
      Çözümü sunarken bu hata oranını söylediğimde, o 200 bin Android kullanıcısının nasıl kurtarılabileceği soruldu. Kurtarma yolu yoktu ve kişi senkronizasyonu basitçe bozulacaktı; bu yüzden yeniden tasarlamam söylendi.
      Sayının kendisi insanı mütevazı kılıyordu. %99,99’un yeterli olduğu alanlar kesinlikle var; ama yeterli olmadığı alanlar da bir o kadar çok.

  • Bu tür işlerde en baştan doğru insanları işe almak yardımcı olur. Bir sürü LeetCode uzmanı alıp da, veri yapıları ve algoritmaları kafasında canlandırma becerisi dışında gerçekten yapmak istediğiniz şeyi yapıp yapamayacaklarını sormamak olmaz.
    İnsanlar o şeyi nasıl inşa edeceklerini biliyorsa büyümeden feragat etmek gerekmez; en baştan doğru şekilde yapılır.
    Bazen muhasebe, finans, biyoloji gibi farklı eğitim geçmişlerine sahip mühendislere ihtiyaç duyulur. Kariyerimde en önemli şey, ürettiğim şeyin ait olduğu sektörü derinlemesine anlamak ve gerçekten önemli soruları sorabilecek alan uzmanlarını tanımaktı. Problem çözme ve mühendislik budur; gerisi programlama/kodlamadır.

    • HN’de şu anki gündelik hayatımı bu kadar ürkütücü derecede doğru anlatıp aynı zamanda tamamen katılmamı sağlayan bir yazıyı ilk kez görüyorum.
      Kariyerimin büyük bölümünü teknoloji ile finansın kesiştiği alanda, çoğunlukla satış vergisi ve kullanım vergisi uyumluluğu tarafında geçirdim. Bu süreçte muhasebecilerin, controller’ların ve avukatların beni ne kadar etkilediğini yeterince fark etmemişim.
      Yakın zamanda epey eski bir startup’ın defter-i kebir sistemine danışmanlık yaptım; finans ya da muhasebe geçmişi olmayan mühendisler muhasebe sistemi kurunca ortaya ne çıktığını görünce dehşete düştüm.
      Sihirli bir muhasebeci-mühendis bulmanız gerekmiyor. Tasarım sürecinde gerçek bir muhasebeciyi mühendislik ekibinin yanına oturtmak bile yeterli. Tüm yeniden tasarım planını bitirdikten sonra CPA bir arkadaşıma baştan sona incelettim; birkaç senaryoda açık buldu ama genel olarak iyiydi.
      Para zor bir mühendislik problemidir. Çünkü paranın etrafında insanların her türlü tuhaflığı da gelir.
    • Doğru. Defter-i kebir alan bilgisidir. Yüksek yük optimizasyonu dahil diğer her şey bunun üzerine kurulmalı.
    • Bazı gruplarda, teknolojinin her sorunu çözebileceğine inanma gibi sinir bozucu bir eğilim var. İnovasyonu her şeyin üstünde tuttukları için uzmanlardan uzak duruyorlar.

  • Mühendislik liderliğinde alan bilgisinin önemli olduğunu yeniden görüyoruz. Bir finans şirketinde çalışıyorsanız doğru teknik kararlar ve ödünleşimler için finansı bir ölçüde anlamanız gerekir; gazetecilik ya da ticaret için de aynı şey geçerli.
    Çalıştığım başarılı organizasyonlar, teknik ekip mülakatlarına her zaman alana özgü teknik olmayan sorular dahil ederdi. Buna karşılık teknik olarak çok güçlü bazı ekipler, alan içgörüsü eksik olduğu için bocalıyordu.

    • Yazılım mühendisi olup aynı zamanda CPA olduğum için alan bilgim var. Ama bunu uygulayabileceğim işi nasıl bulacağımı bilmiyorum.
      Nereye baksam, muhasebe geçmişi ve nispeten kısa yazılım mühendisliği deneyimi olan biri olarak benden ziyade, hiç alan bilgisi olmasa bile yazılım mühendisliği deneyimi iki kat fazla olan kişileri çok daha fazla tercih ediyorlar gibi görünüyor. Bunu etkili biçimde değerlendirmenin bir yolu var mı merak ediyorum.
    • Ana fikre katılıyorum ama bu tür alana özgü soruları da başka bir teknik alanın teknik soruları olarak görmek daha faydalı.
      Finans da tekniktir, makine mühendisliği de tekniktir; spor yönetimi ya da sosyolojide de büyük bir teknik unsur vardır. Teknik yetkinliğin ne olduğuna daha geniş bakınca, farklı alanlarda işbirliği yapmak için gereken tevazu gelişir.
    • Bir sigorta şirketinde çalışmaya başladıktan sonra sigorta sektörünü anlamanın kod tabanını anlamaktan çok daha zor olduğunu fark ettim. Kod tabanı garip davranıyorsa en azından debugger ile izini sürebilirsiniz.
    • Bundan pek emin değilim. Alan bilgisinin tamamına sahip olmanın ürün yöneticisinin görevi olduğunu hep böyle anladım.
      Gereksinimlerin doğru olup olmadığını ve yapılan ürünün bu gereksinimleri karşılayıp karşılamadığını mühendislikle birlikte doğrulamak PM’in işidir. Agile bir ortamda bu konuşmalar ve doğrulamalar her sprint’te gerçekleştiğinden, bir şeyin uzun süre süzgeçten geçmeden kalması zordur.
      PM yoksa mühendislik ekibinin derin alan bilgisine ihtiyacı olur; ama aksi halde bu mühendisliğin sorumluluğu değildir. Ürün organizasyonunun sorumluluğudur.

  • Eski bir hikâye anlatayım: Çift taraflı kayıt sistemi hiç yapmadım ama onlarca yıl önce geliri sekiz hanelere kadar büyüyen bir internet/telekom startup’ında faturalama sistemi yapmıştım.
    Genç bir geliştirici olarak pek bir şey bilmiyordum ve tesadüfen ilk günden faturalama mantığını yazmaya başladım; iyi mi kötü mü bilmem, sistemi iki yerde kurdum. Biri tüketiciye dönük faturalama web sayfasıydı, diğeri de faturaları oluşturan ve kredi kartı ödemelerini gerçekleştiren ayrı bir backend süreciydi.
    İkisini uyumlu tutmak şaşırtıcı derecede zordu. Sermaye yakarak pazar tepkisi bulmaya çalışırken sürekli iterasyon yapıyorduk; yeni ürün ve hizmetler, yeni indirim ve fiyatlandırma biçimleri, kullanım bazlı ücretlendirme, aylık ücretlendirme, ilk X kullanım ücretsiz, kurumsal hesaplarda ana ödeyici/alt hesaplar, kullanıcıların belirlediği maliyet merkezleri, vergilerin bu maliyet merkezlerine dağıtılması ve 1 sentlik dağıtımlar gibi özellikler sürekli ekleniyordu. Her seferinde yeni kırışıklıklar ve istisnalar çıkıyor, iki ekran/yöntemdeki rakamlar tutmuyordu.
    Faturalamadan ben sorumlu olduğum için her ay birkaç günümü tüm faturaları elle gözden geçirerek geçirirdim; kredi kartı tahsilatları yapılmadan ve kâğıt faturalar gönderilmeden önce son kontrol olarak rakamların tutup tutmadığını doğrulardım. Her zaman ya da sık sık tek bir müşteriyi veya az sayıda müşteriyi etkileyen yeni bir sorun bulur, gerçek faturalamadan önce kodu düzeltirdim. Her şeyi elle yeniden kontrol etmeden bırakmak beni hep tedirgin ederdi.
    Tutarsızlıkları ve manuel çapraz doğrulamayı ortadan kaldırmak için faturalama mantığını tek bir yere refactor etmeyi düşündüm; ama uzun süre düşündükten sonra tek bir kod tabanının beni rahatsız ettiğini, iki kod tabanının ise hatalarımı yakalamama yardımcı olduğunu fark ettim. Sonrasında iki implementasyon arasında otomatik çalıştırma ve çapraz doğrulamayı giderek kolaylaştırdım.
    Faturalama kodu övünülecek kadar temiz değildi ama faturalama doğruluğu, şikâyet azlığı ve yıllar boyunca kaçındığımız yürek hoplatan hatalarla çok gurur duyuyordum. Benden sonrakilere bıraktığım karmaşıklık için biraz suçluluk hissediyorum ama bugün de çok pişman değilim.
    O deneyimden sonra çift taraflı muhasebenin motivasyonunu hep iyi anladım. Müşterilere zarar vermemek için kendi hatalarımı engellemek adına, kötü bir biçimde çift mantıklı faturalama kodunu yeniden icat etmişim.

    • Faturalama ya da paranın karıştığı herhangi bir şeyi yanlış yapmak çok kolay.
      Eski şirketimde başına geçtiğim veri ekibinin parayı “kaybetme” gibi talihsiz bir alışkanlığı vardı. Gerçek para bir yerden başka bir yere giderken kaybolmuyordu; müşteriye fatura edilmesi gereken kayıtlar kayboluyordu.
      Gelir kaybetmediğimiz zamanlarda da çift faturalama yapıyorduk; bu böyle sürüp gidiyordu. Yönetimin güvenini yeniden kazanmak 3 yıl süren zorlu bir çalışma gerektirdi.
    • Kötü niyetli söylemiyorum ama kulağa kâbus gibi geliyor. Aynı zamanda sistem karmaşıklığına rağmen doğruluğu sağlamış olmanız gerçekten harika. Bununla gurur duyabilirsiniz.
    • Bu, N-version programming’e de çok benziyor.

  • Testler de mi yoktu? “Her 5 dolarlık satın almada işlem günlüğünde 4,98 dolar kalıyordu” diye örnek verecek kadar her işlemde para kaybediliyorsa, sorun çift taraflı muhasebe eksikliğinden çok daha büyük demektir.
    Böyle bir finans sistemini kim yapar da normal görür? Telafi konusu da sorun ama böyle bir hizmetse mümkün olduğunca çabuk kaçmak gerekir.

    • Bunu yapanlar tam da bu kişilerdi. Kendileri “düzgün de yapabilirdik ama yapmadık” dediler. Bu bir kaza değil, bir tercihti.
      “Dans eden sentler” gibi şakalar yaptılar ve anlamlı sonuçlara katlanmak zorunda kalmayacaklarını bildikleri için böyle davrandılar. Hızlı hareket ettiler, bir şeyi—parayla ilgili bir şeyi—bozdular ve gülüp geçtiler.
      Şimdi de bunu kasıtlı olarak seçmiş olmaları onlara ahlaki ve teknik otorite kazandırıyormuş gibi insanlara ders vermeye kalkıyorlar. Şaşırtıcı derecede kibirli startup VC kültürü saçmalığı.
    • Hâlâ parayı nasıl kaybettiklerini anlamamışlar. Çift taraflı muhasebe teşhise yardımcı olurdu, ama gerçekte para nasıl ortadan kayboldu?
    • Ben de aynı şeyi düşündüm. Defterin pek çok avantajı var ama dans eden sentler sorununu düzeltmez. Sadece deftere yanlış rakamlar yazılır.
      Elbette hatayı bulmak için ipucu verebilir, ama temel testler yazmak da aynı şeyi yapardı.
    • İyi bir tasarım ilkesi, 1000 test kadar değerlidir.
    • Bu hikâyenin doğru olup olmadığına nasıl karar veriyorsun?

  • Yazarın “make it work, make it right, make it fast” özdeyişini neden olumsuz şekilde ele aldığını anlamadım. Muhtemelen “make it fast”ın nereye oturduğunu yanlış anlamış.
    “make it right” ikinci aşamadır ve doğru çalışır hâle getirilmeden iş orada durmalıdır. Sistemin sağlıklı çalışması gerekir. “make it fast”, yani optimizasyon, doğruluk ve sağlamlık sorunları tamamen çözüldükten sonra başlar.
    Bunun teslimat hızıyla ya da hızlı çalışmakla ilgisi yok; optimizasyonu son aşamaya ertelemek gerektiği anlamına gelir.
    Ancak yazarın söylemek istediği şey, bir şey kabaca “çalışsa” bile “doğru” olmaktan o kadar uzak olabilir ki sonradan geri dönüp düzeltilemez; zar zor çalışmaya başlamadan önce bile en baştan “doğru” yapılmalıdır ise, bunu anlarım.

    • Bence son cümle doğru. Yazar, ödeme sistemlerinde önce çalışır hâle getirip sonra doğru hâle getirmenin mümkün olmadığını söylüyor gibi.
      Ben de aynı fikirdeyim ve fintech sistemleri denetiminde yer almıştım. Denetçilerin defterleri onaylamadan önce her şeyi Excel tablolarına indirip rakamları tutturması gerekiyordu. Çok zaman ve para aldı; 3 yıl sonraki likidite etkinliğinde en az 0,1 unicorn kadar fark yaratmış olabileceğini tahmin ediyorum.
    • Bence yazar yanlış özdeyişi seçmiş.
      Hızlı hareket eden startuplarda fiilen mümkün olan en kısa sürede bir MVP çıkarılır. Müşteri tabanı, finansal durum vb. oluşturulması gerektiği için “make it work” aşamasında takılıp kalınır.
      Daha iyi özdeyiş Facebook’un “move fast and break things” sözü olurdu. Ama bu ancak sonradan düzeltebiliyorsan işe yarar. Örneğin uçak yapıyorsan böyle davranmazsın.
    • Mühendislik ekibinin bu özdeyişi izlediği söylenmişti ve bunun içinde “make it right” da var. Ama bunu yapmadılar. Ürünü geliştirmeden önce fintech hakkında neleri bilmediklerini anlamaya bile çalışmadılar.
      O bağlama bakınca, ilk cümledeki yanlış anlama en olası açıklama gibi. Çünkü hemen ardından startupların maruz kaldığı zaman baskısından söz ediliyor.

  • Buradaki yorumların çoğu yazının eleştirdiği şeyi aynen tekrarlıyor. Tek taraflı muhasebeyi savunan sayısız uzun tartışma görüyorum.
    Tek taraflı muhasebe daha kolay ve daha yaygın olabilir; ama bazen yüzyıllar içinde gelişmiş sistemleri ve soyutlamaları olduğu gibi izlemek iyi bir fikirdir.
    Mutlaka başka bir şeye ihtiyacınız yoksa çift taraflı muhasebe kullanmak daha iyidir. Programcı içgüdüsüne ters gelebilir, ama tutarsızlıkları düzeltmek için gerçek bir muhasebeci çağırmanız gereken an geldiğinde minnettar olursunuz.
    Bununla ilgili olarak ödemeler ya da komşu alanlarda çalışan programcılar için iyi kaynak bilen var mı? “Programcılar için muhasebe” gibi bir şey.

  • Her 10 işlemde verinin %1’ini kaybeden bir veritabanı sistemi kullandığınızı söyleseniz, böyle bir mühendislik blogu tavsiyesini ciddiye alabilir misiniz? Bu tür yazılar, kavram tanıtımından çok belirli bir kişi ya da grubun reklamı gibi, sakin bir dille paketlenmiş hissi veriyor.

  • Para taşıyan yazılımlara yönelik bu tür gevşek tutumun gerçek insanlar için ne sonuçlar doğurduğunu görmek için Post Office skandalına bakın.
    https://en.wikipedia.org/wiki/British_Post_Office_scandal
    Para hareket ettiren her şey mümkün olduğunca ciddiye alınmalı ve mümkün olduğu kadar çok tarihsel başarısızlık bilinmeli.