"Bug" Kelimesi Nereden Geliyor? Bir Güvenin Hikâyesinden Milyar Dolarlık Hatalara

Bir yazılımcının en sık kullandığı kelimelerden biridir: bug. Kelime anlamı "böcek". Ama hiçbir yazılımcı böcekten bahsetmez — kastedilen, kodun içindeki hatadır.

Peki neden "böcek"? Gerçekten bir bilgisayarın içine sıkışmış bir güve yüzünden mi? Yoksa bu, defalarca anlatıla anlatıla efsaneye dönüşmüş bir hikâye mi?

Cevap ikisinin ortasında — ve düşündüğünüzden çok daha ilginç.

1. Kelimenin Kökeni: Böcekten Önce Bir Umacı Vardı

İngilizcedeki bug kelimesinin en eski anlamı böcek değildi.

Orta İngilizcede "bugge", "korkuluk, hortlak, umacı" anlamına geliyordu. Muhtemelen Galcedeki bwg (hayalet, korkuluk) kelimesiyle akrabaydı. Bugün İngilizcede hâlâ yaşayan bugbear ("insanı boşuna korkutan şey") ve bogeyman ("öcü") kelimeleri bu kökten gelir.

Yani bug, önce "görünmez, açıklanamaz, insanı rahatsız eden şey" anlamını taşıyordu. Böcek anlamı sonradan geldi — muhtemelen "sinsice ortaya çıkan, rahatsızlık veren küçük yaratık" çağrışımıyla.

Bu, sonraki hikâye için önemli bir detay: mühendisler bir arızaya "bug" derken, aslında "içeride bir yerde saklanan, göremediğim, canımı sıkan şey" diyorlardı. Böcek benzetmesinden çok, umacı benzetmesi.

2. Thomas Edison, 1878: "Bug" Mühendislik Diline Giriyor

Yaygın inanışın aksine, "bug" kelimesini teknik arıza anlamında ilk kullananlar bilgisayarcılar değildi. Kelimenin bu anlamdaki izi 1870'lere kadar gidiyor ve karşımıza çıkan isim Thomas Edison.

Edison, 1878 tarihli bir mektubunda icat sürecini anlatırken şöyle yazar (özetle): Bir fikir ortaya çıkar, sonra zorluklar baş gösterir — bu şey bozulur, şu şey çalışmaz — ve işte o zaman "Bugs" dediğimiz küçük arızalar ve zorluklar kendini gösterir. Edison'a göre bir icadın "ticari başarıya ya da başarısızlığa" ulaşması, bu bug'ların ayıklanıp ayıklanamamasına bağlıdır.

Edison bu kelimeyi tek seferlik kullanmadı; not defterlerinde ve yazışmalarında tekrar tekrar geçer. 1888'de telgraf uzmanı William Maver, quadruplex telgraf sisteminin bilinen bir arıza eğiliminden söz ederken "buna bug denir, bu adı ilk veren Edison'dur" diye yazar.

Telgrafçıların "bug"ı

Terim, 19. yüzyıl sonunda telgraf dünyasında iyice yerleşti. Öyle ki, hızlı mors kodu göndermeye yarayan yarı otomatik telgraf anahtarlarına da "bug key" deniyordu — Vibroplex marka anahtarların üzerinde bugün bile bir böcek logosu vardır.

Yani 1940'lara gelindiğinde, "bug" mühendislik jargonunda zaten yerleşmiş bir kelimeydi. Bu, birazdan anlatacağımız ünlü hikâyenin anlamını tamamen değiştiriyor.

3. 9 Eylül 1947: Meşhur Güve

İşte teknoloji tarihinin en çok anlatılan hikâyesi.

Yer: Harvard Üniversitesi, Bilgisayar Laboratuvarı.

Makine: Harvard Mark II Aiken Relay Calculator — röleli, devasa, elektromekanik bir bilgisayar.

Tarih: 9 Eylül 1947.

Makine hatalı sonuçlar üretiyordu. Ekip arızayı aramaya koyuldu ve F panelinin 70 numaralı rölesinde sıkışmış bir güve buldu. Güveyi cımbızla çıkardılar, laboratuvar kayıt defterine bantladılar ve yanına şu notu düştüler:

"First actual case of bug being found." ("Bir bug'ın bulunduğu ilk gerçek vaka.")

Bu defter sayfası, güve hâlâ üzerinde bantlı hâlde, bugün Smithsonian Ulusal Amerikan Tarihi Müzesi koleksiyonunda bulunuyor.

Hikâyenin efsaneleşen kısmı — ve gerçek

Bu olay genellikle şöyle anlatılır: "İlk bilgisayar bug'ı gerçek bir böcekti ve Grace Hopper bulmuştu. 'Bug' kelimesi buradan doğdu."

Bunun üç sorunu var:

1. Kelime zaten vardı. Yukarıda gördük — Edison 1878'de kullanıyordu. Notun kendisi bunu ele veriyor: "first actual case" yani "gerçek bir vakanın ilk örneği". Bu cümle ancak, ekip "bug" kelimesini mecazi anlamda zaten kullanıyorsa esprili olur. Not bir keşif duyurusu değil, bir şakadır: "Yıllardır bug diyoruz, bu sefer gerçekten bir böcek çıktı!"

2. Grace Hopper muhtemelen güveyi bulan kişi değildi. Hopper o dönem Mark II ekibindeydi ve hikâyeyi yıllarca büyük bir keyifle anlattı — bu yüzden olay onun adıyla anılır hale geldi. Ancak defterdeki not onun el yazısı değil ve olay anında laboratuvarda bulunduğuna dair kesin bir kayıt yok. Hopper efsanenin anlatıcısıdır, kahramanı değil.

3. "İlk" değil. Röleli makinelerde böcek kaynaklı arızalar bilinen bir sorundu; bu, kayda geçmiş en ünlü örnek — ilk örnek değil.

Peki hikâye değersiz mi? Kesinlikle hayır. O güve, soyut bir mühendislik terimine fiziksel bir gövde kazandırdı. Bir kelimenin neden 80 yıl boyunca hiç ölmediğini açıklamak istiyorsanız, cevap budur: insanlar tanımları unutur, hikâyeleri unutmaz.

4. "Debug" Nereden Geliyor?

De- öneki İngilizcede "ayıklamak, gidermek, uzaklaştırmak" anlamı katar (de-ice = buz çözmek, de-frost = buz gidermek). Debug = "bug'ları ayıklamak".

İlginç olan, "debugging" kelimesinin de bilgisayarlardan önce kullanılıyor olması: 1940'larda havacılık sektöründe, uçak motorlarındaki sorunların giderilmesi için kullanıldığına dair kayıtlar var. Bilgisayar bağlamındaki yaygın kullanımı ise 1950'lerde oturdu.

Türkçede karşılığı: hata ayıklama. Türk Dil Kurumu ve yaygın kullanım "hata ayıklama"yı benimsemiştir — "böcek ayıklama" değil, çünkü Türkçeye çeviri anlam üzerinden yapılmıştır. Bugün Türkiye'deki yazılımcılar günlük konuşmada çoğunlukla İngilizce terimi ("bug", "debug etmek") kullanır; resmî dokümantasyonda ise "hata", "yazılım hatası", "hata ayıklama" tercih edilir.

5. Terminoloji: Bug, Hata, Kusur, Arıza Aynı Şey Değil

Günlük konuşmada hepsine "bug" deriz. Ama yazılım mühendisliği literatüründe (ISTQB ve IEEE standartları) bunlar farklı katmanlardır:

• Error / Mistake (hata) — İnsanın yaptığı yanlış (Geliştirici `<` yerine `<=` yazar)

• Defect / Fault / Bug (kusur) — Bu yanlışın koda yansımış hâli (Döngü bir fazla dönüyor)

• Failure (arıza) — Kusurun çalışma anında görünür hâle gelmesi (Uygulama listenin sonunda çöküyor)

Neden önemli? Çünkü her kusur arızaya dönüşmez. Bir bug yıllarca kodda oturabilir ve yalnızca çok özel bir girdi geldiğinde patlar. Bu yüzden Edsger Dijkstra'nın meşhur sözü hâlâ geçerlidir:

"Test etmek, hataların varlığını gösterir; yokluğunu değil."

Ayrıca bir ayrım daha: bug ≠ eksik özellik. Ürün istenen davranışı sergiliyor ama siz beğenmiyorsanız, bu bir bug değil, bir feature request'tir. Bu ayrımı yapamayan ekipler, hata takip sistemlerini dilek kutusuna dönüştürür.

6. Bug Türleri: Teknik Sınıflandırma

6.1. Klasik kategoriler

• Sözdizimi hatası (syntax error): Kod derlenmiyor bile. En zararsız tür — çünkü derleyici sizi hemen uyarır.

• Mantık hatası (logic error): Kod çalışır, ama yanlış sonuç verir. En sinsi tür.

• Çalışma zamanı hatası (runtime error): Sıfıra bölme, null referans, dosya bulunamadı.

• Off-by-one hatası: Döngünün bir fazla veya bir eksik dönmesi. Yazılımın en klasik hatası. ("Bilgisayar biliminde iki zor şey vardır: önbellek geçersizleştirme, isimlendirme ve bir eksik/fazla hatalar.")

• Yarış durumu (race condition): İki iş parçacığı aynı kaynağa aynı anda erişir; sonuç sıralamaya bağlı olarak değişir. Yeniden üretmesi cehennemdir.

• Bellek sızıntısı (memory leak): Ayrılan bellek geri verilmez; uygulama saatler içinde şişer.

• Taşma hataları (overflow): Sayı, veri tipinin sınırını aşar ve başa döner.

• Regresyon (regression): Bir zamanlar çalışan bir şey, yeni bir değişiklikten sonra bozulur.

• Güvenlik açığı (vulnerability): Sömürülebilen bug. Her açık bir bug'dır, ama her bug bir açık değildir.

6.2. Fizikçilerden ilham alan eğlenceli isimler

Programcılar, bazı bug türlerine fizikçilerin adını taşıyan lakaplar takmıştır:

• Heisenbug: İncelemeye kalkınca kaybolan bug. Debugger'ı açarsınız, hata yok olur; kapatırsınız, geri gelir. Adını Heisenberg'in belirsizlik ilkesinden ve gözlemci etkisinden alır. (Genellikle zamanlama, bellek düzeni veya optimizasyon farklarından kaynaklanır.)

• Bohrbug: Heisenbug'ın tam tersi — "sağlam, uslu" bug. Aynı koşullarda her seferinde aynı şekilde tekrar eder. Bohr'un öngörülebilir atom modeline atıf. Bir geliştiricinin en sevdiği bug türüdür, çünkü yeniden üretilebilen bug, çözülmüş bug demektir.

• Mandelbug: Nedeni o kadar karmaşık ve iç içedir ki, davranışı kaotik hatta rastgele görünür. Mandelbrot fraktallarına atıf. Aslında Heisenbug gibi görünen ama derinlemesine bakıldığında son derece karmaşık bir Bohrbug'dır.

• Schrödinbug: Biri kodu okuyup "bu şey nasıl çalışıyor ki, çalışmaması lazım" dediği anda ortaya çıkan bug. O ana kadar sorunsuz çalışmaktadır; farkına varıldığı anda herkes için bozulur. Schrödinger'in kedisine atıf.

• Hindenbug: Felaketle sonuçlanan bug. Veritabanını siler, sunucuyu düşürür. Hindenburg zeplin faciasından.

Bu isimler şaka gibi görünür ama gerçek bir işlevleri vardır: bir bug'ı doğru sınıflandırmak, onu nasıl avlayacağınızı belirler. Heisenbug'ı debugger ile kovalayamazsınız — loglama ve zamanlama analizi gerekir. Bohrbug'ı ise doğrudan adım adım izleyebilirsiniz.

7. Tarihe Geçen Bug'lar

Bug'ların çoğu can sıkıcıdır. Bazılarıysa insanlık tarihine geçmiştir.

Mariner 1 (1962) — Bir tire işareti

NASA'nın Venüs sondası, fırlatıştan kısa süre sonra rotadan çıktı ve imha edilmek zorunda kaldı. Sebep olarak, rehberlik denklemlerinin el yazısı kopyasında bir üst çizgi (overbar) sembolünün atlanması gösterildi. Arthur C. Clarke olayı "tarihin en pahalı tiresi" diye anmıştır.

Therac-25 (1985–1987) — Bug'ların can aldığı dosya

Kanser tedavisinde kullanılan bu radyoterapi cihazı, en az altı hastaya ölümcül dozda radyasyon verdi; birkaç hasta hayatını kaybetti. Sebep, bir yarış durumuydu: operatör komutları çok hızlı girdiğinde, yazılım güvenlik kilidini atlıyordu. Daha önceki modellerde bu hatayı donanımsal bir emniyet sistemi engelliyordu; Therac-25'te o donanım kaldırılıp güvenlik tamamen yazılıma bırakılmıştı.

Bu vaka bugün dünyanın her yerinde yazılım mühendisliği etiği derslerinde okutulur. Çıkarılan ders: "Yazılım hallederiz" demek, bir emniyet katmanını kaldırmak için yeterli gerekçe değildir.

Pentium FDIV (1994) — Bölme yapamayan işlemci

Intel'in Pentium işlemcisi, belirli kayan noktalı bölme işlemlerinde yanlış sonuç veriyordu. Hata bir matematik profesörü tarafından fark edildi. Intel önce sorunu küçümsedi, kamuoyu baskısı büyüyünce geri çağırma yapmak zorunda kaldı — yaklaşık 475 milyon dolar maliyet.

Ariane 5, Uçuş 501 (1996) — Kopyala-yapıştır felaketi

Avrupa Uzay Ajansı'nın yeni roketi, fırlatıştan 37 saniye sonra parçalandı. Sebep: Ariane 4'ten aynen alınan bir atalet referans yazılımı. Ariane 5 çok daha hızlı yükseliyordu; yatay hız değeri 64-bit kayan noktadan 16-bit tam sayıya dönüştürülürken taştı. Dahası, hatalı sonuç veren birim yedek birimle aynı yazılımı çalıştırdığı için yedek de aynı anda çöktü. Zarar: yaklaşık 500 milyon dolar.

Ders: Yedeklilik (redundancy), ancak farklı bir hataya karşı koruma sağlar. Aynı yazılımı iki kez çalıştırmak yedeklilik değildir.

Mars Climate Orbiter (1999) — Birim karmaşası

Yörünge aracı Mars atmosferinde parçalandı. Sebep: yer kontrol yazılımı itki değerlerini pound-saniye (imperial), araç yazılımı ise newton-saniye (metrik) olarak yorumluyordu. Toplam kayıp: 320 milyon doları aşkın.

Y2K (2000) — Olmayan felaket mi, önlenen felaket mi?

Yılları iki haneyle saklayan eski sistemlerin 2000'i 1900 sanması korkusu. Dünya çapında yüz milyarlarca dolarlık düzeltme çalışması yapıldı ve 1 Ocak 2000'de kayda değer bir şey olmadı. Bugün hâlâ tartışılır: "abartılmış bir panik" miydi, yoksa başarıyla önlendiği için görünmez kalan bir felaket mi? Yazılım dünyasında sık rastlanan bir ironi: iyi yapılan önleyici işin ödülü, hiçbir şey olmamasıdır.

Knight Capital (2012) — 45 dakikada 440 milyon dolar

Bir Amerikan finans şirketi, yeni yazılımı sekiz sunucudan yalnızca yedisine kurdu. Sekizinci sunucuda, yıllar önce kullanımdan kaldırılmış eski bir test kodu, yeni bir bayrak (flag) tarafından yanlışlıkla yeniden etkinleştirildi. Sistem çılgınca alım-satım yapmaya başladı. 45 dakikada 440 milyon dolar kaybedildi; şirket iflasın eşiğine geldi ve satıldı.

Ders: Deployment tutarsızlığı ve ölü kod, tek başına yıkıcı olabilir.

Heartbleed (2014) — İnternetin yarısını açan iki satır

OpenSSL kütüphanesindeki bir sınır kontrolü eksikliği, saldırganların sunucu belleğinden rastgele veri (şifreler, özel anahtarlar) okumasına izin veriyordu. İnternetin büyük bölümünü etkiledi. Kritik nokta: OpenSSL, milyarlarca cihazın güvendiği ama neredeyse hiç kimsenin fonlamadığı, bir avuç gönüllünün sürdürdüğü bir projeydi.

CrowdStrike (Temmuz 2024) — Bir güncelleme, küresel felç

Bir güvenlik yazılımının hatalı içerik güncellemesi, dünya genelinde milyonlarca Windows makinesini mavi ekrana düşürdü. Havayolları uçuş iptal etti, hastaneler randevu erteledi, bankalar durdu. Kod hatasının kendisi küçüktü; yıkıcı olan, dağıtım mekanizmasının aşamalı olmamasıydı — güncelleme tüm dünyaya aynı anda gitti.

Ders: Bug'ın büyüklüğü etkisini belirlemez; yayılma hızı belirler.

8. Bug'ın Yaşam Döngüsü: Bulunduktan Sonra Ne Olur?

Profesyonel ekiplerde bir bug şu yoldan geçer:

• 1. Raporlama — Kullanıcı, test uzmanı veya izleme sistemi bildirir.

• 2. Yeniden üretme (reproduce) — En kritik adım. Yeniden üretilemeyen bug, düzeltilemeyen bug'dır. İyi bir rapor şunları içerir: adımlar, beklenen sonuç, gerçekleşen sonuç, ortam bilgisi, log/ekran görüntüsü.

• 3. Triyaj (triage) — İki ayrı eksende değerlendirilir:

• Severity (şiddet): Teknik etki ne kadar büyük? (Veri kaybı mı, yazım hatası mı?)

• Priority (öncelik): Ne kadar acil düzeltilmeli? (İş açısından)

Bu ikisi karıştırılır ama farklıdır: Ana sayfadaki şirket adının yanlış yazılması düşük şiddetli ama yüksek öncelikli bir bug'dır.

• 4. Atama ve kök neden analizi — Semptom değil, sebep aranır.

• 5. Düzeltme (fix)

• 6. Regresyon testi — Düzeltmenin başka bir şeyi bozmadığından emin olunur. Bu adım atlandığında, düzeltme yeni bug doğurur.

• 7. Kapatma — Ve ideal olarak: aynı bug'ın bir daha oluşmasını engelleyecek bir otomatik test eklenir.

Araçlar: Bugzilla (1998, açık kaynak, tür için standart oluşturdu), Jira, GitHub Issues, Linear, Sentry (otomatik hata yakalama).

9. Bug'ların Maliyeti ve "Sıfır Bug" Miti

Yazılım mühendisliğinin en eski bulgularından biri şudur: bir hatanın düzeltilme maliyeti, keşfedildiği aşamaya göre katlanarak artar. Gereksinim aşamasında yakalanan bir hatanın maliyeti neredeyse sıfırken, aynı hatanın üretim ortamında yakalanması onlarca hatta yüzlerce kat pahalıya patlar — çünkü artık sadece kodu değil, bozulmuş veriyi, itibarı ve müşteriyi de düzeltmeniz gerekir.

Bu yüzden modern pratikler hatayı "sola kaydırmayı" (shift left) hedefler: kod incelemesi, statik analiz, birim testleri, tip sistemleri, CI/CD kontrolleri.

Peki sıfır bug mümkün mü? Pratikte hayır.

• Rice teoremi ve durma problemi, bir programın belirli davranışlarını genel olarak otomatik doğrulamanın teorik olarak imkânsız olduğunu gösterir.

• Test, sonsuz girdi uzayının yalnızca bir örneklemini kapsar.

• Yazılım, üzerinde çalıştığı donanım, işletim sistemi ve ağdaki değişikliklerle birlikte "bozulur" — kod değişmese bile.

Bunun bir istisnası var: formel doğrulama (formal verification). Matematiksel ispatla kodun belirli özelliklerini garanti eden bu yöntem, seL4 mikroçekirdeği veya CompCert derleyicisi gibi projelerde uygulanmıştır. Ama son derece pahalıdır ve yalnızca uçak, uzay, nükleer, tıbbi cihaz gibi hataya yer olmayan alanlarda ekonomik olarak anlam kazanır.

Bu yüzden sektör "sıfır bug" yerine "kabul edilebilir risk" üzerine kuruludur. Soru "hata var mı?" değil, "hangi hatalar kabul edilebilir ve hangileri asla?" sorusudur.

10. "It's not a bug, it's a feature" — Kültürel Bir Klasik

Yazılım dünyasının en bilinen esprisi: "Bu bir bug değil, bir özellik."

Genellikle savunmaya geçen bir geliştiricinin şakası olarak kullanılır. Ama arkasında gerçek bir olgu vardır: bazı bug'lar zamanla o kadar benimsenir ki, düzeltmek daha büyük soruna yol açar.

En ünlü örneklerden biri Space Invaders'tır: oyundaki uzaylılar, sayıları azaldıkça hızlanır. Bu bir tasarım kararı değildi — donanım az sayıda nesneyi daha hızlı çizebiliyordu. Ama oyunculara bu "gerilim artışı" o kadar iyi geldi ki, oyun tarihinin en ikonik mekaniklerinden birine dönüştü.

Yazılımda buna bağlı bir yasa da vardır — Hyrum Yasası: Bir API'nin kullanıcı sayısı yeterince arttığında, sözleşmede ne yazdığının önemi kalmaz; sistemin gözlemlenebilir tüm davranışları birileri tarafından bağımlılık haline getirilmiştir. Yani bir bug'ı düzeltmek, birinin ürününü bozmak anlamına gelebilir.

11. Bug Ödül Programları (Bug Bounty)

1995'te Netscape, tarayıcısındaki güvenlik açıklarını bildirenlere ödül veren ilk programlardan birini başlattı. Bugün Google, Apple, Microsoft, Meta ve devletler dahil sayısız kurum, kritik açıklar için altı haneli tutarlar ödüyor.

Mantık basit ve güçlü: Bir güvenlik açığının fiyatı, karaborsada da vardır. Yasal kanaldan daha iyi ödeme ve tanınırlık sunarsanız, açıkları bulan insanların büyük kısmını doğru tarafa çekersiniz.

HackerOne, Bugcrowd gibi platformlar bu ekosistemi kurumsallaştırdı. Ve böylece "bug" kelimesi, 19. yüzyılda bir arıza adıyken, 21. yüzyılda bir meslek haline geldi.

12. Yapay Zekâ Çağında Bug

Son birkaç yıl, bug kavramına yeni katmanlar ekledi:

Yapay zekâ bug bulmada iyi. Statik analiz araçları artık dil modelleriyle destekleniyor; kod incelemesinde insanın gözünden kaçan null kontrolleri, sınır durumları ve güvenlik desenleri yakalanabiliyor. Otomatik test üretimi ve fuzzing, LLM'lerle belirgin şekilde güçlendi.

Yapay zekâ bug üretmede de iyi. Model tarafından üretilen kod sözdizimsel olarak kusursuz görünürken mantıksal olarak yanlış olabilir. Daha tehlikelisi, inandırıcı görünmesidir — insan yazımı hatalı kod genellikle "acemi" görünür, model çıktısı ise temiz ve profesyonel görünür. Bu, kod incelemesinde yanlış bir güven duygusu yaratır.

Yeni bir bug sınıfı doğdu. Klasik yazılımda bug, kodun içindedir. Makine öğrenmesi sistemlerinde ise hata; eğitim verisinde, model ağırlıklarında, dağıtım kaymasında (data drift) veya istem (prompt) tasarımında olabilir. Bunların hiçbiri bir debugger'la adım adım izlenebilecek şeyler değildir. Sektör bu yeni sorunlar için hâlâ ortak bir dil arıyor — bugün kullanılan "halüsinasyon", "jailbreak", "prompt injection" gibi terimler, 2020'lerin "bug"ıdır.

Belki de birkaç on yıl sonra biri, bu terimlerin nereden geldiğini araştıran bir yazı yazacak.

13. Sık Sorulan Sorular

İlk bilgisayar bug'ı gerçekten bir böcek miydi?

Hayır — ama gerçekten bir böcek bulundu. 1947'deki güve, kelimenin kaynağı değil, en ünlü örneğiydi. Kelime 1878'den beri kullanılıyordu.

Grace Hopper "bug" kelimesini icat etti mi?

Hayır. Onu icat etmedi, hatta muhtemelen o güveyi bulan kişi de değildi. Ama hikâyeyi anlatarak ölümsüzleştirdi.

Bug ile hata (error) arasındaki fark ne?

Error insanın yaptığı yanlış, bug (defect) o yanlışın koddaki hâli, failure ise çalışma anında ortaya çıkan sonuçtur.

Türkçesi ne?

Resmî karşılığı "yazılım hatası"; debug için "hata ayıklama" kullanılır. Günlük konuşmada sektör çoğunlukla İngilizce terimi tercih eder.

Bug'sız yazılım yazılabilir mi?

Küçük ve kritik sistemler için formel doğrulamayla yaklaşılabilir; ama genel amaçlı büyük yazılımlarda pratik olarak mümkün değildir. Hedef sıfır bug değil, kabul edilebilir risk ve hızlı toparlanmadır.

14. Sonuç: Bir Kelimenin 150 Yıllık Yolculuğu

"Bug" kelimesinin hikâyesi, teknolojinin kendi hikâyesinin küçük bir modeli gibi.

Orta Çağ İngiltere'sinde görünmez bir umacıydı. 1878'de Edison'un laboratuvarında mühendisin baş edemediği küçük arıza oldu. 1947'de Harvard'da bir kayıt defterine bantlanmış gerçek bir güve olarak somutlaştı. 1996'da bir roketi havada patlattı, 2012'de bir şirketi 45 dakikada bitirdi, 2024'te dünyanın havaalanlarını durdurdu. Ve bugün, onu bulanlara altı haneli ödüller ödeyen bir sektör var.

Ama kelimenin taşıdığı asıl anlam hiç değişmedi: bug, sistemin içinde saklanan, görmediğiniz ve sizi rahatsız eden şeydir. 14. yüzyıldaki umacıdan bugüne kadar tam olarak aynı korku.

Ve bir yazılımcının işi, o umacıyı bulup ışığa tutmaktır.

Kaynaklar

• Log Book With Computer Bug — Smithsonian National Museum of American History

• Did You Know Edison Coined the Term "Bug"? — IEEE Spectrum

• The Bug in the Computer Bug Story — JSTOR Daily

• Heisenbug — Wikipedia

• List of software bugs — Wikipedia

• 11 of the most costly software errors in history — Raygun

• The Most Expensive Software Bugs in History — Techfellow

• The First Computer Bug: How A Moth Became A Tech Legend — Quantum Zeitgeist