Bu Uygulamanın Yapımı Sırasında Hiçbir Köpek Zarar Görmedi

 (shmck.substack.com)
1 puan yazan GN⁺ 2023-11-04 | 1 yorum | WhatsApp'ta paylaş
  • 2016'da React Native mobil uygulamasındaki konum bilgili fotoğraf yükleme özelliğinin yalnızca Android betada başarısız olması, yerel Android ve iOS'ta yeniden üretilememesi sorunu bir hafta boyunca izlendi
  • Android beta, görsel yükleme başarısız olduğunda bile hata geri bildirimi vermiyordu; Play Store'a her yeni derleme yüklendiğinde yaklaşık 1 saat sürdüğü için hipotezleri doğrulamak yavaştı
  • Gömülü sistemler, donanım, kimya ve veterinerlik örnekleriyle karşılaştırıldığında yazılımda hata ayıklamanın çok daha hızlı ve gözlemlenebilirliği yüksek olduğu ortaya çıkıyor
  • Asıl neden, görsel MIME türünün "jpg" yazılması gibi tek karakterlik bir farktı; dosya uzantısı .jpg olsa da MIME türünün "jpeg" olması gerekiyordu
  • Loglar, gerçek zamanlı gözlem, debugger ve tekrarlı deneyleri düşük maliyetle kullanmayı sağlayan geliştirme ortamı, diğer mesleklerin geri bildirim döngüleriyle karşılaştırıldığında büyük bir ayrıcalığa yakın

Yalnızca Android betada başarısız olan fotoğraf yükleme

  • React Native mobil uygulamasının geolocated photos özelliği pazartesi günü yayıma hazır gibi görünüyordu, ancak Android beta dağıtımından sonra görseller yüklenmedi
  • Yerel Android testlerinde ve iOS betada normal çalıştığı için hatanın nedeni hemen ortaya çıkmadı
  • Hata işlemeyi iyileştiren sürüm yeniden yüklense de yükleme hatası hâlâ geri bildirim olmadan gerçekleşti
  • Yeni yineleme sürümünü Play Store'a yüklemek yaklaşık 1 saat sürüyordu; bir sonraki hipotezi hazırlarken derlemenin dağıtılmasını beklemek gerekiyordu

Diğer mesleklerde daha uzun geri bildirim döngüleri

  • Bir gömülü sistem mühendisi, uzaktaki ekipmana firmware güncellemesi dağıttıktan sonra düğümün yanıt vermediği bir durum yaşar
    • Nedeni anlamak için ekipmanın geri alınıp analiz edilmesi gerekir
    • Bazı durumlarda neyin yanlış gittiğini öğrenmek aylar alır
  • Bir donanım mühendisi, uzakta dağıtılan yeni donanımın tasarım kusurunu ancak birkaç mevsim dayandıktan sonra ortaya çıkarabileceğini düşünür
    • Eski ekipman postayla alınır ve düzeltmeler bir sonraki nesil ürüne yansıtılır
    • Isıyı azaltmak için havalandırma delikleri eklenmiş, ancak delikler eşek arılarının yuva yapabileceği kadar büyük olduğundan daha kötü bir bug'a dönüşmüş bir örnek vardır
    • Laboratuvar testleri mümkün olsa da nihai doğrulama sonunda sahada yapılır

Başarısızlığı kabullenme biçimi

  • CEO, doktora tezini hazırlayan bir kimyager olduğu dönemde pahalı kimyasallar için aldığı büyük bir araştırma bütçesiyle deney yürüttüğünü, ancak birkaç hafta sonra sonucun deney hatası nedeniyle başarısız olmuş gibi göründüğünü hatırlar
  • Neyin yanlış gittiğini anlayamamıştı; aynı hatayı tekrarlamamak için neyi farklı yapacağı sorusuna da yanıt verememişti
  • Buna rağmen ikinci araştırma bütçesini aldı ve bu deneyim, başarısız olan kişiyi yeniden ayağa kaldıran empatik liderliğin bir örneği oldu

Veterinerlik örneğinin gösterdiği daha yüksek risk

  • Veteriner bir arkadaş, yaşlı ve hasta bir köpeği muayene ederken sahibine röntgen önerdi, ancak maliyet nedeniyle reddedildi
  • Röntgen olmadan yapılabilecek en iyi şey köpeğin karnını dışarıdan elle muayene etmekti ve büyük bir cisim hissedildi
  • Ameliyatla çıkarılan şey mısır koçanıydı, ancak röntgen olmadığı için sorunun tamamının bu olup olmadığından emin olunamadı
  • Ertesi gün o köpek hayatını kaybetti; mobil uygulama yayımlama sorunundan farklı olarak, diğer mesleklerdeki başarısızlıklarda gerçek anlamda yaşam ve ölüm söz konusu olabilir

Tek karakterlik bug ve hata ayıklama araçlarının ayrıcalığı

  • Cuma sabahı Android belgeleri ile kod tabanı arasında bir tutarsızlık görüldü ve bir hafta boyunca soruna yol açan neden tek bir karakterdi
  • Görsel MIME türü "jpg" olarak ayarlanmıştı, ancak aslında "jpeg" olması gerekiyordu; dosya .jpg olarak kaydedilmişti
  • Yazılım geliştiricileri karmaşık süreçlerin derinliklerine bakabilir, gerçek zamanlı çalışmayı izleyebilir, log tutabilir ve debugger ile yürütmeyi durdurup inceleyebilir
  • Bu yetenekler ucuz ve hızlıdır; birkaç tıklamayla aynı gün içinde defalarca deney tekrarlanabilir
  • Yazılım da diğer meslekler kadar önemli ve etkili olabilir, ancak geliştiriciler bugün sahip oldukları hata ayıklama araçları için minnettar olunabilecek bir ortamda çalışır

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-04
Hacker News yorumları

  • Yazılım mühendisliğinin diğer mesleklerden, şakayla karışık söylersek “gerçek” mesleklerden nasıl farklı olduğunu gösteren neredeyse fabl gibi bir hikâye
    Daha kısa ve nükteli bir versiyonunu da seviyorum: Bir yazılım mühendisi, bir donanım mühendisi ve bir bölüm yöneticisi İsviçre’de bir toplantıya giderken dik bir dağ yolunda frenler bozulur; araba bariyerlere çarpa çarpa aşağı iner ve mucizevi şekilde durur
    Bölüm yöneticisi bir toplantı yapıp vizyon, misyon ve hedefler belirleyerek sürekli iyileştirme yoluyla temel sorunu çözelim der; donanım mühendisi ise İsviçre çakısıyla frenleri söküp tamir edelim der
    Yazılım mühendisi de “Bir şey yapmadan önce arabayı tekrar yukarı itip yeniden üretilebiliyor mu bakalım” der

    • Yazılım mühendisliğinin büyük avantajı soyutlamalarla uğraşmasıdır. Bulutların üstüne şato inşa etmeye benzer; temellere kadar her şeyi yeniden şekillendirebilirsiniz
      Aynı zamanda yazılım mühendisliğinin büyük dezavantajı da soyutlamalarla uğraşmasıdır. Temeller bile hareket eder
      http://thecodelesscode.com/case/154
    • Bu hikâyenin dersi sadece donanım mühendisinin haklı olduğu mu?
    • Makine mühendisi bu
    • “Tekrar çalıştır”a basınca araba mucizevi şekilde tepenin üstünde yeniden belirip aynı şey tekrarlansa; frenin bozulduğu anda zamanı durdurup arabanın tüm parçalarını sökerek sorunun tam olarak nerede olduğunu gerçek zamanlı, yavaş çekim ve geri sarımda görebilsek nasıl olurdu?
      Böyle bir yeteneğe sahip olmak yazılım mühendisinin gülünç ya da gerçek dışı olduğu anlamına gelmez
      Dijital uzayın mühendisliği, fiziksel alanlarda mucizeye yakın hata ayıklama yetenekleri sağlar. Aynı nesneden 10 tane yapıp 10 farklı şekilde test etmek istiyorsanız, kelimenin tam anlamıyla CTRL+C, CTRL+V yeter. Bir tamircinin bunu yaptığını görmek isterdim
    • Sorun sadece frenlerde, motor sapasağlam. Arabayı illa neden tepenin üstüne itelim ki?
    • Tüm pencereleri kapatıp yeniden başlatırım

  • Yazılım mühendisleri “gerçek mühendis” değilmiş; daha fazla büyük ölçekli ön tasarım toplantısı ve muazzam planlama yapılırsa sorun çözülürmüş tarzı şikâyetlerden gerçekten bıktım
    Diğer mühendislik alanları öyle çalışıyorsa bu bizden çok daha profesyonel oldukları için ya da o yöntem daha iyi olduğu için değil; ellerinde başka yöntem olmadığı için. Bir oteli bitirdikten sonra tavanın 6 inç daha yüksek olması gerektiğini fark edip her şeyi yıkıp yeniden yapmazsınız
    Eğer ceilingHeight += 6 çalıştırıp “Rebuild”e bastığınızda otel yeniden inşa edilse, otomatik birim testleri erişilebilirliği bile kontrol etse ve toplam maliyet 2,82 dolar olsa, onlar da elbette böyle yapardı
    Aşağılık kompleksini bırakmalıyız. Gerçek dünyadaki inşaat ve makine mühendislerinin hayal bile edemeyeceği araçlarla mühendislik yapıyoruz; bunun sonucunda süreçlerin ciddi biçimde farklılaşması son derece doğal
    Elbette bazen sorunlara yeterli süreç uygulayamadığımız oluyor. Ama bunun yalnızca programlamaya özgü bir sorun olduğunu düşünüyorsanız, size birkaç saat https://www.imdb.com/title/tt4788946/ izleme reçetesi yazmak isterim

    • Bence asıl noktayı kaçırıyorsun. Önceden planlama ya da toplantılar işin özü değil; bunlar önceki ölçütlerin sonucu. Mühendislik, pratik sorunları bilimsel biçimde çözmektir; güvenlik, tekrarlanabilirlik ve çözümün ilkelerini anlama taviz verilemezdir; çözümü üreten kişi etik ve bilimsel titizlik açısından mühendis niteliğine sahiptir ve bu nitelik nedeniyle onayladığı çözüm başarısız olduğunda muaf tutulamayacağı bir sorumluluk taşır
      Bu bir üstünlük meselesi değil; bu ölçütlerden biri bile eksikse mühendislik yapmıyorsun demektir. Benim deneyimime göre yazılım geliştirmenin çoğunda bu dört unsurun hepsi eksik. Bu mutlaka kötü bir şey değil, ama yazılım geliştirmenin çoğu mühendislik değildir
      Mühendisliğin geliştirmeden üstün olduğu anlamına hiç gelmiyor
    • Tamamen katılıyorum. Farklı ortamların her birine uygun, optimize edilmiş süreçler ve teknikler vardır
      Kil heykel ile mermer heykel arasındaki fark gibi. Kilde hata yaparsanız kısa sürede yeniden şekillendirebilirsiniz; ama mermerde çıkarılmaması gereken bir yeri oyarsanız yeni bir mermer blok sipariş etmeniz gerekir
      Mermer heykel yöntemini kil dünyasına taşırsanız ancak berbat ya da en azından çok verimsiz bir kil heykeltıraşı olursunuz
      Kil ile mermerden hangisinin daha değerli olduğuna dair yarışmanın da pek anlamı yok. İkisinin de toplumda kendi yeri var
    • Tamamen konu dışı ama 3D baskının güzel yanlarından biri, gerçek dünyada ceilingHeight += 6 deneyimine en yakın şeyi sunması
      Bugün de bir nesneyi modelleyip bastım; bir kısmının yaklaşık 1 mm daha kalın olsa iyi olacağını fark ettim. 30 saniye sonra sürüm 2 yazıcıya gidiyordu
      Gerçekten harika. Bunun kâğıt yazıcılar kadar yaygınlaşmasını beklemek zor
    • Yazılım mühendisliğinin gerçek mühendislik olmadığını düşünenler, “gerçek” mühendisliğin önemli bir kısmının aslında sadece yazılıma sayı girmek olduğunu öğrenince şaşırabilir
    • CAD’den önce tasarlanmış uçaklara ve jetlere bakarsanız, mühendislik tasarımının da sahada gayet düzeltilebildiğini görürsünüz. Onu yapanların ve düzeltenlerin kafasındaki know-how’a dayanarak tam uyacak şekilde yapılmışlardı
      https://www.youtube.com/watch?v=NPVT2lvMvOk

  • Kariyerim boyunca birkaç kez, bir şeylerin hata verdiği ama tamamen sessiz kaldığı için herkesin tıkandığı durumlar yaşadım. Hata çıktısı yoktu, hiçbir şey yoktu
    Bu vakaların önemli bir kısmında sebep, düşük seviyeli bir üçüncü taraf kütüphanesinin catch (e) {} yapıyor olmasıydı. Başlarda yaşadığım ilk örnek iyi bir ders oldu; artık hiçbir hatayı sıradan görüp geçmiyorum. En azından logluyorum
    Bugün yaptığınız yazılım 5 yıl sonra, hiç hayal etmediğiniz bir ortamda kullanılabilir

    • “Bu fonksiyon ekipteki herkese fazlasıyla açık, yoruma gerek yok” diye düşünürsünüz
      30 yıl sonra:
      /* X systems I modul body I 14.09.1990 */
      void xxvcda(int *addr, int sizeof)
    • Gerçekten öyle. Şu anda baktığım kodda, daha önce kısa süre uğramış bir yazar alt kütüphane istisnasını yuttuktan sonra onun yerine tamamen işe yaramaz bir istisna fırlatıyor
      Önceki istisnadan yeni istisnayı yükselterek yığın izlemenin bağlamını koruyan dil özelliğini de bilmiyormuş. Eğlenceli işler. En azından ana işimdeki kod değil; ama ana işimin de kendine göre eğlenceleri var
    • Yakın zamanda DRF ve JWT’de de benzer bir şey yaşadım. Aralıklı bir zamanlama sorunu nedeniyle JWT geçersiz oluyordu ve giriş yapılamıyordu
      DRF doğrulama hatasını yutup yalnızca genel bir hata döndürdüğü için hiçbir ipucu yoktu; sonunda bizzat aşağı katmanlara inip loglama ekleyerek ne olduğunu bulmak zorunda kaldım

  • Fizikçi bir arkadaşım Rutherford’un “Bütün bilim ya fiziktir ya da pul koleksiyonculuğu” sözünü sık sık alıntılardı.
    Onun kastettiği, fiziğin matematik ya da bilgisayar bilimlerinden farklı olarak fiziksel gerçeklik tarafından doğrulanan bir yöntemi olduğuydu.
    Alanı aşırı güçlü manyetik alanlardı; dev bakır bobinler yapıp eriyecek kadar akım geçiriyor, sonra bobinin çevresinde patlayıcılar patlatarak çok kısa bir an için merkezdeki manyetik alanı insanlığın ürettikleri arasında en güçlü hâle getiriyor, ardından binlerce derecelik sıvı bakır etrafa saçılırken tüm düzeneğin yok olduğu türden deneyler yapıyordu.
    Böyle bir çalışma ortamında hata ya da yanlış hesap, insanların çok hızlı ve korkunç biçimde ölebileceği anlamına gelir. Bu yüzden, en büyük zararı kazağına tebeşir tozu bulaşmak olan matematik doktora öğrencilerinin kendilerine bilim insanı demesine katılmazdı.

    • Bu alıntının epey sıra dışı bir yorumu. Çeşitli kitaplara göre sözün anlamı, bilimin ya matematiksel ve nicel olduğu ya da teknik kaldığıdır.
      Başka bir deyişle, ya nesnenin dinamiklerini anlamaya çalışır ya da ilginç olguları toplamak ve ilgi duyulan şeylere ad vermekle sınırlı kalır.
    • Patlayıcıyla pompalanan manyetik akı sıkıştırma jeneratörü[1] eğlenceli.
      Süper kötü kariyerine ilgi duyup nereden başlayacağını bilmeyenler için söyleyeyim: Gerçek EMP böyle yapılır.
      [1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
    • Dijkstra’nın neden bu kadar kibirli olduğunu merak ediyordum; teorik fizik okuduğunu öğrenince anladım.
    • Matematikçilerin kendilerine bilim insanı dediğini pek görmedim. Aksine, genelde bilim insanı olmadıklarını ve gerçekliğin önemsiz kısıtlarıyla sınırlı kalmadıklarını söyleyerek övünürler.
    • Bir fizikçiye yakışır şekilde, o alıntıyı yanlış yorumlamış.

  • Böyle bir şey yaşandıktan sonra her zaman yukarı akışta düzeltici önlem olmasını isterim. Uygun günlükleme ve hata raporlama olsaydı bunu düzeltmek bir hafta sürmezdi.
    Hatalı image/jpg MIME türünü alan kütüphane istisna fırlatmalı, çökmeli ya da en azından bunu belirgin biçimde loglamalıydı. İlk yazarın o kütüphaneye bug bildirip bildirmediğini merak ediyorum.

    • Yazının sonlarına doğru, Shawn’ın nasıl bir ortamda çalıştığını ve teşhisin neden bu kadar uzun sürdüğünü merak ettim.
      Sunucuda görsel yüklemelerin gerçekten gelip gelmediğini doğrulayacak ya da çürütecek erişimi var mıydı? Test ortamında yükleme çalışırken uygulamanın yayın sürümünde neden çalışmıyordu? Test ortamında ne farklıydı?
      Teoride Shawn’ın, sunucuyu doğrudan çalıştırarak ya da yüklemenin sessizce neden başarısız olduğunu teşhis edecek birinden yardım isteyerek, “yükleme başarılı oluyor da neden görünmüyor?” sorusuna epey hızlı yanıt verebilecek kadar erişimi olmalıydı.
      Bence “görselin MIME türü jpg idi, jpeg olmalıydı”dan çok, testte çalışıp prodüksiyonda çalışmamasının nedeni çok daha önemli ders. Bug’ın kendisinden ziyade, ortamın bug’ı bulmayı neden zorlaştırdığı daha büyük mesele.
      Benim durumumda masaüstü uygulaması ciddi şekilde yanlış çalışıyordu ama hata loglara düşmüyordu. Ancak birkaç gün sonra dosya handle’larının tükendiğini ve log4net’in de dosya handle’ı alamazsa log yazamadığını anladım. Küçük bir bug düzeltmesini geri almak çözüm olarak basitti; asıl düzeltme ise log4net’i log dosyasını her zaman açık tutacak şekilde özelleştirmekti. Böylece uygulama tüm dosya handle’larını tüketse bile hata kaydediliyordu.
    • Yazıdaki ilgili paragraf biraz canımı sıkıyor: “Hata işlemeyi iyileştiren sürümü yeniden yükledim ama görsel yükleme hiçbir geri bildirim olmadan başarısız oldu. Normalde kod hataları kırmızı yazıyla çığlık atar gibi gösterir ve sessizlik hedeftir. Burada sorun sessizlikti.”
      Sessizlik hedef değildir. Çok fazla geliştirici sessizliği hedef sanıyor ama gerçek hedef doğruluktur. Hata yoksa sessiz olmalı; ama kullanıcıyı etkileyen bir hata varsa büyük kırmızı bir uyarı kutusu olmalı.
      Geliştiricilerin hata mesajlarını sevmeyi öğrenmesi gerektiğini düşünüyorum. İyi yazılmış bir hata mesajı nedeni hızla ortaya çıkarır ve herkesin çok zamanını kurtarır.
      Bu geliştirici bundan sonra hata mesajlarını daha sık göstermeyi öğrendiyse bu çok iyi bir sonuçtur.

  • Eski bir iş arkadaşımın sık sık “Sonuçta hava trafik kontrol sistemi yapmıyoruz ya” dediği aklıma geliyor. Kastı, hata yapsak da işin ucunda can kaybı olmadığıydı.
    O sırada oyun geliştiriyorduk ama yazdığım neredeyse tüm CRUD uygulamaları için de geçerli bir sözdü.
    Ayrı olarak, diğer kıdemli teknoloji liderlerine, özellikle Director, VP ve CTO’lara sık sık “Yaptığınız en pahalı hata neydi?” diye sorarım. Junior mühendis iseniz bunu bir gün mutlaka yapmanız iyi olur.
    Birçok üst düzey teknoloji lideri 100 bin–1 milyon dolar ölçeğinde hikâyeler anlatabilir. Bir projede milyonlarca doları batırıp hemen terfi eden insanlar da gördüm. Bunun nasıl mümkün olduğunu, hatta neden iyi bir şey bile olabileceğini anlamak önemlidir.

    • Katılmıyorum. Başarısızlık ateş topu içinde ölümle sonuçlanmayabilir ama yine de zarar verebilir. Küçük zararlar bile ölçek büyüdükçe birikir.
      Bug’lı bir oyunun yarattığı hayal kırıklığı, gerçek hayatta trafikte öfkeye ya da bağırışmalı kavgalara dönüşebilir. Bilgisayarın yanlış fatura göndermesi yüzünden intihar eden insanlar oldu. Yazılım değerli verileri kaybettiği için batan şirketler de oldu.
      İnsanlar önemsiz görünen sosyal medya uygulamaları yüzünden öldürüldü; Twitter’da katliam kışkırtmaları örgütlendi. Pokemon Go’nun sızdırdığı bilgiler yüzünden takip edilip saldırıya uğrayanlar oldu.
      Yazılımın gerçek gücü var. Aksi olsaydı yazılım yazmanın da bir nedeni olmazdı.
    • “Sonuçta hava trafik kontrol sistemi yapmıyoruz ya” tavrı beni de rahatsız ediyor.
      Değerli verileri kaybedebilecek yazılımlar yaptım; şimdi de arızalanırsa su baskınına yol açabilecek yazılım geliştiriyorum.
      İnsan yaptığı işle biraz daha gurur duymalı.

  • Bir yazılım mühendisi olarak hata ayıklamaktan epey keyif alırdım. Çünkü tasarım yapıp uygulamaktan farklı beceriler ve düşünme biçimleri kullanmamı sağlıyordu
    Elbette bu, hata ayıklamanın stres yaratmadığı anlamına gelmiyor. AT&T'nin 5ESS telefon santrali yazılımını geliştirirken bir demo vardı; test laboratuvarında bizim özellik için ayarlanmış tek bir telefon hattı vardı
    Kaç kez denesek de yazılım çalışmadı ve yazılımın doğru olduğundan emin bir halde mümkün olan her şeyi kontrol ederken strese girdim. Sonunda laboratuvar teknisyeninden hattı kontrol etmesini istedim; ayarlanmış tek hattın bir şekilde bağlantısı kesilmişti. Aptalca bir donanım sorunuydu

    • Ben de aynıyım. Özellikle karmaşık sistemlerde hata ayıklamanın zorluğundan her zaman keyif aldım
    • Araçlar varken hata ayıklamak keyifli, ama tercihlerin sonucu olarak her şey mecazen ya da kelimenin tam anlamıyla çok uzağa dağılmışsa pek öyle değil
      Buluttaki dağıtık sistemlerde hata ayıklamak, tüm servisleri yerelde çalıştırabildiğiniz duruma kıyasla katlanarak daha berbat; o yerel dağıtık sistem de sorunu tek bir programın içinde ayıklayabildiğiniz duruma göre çok daha kötü
      Gerçek bir debugger da hata ayıklamayı çok daha iyi hale getiriyor. printf ile hata ayıklama ile gerçek debugger arasında yalnızca birine takılı kalan insanları hiç anlamadım. İkisini de kullanmak devasa kazanç sağlıyor. İyi izleme özellikleri de mümkün olduğunda printf ile hata ayıklamadan çok daha iyi olduğu için burada vurgulamaya değer
      Programlamanın ilk dönemlerinde, bunun neden olduğunu bilmediğim durumlara gereksiz duygular yüklerdim; zamanla “Bir dakika, neden böyle? Bilmiyorum… aa, dur… vay, bunun neden çalışmadığı gerçekten mantıklıymış!” döngüsünü kabullenmeye başladım ve sonuna gelince iyi hissettirdiğini de içselleştirdim
      Artık bilmeme hali tek başına, ancak başkalarının beklentileri ve davranışları yüzünden bozulabiliyor. Zamanla dil seçimi, mimari seçimi vb. konuları bu süreci kolay ve hızlı kılacak şekilde çok kararlı yönetmem gerektiğini öğrendim
      Kariyerimin bu noktasında, AWS Lambda'nın performans, toplam maliyet, hata ayıklanabilirlik ve geliştirme hızı açısından iyi bir seçim olmadığına insanları en baştan ikna etmek; sonradan “o tek sorunu düzeltmek neden bu kadar uzun sürdü” sorusuna makul bir gerekçe olduğuna ikna etmekten çok daha kolay

  • Sonda güldüm. Daha dün, şirkette 3 yıldır başımıza bela olan bir sorunu çözdüm; bizde sebep A harfiydi
    Son 3 yıl boyunca biri veriyi içeri alıp çıkarmak için manuel bir düzeltme yapıyormuş ve bu onun işinin bir parçası haline gelmiş. Düzenli temizlik için takvimine tekrarlanan etkinlik bile koymuş. Milyonlarca müşteri, cep telefonu hatlarında doğru veri paketinin uygulanması için bu tek kişiye bağımlıymış
    Unuttuğunda ya da tatile çıktığında ne tür bir karmaşa olacağını tahmin edebilirsiniz
    Sonunda sebep if $line->status == STATUS_ACTIVE idi; biri Active, diğeri active olmuştu. Hiçbir köpek zarar görmedi ama yıllar boyunca hesaplanamayacak kadar para kayboldu

    • Bir hukuk davası olsaydı şaka şöyle olurdu: “Ne yaptın sen? Bütün ailemi hukuk fakültesine gönderecek davayı çözdün!”
      O zavallı kişi artık vazgeçilmez değil. Yarı şaka. Yazılım işleri daha verimli hale getirir ama insan motivasyonlarına da bakmak gerekir
    • Boşluk ya da satır sonu gibi görünmez karakterlerin zarar verdiği zor vakalar gördüm
      Özellikle Mac'te HL7 alanlarını doldururken çok acı çektim. Mac klavyesinde girilen ’ karakteri HL7'nin tüm sürümleriyle uyumlu değildi ya da HL7'nin aktarıldığı hedefle uyuşmuyordu sanırım
      Eski bir anı ama o’clock ile o′clock gibi kelimeler arasındaki fark yüzünden radyoloji raporlarının dağıtımı bozulmuştu. Yakalanana kadar yıllarca sürdü
      HN, girdiğimden farklı biçimde ’ gösteriyor ama yine de aynı karakter. Hata ayıklarken farkın görünmemesi sorunun yarısıydı, bu yüzden epey komik
    • Kodun bir bölümünde STATUS_ACTIVE yanlış mı tanımlanmıştı?
      Birinin HttpHeader::REFERRER içindeki referer yazım hatasını “iyilik olsun diye” referrer olarak düzeltme riski her zaman var. Ama o yazım hatası HTTP standardına kazınmış durumda; böyle yaparsanız yazılım tamamen bozulur. CERN döneminden Phillip Hallam-Baker'ın sorumluluğu

  • Eşek arısı yuvası anekdotu bana hiç yabancı gelmiyor
    Ofis binamızın mülk sahibi, dışarıya dokunmatik ekranlı bir arayüz kurdu; her resepsiyonu arayıp kapıyı açtırmayı sağlıyordu. Kapıyı görebilen bir resepsiyon görevlisi olmadığı için bunu yaptılar
    Cihaz 6 ay dayandıktan sonra ciddi şekilde arızalanmaya başladı. Sebep, aslında büyük siyah bir Android tablet olan arayüzün binanın doğu cephesine kurulmuş olmasıydı
    İlkbaharın ortasına gelindiğinde her gün yeterince güneş alıp aşırı ısınıyor, dokunmatik elektroniği ve ekran donanımının bir kısmı bozuluyordu
    Benim yaptığım türden yazılımlarda ısı yükü konusunda endişelenmem gerekmiyor

    • Güneş ışığının treni durdurduğu hikâyeyi hatırlattı. Southeastern'a göre Londra'nın güneydoğusundaki Lewisham'da seferler, “alçak kış güneşi”nin açısı nedeniyle gecikmişti
      Demiryolu şirketi Twitter'da “güçlü güneş ışığından kaynaklanan kalkış sorunları nedeniyle Lewisham'dan geçen hatta ciddi yoğunluk yaşandı” diye yazmıştı
      Alçak kış güneşinin kalkış monitörlerine vurup makinistin görmesini engellediğini de söylemişlerdi

  • “Sonunda çözdüm. Sebep ‘E’ harfiydi” mesajı komik
    En basit ve en küçük hatalar çoğu zaman bulunması en zor olanlar oluyor. Bu sabah da bir off-by-one hatası bulmak için bir iki saat harcadım
    Sebep, refactoring sırasında değiştirmeyi unuttuğum tek bir index + 1 idi

    • Sık söylendiği gibi bilgisayar bilimlerinde iki zor problem vardır: cache invalidation, isimlendirme ve off-by-one hataları