Bu bir hata değil, bu bir özellik — anlamı, kökeni ve farkları

“Bu bir hata değil, bu bir özellik” ne anlama geliyor

“Bu bir hata değil, bu bir özellik” — bir geliştirici veya yöneticinin, programın beklenmedik davranışının hatalı değil kasıtlı olduğunu belirtmek için kullandığı bir ifadedir. Klasik durumda, bu bir şakadır: herkes davranışın yanlış olduğunu anlar, ancak gerilimi azaltmak için ona “özellik” denir. Ancak gerçek projelerde, ifade ciddi anlamda da kullanılır — davranış gerçekten spesifikasyona uygun olduğunda ancak kullanıcının beklentilerini karşılamadığında.

Bir hata ile bir özellik arasındaki fark genellikle özneldir. Kodu yazan geliştirici için belirli bir davranış mantıklı görünebilir. Bir kullanıcı için beklenmedik ve hatalı görünebilir. Algının öznelliği, ifadenin bu kadar kalıcı olmasının ana nedenidir. Konuşmayı “kim suçlu” dan “böyle tasarlandı” ya kaydırır. UX Collective’e göre, kullanıcılar tarafından bildirilen hataların %40’ı aslında UX sorunlarıdır, kod hataları değil.

Çevik ekiplerde, ifade genellikle demolar sırasında bir savunma mekanizması olarak kullanılır. Geliştirici beklenmedik bir davranış gösterir, ürün sahibi kaşlarını çatar ve kader ifadesi “bu bir hata değil, bu bir özellik” söylenir. Ekipteki güven, ifadenin bir şaka olarak mı yoksa bir sorunu gizleme girişimi olarak mı algılanacağını belirler. Sağlıklı bir ekipte böyle bir şaka ortamı yatıştırır, toksik bir ekipte çatışmaya neden olur.

İkonik ifadenin ortaya çıkış tarihi

İfadenin bilinen ilk kullanımı 1976’da DECUS (Digital Equipment Corporation User Society) bülteninde kaydedildi. Bir kullanıcı, RUNOFF metin işlemcisinin boş satırları yanlış işlediğinden şikayet etti. Geliştiricinin yanıtı: “Bu bir hata değil, bu bir özellik — paragraflar böyle işlenir.” O zamandan beri ifade, gerçek kalitesinden bağımsız olarak “olduğu gibi” yazılan kodu savunmanın sembolü haline geldi.

İfadenin popülerleşmesine Jargon File katkıda bulundu — 1990’larda “The New Hacker’s Dictionary” kitabının temelini oluşturan bir hacker argo sözlüğü. Jargon File’da “feature” girişi, düzeltilmesi imkansız veya istenmeyen olduğu için özellik haline gelen hatalara doğrudan atıfta bulunur. Örnek: ilk terminallerdeki Caps Lock tuşunun gösterge ışığı yoktu — bu, “kör yazma için” bir özellik haline gelen bir hataydı.

2000’lerde ifade, internet memleri aracılığıyla popüler kültüre geçti. “It’s not a bug, it’s a feature” başlıklı bir kedi resmi forumlara ve sosyal medyaya yayıldı. Oyun endüstrisinde ifade özellikle sık kullanılır: oynanışı etkilemeyen hatalar, atmosfer için “özellik” olarak ilan edilir. Kültürel fenomen BT’nin çok ötesine yayıldı — ifade, bir hatanın mazur görüldüğü her bağlamda duyulabilir.

Bahanenin psikolojisi: neden böyle söylenir

İfadenin psikolojik temeli bilişsel uyumsuzluktur. Bir geliştirici kod yazmak için saatler harcamıştır ve sonucun yanlış olduğunu kabul etmek, emeğini değersizleştirmek anlamına gelir. “Bu bir hata değil, bu bir özellik” ifadesi uyumsuzluğu azaltır: hata kasıtlı bir karara dönüşür ve geliştirici suçlu olmaktan fikrin yazarı olmaya geçer. Bu, benlik saygısını koruyan psikolojik bir savunma mekanizmasıdır.

İkinci neden yeniden çalışma korkusudur. Bir hatayı kabul etmek, kod incelemesi, test etme ve dağıtımı yeniden yapmak anlamına gelir. Bir “özellik” düzeltme gerektirmez — görev kapatılır, iş yükü azalır. Microsoft Research’e göre, geliştiriciler vakaların %23’ünde yeniden çalışmadan kaçınmak için kasıtlı olarak hataların ciddiyetini düşük gösterir. İfade, bu düşük göstermenin hafif bir biçimidir.

Üçüncü neden kurum kültürüdür. Bazı şirketlerde hatalar geliştiricinin KPI’larını etkiler ve kod incelemesinde bir hata bulmak, yazarın hatası olarak kabul edilir. Böyle bir ortamda, “bu bir hata değil, bu bir özellik” ifadesi, kariyer için olumsuz sonuçlardan kaçınmanın bir yoludur. Sağlıklı bir hata kültürü (suçlamasız kültür) bu nedeni ortadan kaldırır: hatalar cezalandırılmazsa, onları kabul etmek daha kolaydır.

Hata ve özellik arasındaki sınır nerede

Net bir sınır yalnızca Kabul Kriterleri olduğunda vardır. Davranış herhangi bir Kabul Kriteri maddesiyle eşleşmiyorsa — bu bir hatadır. Davranış Kabul Kriterleriyle eşleşiyor ancak kullanıcı beğenmiyorsa — bu bir UX sorunudur, hata değil. Kabul Kriterleri yoksa — herhangi bir davranış özellik olarak ilan edilebilir ve ifadenin kalıcı olmasının ana nedeni budur.

Pratik bir kural: hata, bir programın spesifikasyona göre yapmaması gereken bir şeyi yapması veya yapması gereken bir şeyi yapmamasıdır. Özellik, sonuç kullanıcıyı şaşırtsa bile programın amaçlananı yapmasıdır. Sınır durumları: tanımsız davranış (dil sonucu tanımlamaz), yarış koşulları (düzensiz görünür), uç değerler (verilerin %99’u için çalışır).

Açıklık için bir karar matrisi kullanın:

• Davranış spesifikasyonda tanımlanmış ve doğru uygulanmış — özellik, beğenmeseniz bile
• Davranış tanımlanmış ancak yanlış uygulanmış — hata, düzeltme gerekli
• Davranış tanımlanmamış ancak gereksinimlerden mantıksal olarak çıkıyor — belgelenmemiş özellik, spesifikasyona eklenmeli
• Davranış tanımlanmamış ve mantıksız — hata, gereksinimlerin netleştirilmesi gerekli

En tehlikeli durum, spesifikasyon olmadığında ve geliştiricinin kendi başına neyin özellik olduğuna karar vermesidir. Bu tür projelerde, herhangi bir hata “özellik” olarak ilan edilebilir ve bu da kodu tüm ekip için öngörülemez hale getirir. Her görev için net Kabul Kriterleri — sınırı nesnel olarak çizmenin tek yolu.

Ekipte kavramların değiştirilmesi neden tehlikeli

İlk tehlike — kalite erozyonu. Her hata özellik olarak ilan edilebiliyorsa, ekibin kaliteli kod yazmak için teşviği yoktur. Hatalar düzeltilmez, teknik borç artar ve kullanıcılar “garip davranışa” alışır. Er ya da geç, bir rakip öngörülebilir şekilde çalışan bir ürün çıkarır ve kullanıcılar gider.

İkinci tehlike — ekiptye çatışma. Bir QA mühendisi bir hata bulur, geliştirici “bu bir özellik” der. Nesnel kriterler (Kabul Kriterleri) olmadan, tartışma kişisel bir boyuta taşınır: “testi kötü yapıyorsun” vs “programlamayı kötü yapıyorsun”. PractiTest State of Testing 2023’e göre, “hata vs özellik” anlaşmazlıkları, QA ve geliştiriciler arasındaki sürtüşmenin ilk üç nedeninden biridir.

Üçüncü tehlike — yasal riskler. Düzenlemeye tabi sektörlerde (tıp, finans, havacılık), “hata” ve “özellik” kavramları yasal ağırlığa sahiptir. Tıbbi bir yazılımda bir davranış özellik olarak ilan edilirse ancak yanlış dozaj hesaplamasına yol açarsa — bu bir şaka değil, düzenleyici gerekliliklerin ihlalidir. Güvenlik açısından kritik sistemler kavramların değiştirilmesini tolere etmez, bu nedenle her zaman biçimsel doğrulama kullanırlar.

Hata ve özellik arasındaki karışıklık nasıl önlenir

Ana araç — her görevde net Kabul Kriterleri. Kabul Kriterleri geliştirme başlamadan önce yazılır: “X girildiğinde, sistem Y çıktısını vermelidir.” Davranış tanımlanmamışsa — varsayılan olarak hatadır, geliştirici aksini düşünse bile. Kabul Kriterleri ölçülebilir ve doğrulanabilir olmalıdır: “düğme yeşil” kötüdür, “HEX #00FF00” iyidir.

İkinci araç — ekipte bir Tamamlanma Tanımı. “Görev tamamlandı” nın ne anlama geldiğinin net bir açıklaması: kod yazıldı, testler yazıldı, testler geçti, kod incelemesi tamamlandı, staging’e dağıtıldı, QA tarafından test edildi. Tamamlanma Tanımı’nın tüm maddeleri karşılanmışsa ve kullanıcı hala şikayet ediyorsa — bu bir hata değil, backlog’a yeni bir özellik olarak giren eksik bir gereksinimdir.

Üçüncü araç — suçlamasız olay sonrası analiz kültürü. Bir hata özellik olarak ilan edilip üretime gittiyse — nedenleri analiz ederiz, suçlu aramayız. Geliştirici neden bunun bir özellik olduğunu düşündü? QA neden gözden kaçırdı? Kabul Kriterleri neden eksikti? Bu soruların yanıtları süreci iyileştirir, insanları cezalandırmaz. Sistemsel iyileştirmeler, “bu bir hata değil, bu bir özellik” ifadesini yasaklamaktan daha etkili çalışır.