Yazılımsal Safsatalar

Kariyerimin son 10 yılı irili ufaklı bir çok projeyi tamamlamak ile geçti. Bazıları çok öğreticiydi (bloket.pro) bazıları çok eziyetliydi (maestropanel.com) bazıları ufuk açıcıydı (yuex.com), bazıları da çok eğlenceliydi (headball2.com). Onlarca hata yaptık, çok şey öğrendik, tecrübelendik ve şimdi de başka bir zorlu projedeyiz… 🧙

Tüm bu yazılımsal faaliyetlerde bulunurken sayısız karar verme fırtınasında, doğru yolu bulmak için pruvamızı hep neta alametlere çevirdik (*Amat okuduktan sonra ben *🤲). Bazen neyin doğru olduğunu bulmak yerine kimin haklı olduğu yanlışına düştük. Bilinçli ya da bilinçsiz onlarca Safsata üretip işin özünden koptuk, egolarımıza yenik düşüp görülmemiş safsatalar ile saldırdık, safsatalara kurban gittik… 🚬 Yüksek dozda safsatalara maruz kaldığında zamanla bir desen olduğunu fark ediyorsun. İnsanlar değişse de argümanlar aynı kalıyor, desenleri yakalamak kolaylaşıyor. Ardından Safsata olarak belirlemek kolay oluyor.

İşin farkına vardıktan sonra büyük insan Aristoteles reizin taa MÖ 384 yılında safsataları tespit edip kategorilendirmiş olduğunu keşfettim. Bununla kalmamış bir de Sophistical Refutations eseri ile ölümsüzleştirmiş. Tabi okuduktan sonra esinlenerek, naçizane safsata olarak avladığım bazı argümanları yazmaya karar verdim… Giderek bir spor halini aldı, hem de sıkıcı toplantılara bir renk katabildim.

Bu yazıda ağırlıklı olarak karşılaştığım teknik safsataları derledim… İyi okumalar 🍻

Not: Konu hakkında başlangıç için Tevfik Uyar’ın Safsatalar kitabını ve fularsızın Safsatalar Ansiklopedisini öneririm.

Unit Test Mevzusu…

İlk olarak test mevzusuna değinmek istiyorum, çünkü bunu her proje başında tartışıp faydalarını ve zararlarını masaya yatırılması ile ilgili tekrar eden tartışmalarımız oluyor.

Endüstri jargonunda konuşmak gerekirse, yazılım projeleri entropiktir! Sürekli kötüye giderler. Biz emektarlar ise bu kötü gidişi en az maliyetle yönetmeye çalışırız. Bunun için en önemli silahlarımızdan biri de Unit Test’lerdir.

Bir kaç orta ölçekli proje geliştirmiş Developer insanının çoktan fark ettiği üzere Code Base büyüdükçe yönetimi zorlaşır ve yeni özellikleri eklemenin maliyeti dayanılmaz olur. Karmaşıklık üssel olarak büyür de büyür. Bu durumu çok kez yaşadığımdan dolayı Unit Test ve bakımı için ayrılan zamanı yazılım geliştirmenin doğal bir parçası görmeyi öğreniyorsun.

https://www.monkeyuser.com/2022/unit-tests/

Test’lerle ilgili çok karşılaştığım bir kaç söylemi aşağıda belirttim. Bunları yakalayıp makul bir şekilde çürütmek projenin gidişatını da etkileyen durumlardır…

Yeni eklenen özellik için Unit Test yazarsam zamanında yetiştiremem…

Yukarıdaki söylemin tercümesi şu 👉 “Ben yeni eklenen özelliğin canlıya çıktıktan sonraki hatalarını düzeltmek için büyük zaman ve para harcayabilirim ve bu maliyeti görmezden gelebilirim.” Genuine but Insignificant Cause — İhmal Edilebilir Safsatası diyebiliriz.

Zamanında yetiştiremiyorsan belki test yazmanı hızlandırman gerekiyor olabilir. Code Kata’lar bunun için yapılıyor. Gel gelelim bir zaman verirken de Development’ın içinde olan bir kavramı göz önüne alıp değerlendirmeyi içselleştirmemiz lazım.

Skeptik olup kendi doğrularımızın peşinden koşalım! Örneğin, bir özellik için test yazmayın. Diğer bir özellik için Test Coverage’ı %80 civarında tutun. İki özelliğin de yaşam döngüsündeki bakımını takip edin (Cycle Time ve Defect Rate). Aradaki fark özellik için katlandığınız gizli maliyetiniz olacak.

https://raygun.com/blog/cost-of-software-errors/

Bazı fonksiyonlar için Unit Test çok gereksiz kalıyor…

Söylem, biraz istisna safsatasını andırmakla beraber argümana odaklandığımızda doğru olabilecek bir cümle. Endüstri, yazılım projelerinde Code Coverage’i genelde %85 civarında olmasını yeterli görür. Nedeni ise %100 Coverage’e yaklaşıldıkça Unit Test’lerinin maliyetinin katlanarak artması ve yazılım kalitesine etkisinin azalması. O nedenle %90'dan az %80'den çok olan bir değer makbuldür.

Burada neden bazı fonksiyonlar için testin gereksiz kaldığının gerekçesi önemli hale geliyor. O cevabı aldığımızda söylem safsatadan çıkar.

Unutmayalım ki, yazılım biriminin çalışıp çalışmadığını anlamanın en ucuz yolu Unit Test’tir. Aşırı kullanımın olumsuz etkileri vardır doğru, fakat makul seviyede fonksiyonları Unit Test ile kapsamamız yazılım kalitesini arttırır. 🤷‍♀

Unit Test yazıyoruz yine Bug çıkıyor…

Unit Test’ler uzaktan sanki yazılımın tüm kalitesini ve sağlığını kendi başına sağlayan “Silver Bullet” gibi görülebiliyor. Halbuki Unit Test’ler yazıldığı kadar akıllıdır… Bu yüzden yazılım sağlığını direkt bu kavrama bağlamak onlarca parametreyi görmezden gelinmesine neden olur.

1947'den beri yazılım sporunun çıktılarından biri de bildiğimiz gibi Bug yani hatalardır. Bundan kaçamayız, ancak kaçınabiliriz. Hatalarla yaşamayı ve yönetmeyi öğrenmeliyiz. Unit Test’ler kodun amaçlanan şeyi yaptığını söyler (bu bile yeterli değildir), kodda bir Bug olabileceğini söylemez. 🤷‍♂️

Unit Test yazalım yazmasına da. Q.A. takımı ne güne duruyor..?

https://media.giphy.com/media/32TX9Sfl8rpKN4q2gn/giphy.gif

Developer’ın dostu, prestijlerinin emniyeti QA (Quality Assurance) insanlarının salt Bug arayan robotlara indirgenmesine karşıyım. QA takımının işin içine kendi zekasını katabileceği, kaliteye, ürüne ve kullanıcı deneyimine katkı sağlayabileceği bir ortam yaratılması gerekir. Öncelikle bunu söylemeden konuya geçemeyeceğim. 🍻

Developer’ın topu QA’e atmasındaki toksik durumu es geçip olaya odaklanırsak…

Buradaki esas olay hatanın QA aşamasında bulunmasının getirdiği büyük maliyet.

Daha önce de belirtmiştim. Yazılan kodun çalışıp çalışmadığını en hızlı ve en az maliyetli olarak Unit Test’ler ile öğrenebiliyoruz. Yani ne kadar erken fail edersek o kadar iyi. QA takımından dönen hatanın maliyeti, Development’dan dönen hata maliyetinin 150 katı!

https://azevedorafaela.com/2018/04/27/what-is-the-cost-of-a-bug/

“X” firma hiç Unit Test yazmıyor ama bak ürünleri ne kadar başarılı…

Bu söylem tam bir safsata kombosu. İçinde ad Hominem, Whataboutism, Otoriteye Başvurma, Çoğunluğa Başvurma ve zorlasan Tu Quoque bile var.

Dünyada önemli yazılım kavramlarını görmezden gelen ama piyasada başarılı kabul edilen bir çok yazılım var. Bu firmalar test yazmıyorsa demek ki bizim de yazmamıza gerek yok gibi bir mantığı kabul edersek. Düz Dünyacıları da ciddiye almamız gerekir, onları ciddiye alırsak Reptilian’lara kadar gider iş 🎃

Neyse konuya dönelim;

Unit Test yazmanın ana amacının ürünün bakım maliyetlerini düşürmek olduğundan hemfikir olduğumuzu varsayıyorum. Yukarıda öne sürülen argümanın kaçırdığı nokta da burası. Bakım maliyeti! hemen ardından genişleyebilme yeteneği.

Başarılı sayılan yazılımlar test yazmıyorlarsa emin olun bir özellik eklemek için haddinden fazla süre gerekiyordur (spekülasyon 😈), kararlı hale gelmesi içinde üzerinden bir hayli zaman geçiyordur. Çünkü tüm süreç el yordamı ile ilerler ve üssel olarak zorluğu artar. Taa ki bir T noktasına gelip yönetilemez hal alana kadar… Bu bir tercihtir business bunu gerektiriyorsa yapılır ama sonuçları yüksek faizli borç etkisi gibidir.

Sırf yukarıdaki durum olmasın diye Extreme Programming, TDD, SOLID vs. gibi pratikler projedeki karmaşayı yönetip bir düğüm yumağı haline gelmesin diye ortaya atıldığını da unutmayalım…

Unit Test yazana kadar önce günlük toplantılara (scrum’daki daily kast ediliyor) katılmayı öğrenelim…

Bir code review sırasında “Bunun testleri yok mu?” diye sorduğumda aldığım güzel bir cevap.

Argumentum ad Hominem, bir nevi karalama safsatası. Günlük toplantılara katılmanın Unit Test ile pek bir alakası yok. Gel gelelim günlük toplantılara katıldığımızda testleri de otomatik olarak iyi yazacağımız gibi bir çıkarım da yapamayız… gibi savuşturulabilir.

- DEV1 : Ben tüm kodlarım için test yazarım arkadaş! - DEV2 : Ee.. ama yazdığın kritik modülde hiç test yok**

• DEV1 : Orası başka. Bir tek orada yok, oraya da gerek yok zaten…**

Bariz Exception Fallacy — İstisna Safsatası 🤘 oradaki kodun test edilmeye ihtiyacı olup olmadığının bir gerekçesi olması gerekir. Eğer var ise bir şekilde safsata olmaktan çıkar ama iş keyfi ise gerekçelendirilmesi gerekir veya oradaki testleri yazmak gerekir.

Bu özelliklerin bir de Unit Test’leri yazılacak! Proje yöneticisi bunun farkındadır umarım…

Bildiğimiz gibi yazılım geliştirme bir takım sporudur. Çoğunlukla çeşitli disiplinler vardır, aynı hedefe kilitlenmiş olsalar da doğal olarak öncelikler, korkular ve endişeler çok farklıdır. Nasıl bir Product Manager’ın ürünün büyümesi için yapması gereken Growth Hack yöntemlerini Development’a yansıtmadığı gibi, bir Developer’ın da yazılımı geliştirirken kendi yönetmesi gereken kavramları farklı disiplinlere yansıtmaması gerekir.

Bu aşamada ölçümlemeler önemli. Sizin kurguladığınız Development Life Cycle’ın tükettiği ölçü birimi (Story Point olabilir, Developer/Gün olabilir vs) üzerinden giderseniz böyle cümleler kurulmasının önüne geçilebilir.

Gerçek Dünya Bu kadar “Unit Test” övdükten sonra aşağıdaki tweet’ı de atabiliyor insan…

İşin garibi üzerinde çalıştığım projelerden code base’i kötü ve günü kurtaranlar daha başarılı oldu :) Tabi bunun teknik olmayan onlarca nedeni var ayrı konu ama bu kadar projeden sonra önemli olanın “çözümün kendisi” olduğunu anlamaya başlıyor insan…

[embed]Kitapta yazan tarlada yetişmez tweet’i 💩

Şirketim de Şirketim!

Aşağıdaki iki söylemi en çok duyduklarım arasına not almışım. Bir safsata olarak değil ama demotive edici bir etkisi olduğundan düşüncelerimi bir cevap niteliğinde belirtmek istedim.

Şirketim beni geliştirmiyor! beni geliştirecek bir şirkete geçiş yapmak istiyorum…

Zaman zaman bende bundan hayıflandığımı hatırlıyorum. İş rutine girince öğrenme ivmesi düşer de düşer. Burada yine biz uslu ve uyumlu beyaz yakalıların hayıflanmaktan öte yapacağı bir çok şey var 🫡

Bildiğiniz gibi şirketlerin amacı kar etmektir. Sizi geliştirmek gibi dertleri ikinci planladır veya yoktur. Var gibi görünse de sonuçta bunlar hep karlılık hedefinde atılan adımlardır. Doğrusu da budur.

Eğer köreldiğinizi hissediyorsanız bir şeyler öğrenmek için güzel bir bahane olabilir. Kendinize bir hedef koyup onu gerçekleştirecek adımları atmalısınız. Örneğin öğrenmek istediğiniz programlama dili ile ilgili Open Source bir proje açıp öğrenme ivmenizi koruyabilirsiniz veya yeni çıkan hype bir tool’u işinize adapte edebilirsiniz…

Kendinizi geliştirmeniz tamamen sizin sorumluluğunuzdadır, kimse şirketleri velisi gibi görmemeli ve kendinizi geliştirme sorumluluğunuzu şirketinize yıkmamalısınız. 💚

Şirketim/Yöneticim yeni teknolojilere karşı çok ilgisiz, halbuki projede kullansak büyük fark yaratacak…

Böyle bir FOMO hep vardır. Gel gelelim şirketin gündemi farklı olabilir, konsantrasyonu farklı olabilir. Böyle bir teknolojiye odaklanacağına içerideki bir çok şeyi iyileştirip aynı verimi alabilir veya yeterli görüp farklı hedefler belirleyebilir.

Burada şirketim günceli takip etmiyor diye seninde günceli takip etmemen, ilgisiz kalman IT sektöründe kabul edilemez. Yeni teknoloji ile PoC yapıp bunun artıları eksilerini spekülasyona yer vermeden ortaya koyup ikna edebilirsin. İkna edemesen de hype ile ilgili bilgin olur buda fark yaratmanı sağlayacaktır.

Bonus! 👇

Projede sürekli fikir değiştiriliyor. Sürekli yaptıklarımı çöpe atıyorum…

Hepimizin kesin duymuş olduğu bir söylem. Direkt safsata değil daha çok Developer’ın bakış açısı ile ilgili bir durum olarak tanımladım kendimce.

Bir ürün geliştirmek gerçekten karanlık odada fili el yordamı ile tanımaya benziyor. Çoğu zaman yanlış hipotezler üretip bunu hayata geçiriyoruz ve büyük israfalar yaratıyoruz. Bu süreçte işi somutlaştıran mühendis de günlerce yüksek konsantrasyon ile nakış gibi işlediği kodları yanlış hipotez yüzünden çöpe atabiliyor. Gerçekten yıpratıcı bir durum…

Gel gelelim bu yıpratıcı duruma daha profesyonel yaklaşarak aşabileceğimizi düşünüyorum. Sonuçta hipotezin üretilip, gerçekleştirilmesi bir süreç. Eğer bu süreç hoyratça kullanılıyorsa benim zaman kaybım değil şirketin zaman kaybı. Bu verimsizliğe neden olan unsurları bulmak Developer olarak benim değil ilgili kişilerin görevi. Ben gelen işi layıkıyla yaparım ve beğenirim. 🖖

Ek: Aslında biraz Toyota okumuş hipotez sahipleri (Product Owner, Product Manager, Designer vs.) hipotezi en az maliyetle test edebileceği yöntemleri biliyor ve şirketi yukarıdaki ortama sokmuyor. Sanırım buda Developer’ın SOLID’i bilip uygulamaması ile aynı şey.

Developer’dan Developer’a.

Bu bölümde Developer’ların Developer’lara karşı kullandıkları safsataları topladım. Söylemler size de kesin tanıdık gelecektir. Disiplinler arası durumlarda Ad Hominem çok görülüyor. Savunulamayacak durumlarda ise Yok Sayma, Sümen Altı ve Cımbızlama safsataları çok kullanışlı 😈

Haydi bakalım! 🐬

Biz video oyun yapıyoruz, yazılım geliştirmiyoruz…

Red Herring ya da Konuyu Saptırma Safsatası. Gaming alanında yazılımsal bir soruna çözüm bulmak için tartışırken denk geldim.

Aslında çok güzel bir temenni. Son zamanlarda da GPT-3 sağ olsun bunu gerçekleştirme yolunda ilerlediğimizi görüyorum hep 😎

Oyun geliştirirken gerçekten eğlenceyi yakalamak gerekiyor. Bunun teknik bir konu ile alakası yok “Gut Feeling” gerekiyor. Gel gelelim o gri alan, hissiyatı verebilmek için iyi kod bilgisine ihtiyacın var. İyi kod bilgisinden ziyade o kodu yönetecek yapıda bir mimari kurman gerekir ki eğlence stabil bir şekilde oyuncuya ulaşsın. İyi oyunların arkasında mükemmel bir mimarisi olmalı demiyorum ama yeteri kadar olması lazım. Ayıdan kaçmak için ayıdan hızlı olmana gerek yok, arkadaşından hızlı olsan yeter. 🙃

O nedenle iyi oyunlar, iyi kodlanmış olanlardır… 🤷‍♂

Not: Son zamanlarda Vampire Survivors’ın stabilitesi hakkında çok konuşuyoruz ve stabilitenin oyunun Retention’ına nasıl etkisi olduğuna tanık oluyoruz…

O bebe, bizim yanımızdaydı Vim’den çıkmayı bilmiyordu daha. Ne zaman Senior Developer oldu?

Ad Hominem ama “Adam Karalamalı”. Developer’lar akıllı insanlar, çok hızlı öğrenip çok hızlı adapte olabiliyorlar ve gelişiyorlar. Zaten bu değişime ayak uydurduğumuz için 6 ay önceki kodunuza dönüp baktığınızda utanıp, krizler geçiriyoruz.

O kozadaki bebe! güçlenip kozayı yırtıp çoktan afonfisli bir kelebeğe dönüştü bile.

Not: Yeri gelmişken de söylemiş olalım. “Senior Developer” titri yaşa göre değil yaptığı işlerin, bitirdiği projelerin ve yetiştirdiği kişilerin ona verdiği doğal bir rütbedir. Şirketlerin bireylere verdiği ünvanlar kozmetik ve politik olabileceğinden çok anlam yüklememek gerekir.

Sen o class’ı static yap. Ben takımın Senior Developer’ı olarak söylüyorum. X firmadaki Senior’de öyle yapıyor.

Argumentum ad Verecundiam safsatasına yaslanır. Basitçe alanında otorite olan birinin görüşünü kendi argümanını desteklemek için kullanmasına deniyor. Argumentum Ad Personam’a da yaslanabilir X firmadaki Senior Developer’ı karşıdaki insan tanıyor veya beğeniyorsa işe yarar.

Genelde Developer diyaloglarında bu tür safsataların geniş bir kullanım alanı var. Developer’ın kendinden daha az kıdemli ama daha çok bilgili olan başka bir Developer’ı ikna ederken çok yakalıyorum. İşe yaradığınıda söyleyebilirim 😈 tabi her zamanki gibi böyle safsatalar yerine daha somut argümanlar yeğdir. “Sen o class’ı static yap zaten sadece const tipinde değer tutan global sabitler olacak. Sen ne diyorsun peki?” gibi…

View-Model diye ayırmayalım. Çok iyi olmuyor, yazacak developer’ın kafası karışır, çok hata çıkar.

Fallacy of Slanting yani Sümen Altı Safsatası olabilir, Karmaşık Nedenler Safsatası olabilir ya da Fallacy of Limited Alternatives yani Sınırlı Seçenek Safsatası olabilir. İlk karşılaştığımda baya şaşırmıştım çünkü kafa karışıklığının nedenlerini düşünüp bulmak insana zor geliyor, hata çıkması garanti olduğu bir süreç için de hayır diyemiyorsunuz :)

Burada cümleye odaklanıp sorularla gerekçeleri almak gerekiyor. Neden çok iyi olmuyor? Developer’ın kafası nasıl karışabilir? gibi… Daha sonra bu pattern’in “Pros & Cons” tadında değerlendirmeleri masaya konulabilir.

Bu özelliği bir hafta içinde çıkmalıyız yoksa gelirlerimiz etkilenecek.

Bu söylemi garip ve iyi tasarlanmamış bir özelliğin Sprint’in ortasında ürüne eklenmesini tartışırken yakaladım. Developer’lar yeni özelliği anlamaya çalışırken sorulan soruları savunamayan arkadaş güzel bir kontra yapmıştı :)

Söylemin içinde korku var (Argumentum ad Baculum), dolduruşa getirme var (Poisoning The Well) biraz da tehdit var. Elbette istenilen özelliğin nasıl bir etki yaratacağını, eklenmez ise masada ne kadar para bırakılacağı net bir şekilde söylendiğinde safsata olmaktan çıkar.

O özelliği ekleriz ama sunucuya çok yük getirir. Onun yerine front-end tarafta halletsek daha iyi olur…

Özelliğin Client da mı yoksa Back-end’de mi çözüleceğini tartışmalarında Back-end Developer’ların çok kullandığı bir söylem. Gerekçelendirilmedikçe safsata olarak çok kullanılıyor.

Argument From Force yani Tehdit Safsatası sınıfına giren bir durumu var. Back-End tarafında sunucuya yük getirir demek insanı korkutur + maliyeti de arttırır o nedenle söylem biraz korkuya oynuyor. Tabi gerekçelendirildiğinde sorun yok. Örneğin kullanıcının büyük bir json çıktısını encrypt edip saklamayı back-end’de yapacağımıza client’da encryp edip göndersek sunucu CPU’sunu kullanmadan halledebiliriz” gibi bir durum ile açıklanması gerekir.

Gel gelelim Back-end’in can simidi olan söylem yeri geldiğinde kurban kişinin ispat edemeyeceğine güvenip kötü niyetle de kullanılmasına denk gelmedim değil. “Kullanıcı verilerini client’da diske kaydedelim. Sunuculara ve veritabanına çok yük bindirmeyelim” gibi… Bu hangi safsataya denk geliyor bilemedim :)

Bu ister kesin gelecek. Şimdiden yazdım koydum kenara…

Kendim dahil her seviyedeki Developer insanın kaçınması gereken yegane prensip YAGNI (You aren’t gonna need it). “Doğmamış çocuğa don biçmek” veya “Kasaptaki ete soğan doğramak” gibi güzel atasözlerimize denk geliyor.

Bütün yazılım endüstrisi bunu yapmayın diye bas bas bağırırken her yazılım tasarımında bir ucube olarak parlayan o gereksiz kod işte bu prensibin göz ardı edilmesi ile alakalı. Neyseki Martin Fowler peygamberimiz bununla alakalı bir yazı yazdıda kolayca paylaşıyoruz 👉https://martinfowler.com/bliki/Yagni.html

Ekipçe son zamanlarda yeni bir mimari yapı tasarlıyoruz ve o kadar çok Overthinking ve Overengineering’e yanlıyoruz ki inanamazsınız. Neredeyse herkesin görevi birbirimizin over engineering yapmamasını sağlamak halini alıyor. YAGNI sonuçlarını ve neden bu prensibe uymamız gerektiğini anlatmayacağım ama yukarıdaki söylemi duyduğunuzda tetiklenin…

https://www.monkeyuser.com/2019/yagni/

Peki bu özelliği ekledik. Madagaskar’daki 64k modem ile bağlanacak kullanıcılar Suse Linux 10 ile girmeye kalktıklarında ne olacak?

Fark edeceğiniz üzere söylemi bilerek abarttım ama böyle aşırı uç senaryolarla toplantıyı tıkayan stereotype profili tekrar tekrar görünce not almışım.

Bir sorunumuz var, aklımızda makul bir çözümde var. Bunun için tartışırken bir arkadaş absürt örnekler üzerinden çözümü önemsizleştiriyor. Appeal to Extremes! akademik çalışmalarda daha çok Reductio ad Absurdum diye geçiyor Saçma Olana İndirgeme.

Bir çözüme meydan okumak için özellikle de buna mecbur hissediyorsanız direkt düşeceğiniz safsata. Yöneticilerde daha çok görüyorum ama birde şu köşedeki kapüşonlu kulaklıklı Developer çok yapıyor. Uzun uzun ürünü madagaskar’a açmayacağınızı ve açsak bile 7 kullanıcı olduğunu (Devede Kulak Safsatası) anlatıyoruz da anlatıyoruz. Sağ olsun tartışma kardiyosu yaptırıyor…

Ben çok oyun oynarım ama böyle bir şey görmedim…

Bu söylem ile ilgili bir kaç kelam yazayım dedim ama sonra Altuğ Işığan’ın aşağıdaki konuşmasına denk geldim. Benden daha iyi özetlediği için sizi aşağıdaki video’nun 11:00 dakikasına ışınlıyorum👇

[embed]

**- PM: Bu 100 maddelik ürün özelliğini bir ayda bitirilmesi gerekiyor?

• DEV: Tabi yaparız.**

Optimistik Bias! gibi duruyor ama değil… Belki yeni bir Safsata keşfetmiş olabilirim… Anlatayım…

Yine bir gün Sprint’e alınacak yeni bir iş üzerinde konuşuyoruz, iş direkt BREAKING CHANGE! gel gelelim toplantıda patron ve üst düzey kurmaylar var. PM’ler son teslim tarihini söylüyorlar… Developer’larda tamam diyorlar… ama PM’lerde, Developer’larda yeni işin belirlenen tarihte bitmeyeceğini biliyorlar, bitse bile kararlı olması bir o kadar daha sürecek ama görmezlikten gelinip büyük bir iyimserlik ile el sıkışıyorlar…

Esasen burada gerçek değer ölçümlendiğinde ortaya çıkacak teslim tarihi patronun kabul edeceği bir tarih olmayacağı için bir yok sayma durumu var. Buda Yok Sayma Safsatası (Slothful Induction)’na yakın bir safsata oluşturuyor. Belki Cımbızlama Safsatası’da (Cherry picking) olabilir işin ağırlığını ölçerken istenilen teslim tarihine denk gelecek şekilde ölçümleme yapılıyor da olabilir…

https://www.monkeyuser.com/2022/estimate/

⚠️ Disclaimer! Ben burada danışman olduğumdan bu tiyatroya karışmadım ama efendi gibi durumun tespitini yapıp bildirdim.

**- A: Bizim uygulamaya kimse tablet üzerinden girmiyormuş ki!

• B: Nereden biliyoruz?
• A: Öyle diyorlar…**

Yine bir iş var ve işin isterleri uygulamayı tablet ile açan kullanıcıları kapsamıyor. Developer haklı olarak uygulamayı tablet’e destek verecek şekilde de yapılmasını söylüyor ama kulaktan dolma veya ön kabul olarak uygulamayı tablet ile kullanan olmadığını o nedenle bu desteğe gerek olmadığı kararlaştırılıyor…

Circulus in Demonstrando yani Kısır döngü safsatası. Bilginin kaynağının sonucun kaynağı ile aynı olduğu zaman beliren safsata. Hani bazen oturduğunuzda yanlışlıkla tweet atan bölgemiz kaynaklı safsatalar diyebiliriz.

Skeptik bir beyaz yakalı olarak yukarıdaki diyaloğa şüphe ile yaklaşıp doğruladığımızda tablet ile kullanma oranının %16 olduğunu görüp isteleri genişlettik. 💥

Bu sprint “Son Şans!”. Eğer söz verdiğimiz gibi tamamlayamazsak korkmaya başlayabilirsiniz. Benden söylemesi.

İtiraf edeyim bu safsatayı bizzat şahsım yaptı! 🙄 (winner ceketi lazım)

Direkt Argumentum ad Baculum yani Korkuya başvurma safsatası. Tabi bu korku ve stres yönetimi pek etkili olmadığı gibi daha geriye gittik. Halbuki biraz evrimsel psikolojinin nimetlerinden faydalanmayı umuyordum. Sonuçta beyinlerimiz 21. yüzyılda ama korkularımız hala Homoerectus’dan kalma. Şirket jungel’ında hayatta kalmamızı sağlar diye düşündüm.💩

Aslında daha katılımcı ve şeffaf hareket edip sorumluluklar üzerinden bir planlama yapsaydım korkuya başvurmama gerek kalmayacaktı. Bu da böyle bir anımdır…

Not: Her hangi bir duyguya atıf yapan safsatalar çok. Sıralamak gerekirse (safsata klavuzundan aldım) Tehdit Safsatası, Duygu Sömürüsü, Ön yargılı Dil Safsatası, Mazeret Safsatası.

Ne zaman Salı günleri Deploy çıksak patlıyoruz. Bir daha salı günü deploy çıkmayalım.

Sistemci, DevOps/SRE, insanlarına selam olsun 🙋‍♂️

Post Hoc Ergo Propter Hoc yani Öncesinde Safsatası. Art arda meydana gelen olaylarda mantık aramayıp sadece art arda olduğu için bir nedensellik bulan söylemlere deniyor.

Tabiki olayın salı günü ile alakası yok, sadece error loguna bakıp hatanın bir daha olmamasını sağlayabilirsin veya atıyorum sadece salı günü çalışan schedule bir job CI/CD pipeline’ını yürüten makinede load yaratıp timeout’a düşürüyor olabilir… batıl inançlara koşmak yerine Root Cause’u kovalamak gerekiyor.

Buraya uyan bir hikaye de “Vanilyalı Dondurma Alınca Çalışmayan Araba“ hikayesi. Çok kısalttım 🥂 👇

Yeni bir Pontiac alan müşteri, marketten ne zaman vanilyalı dondurma alsa arabasının çalışmadığını söylüyor (bariz Post Hoc). Şirket ciddi bir şekilde araştırıyor ve vanilyalı dondurmanın marketin girişinde, diğer dondurmaların ise marketin en sonunda olduğunu, sorunun vanilyalı dondurma değil sürücünün vanilyalı dondurma aldığında kısa sürede araca dönmesi olduğunu tespit ediyor. Buna bağlı olarak sorunun motorun tekrar çalışması için geçen zamanda yeterli soğutma yapamaması olduğunu tespit ediyorlar. 💥

PM: Yeni bir özellik eklemek istiyoruz. Bir ödeme sistemi ve twitter ile entegre olacağız. DEV: Kolay… Veritabanına yeni bir field ekleyip hızlıca halledebiliriz. PM: Süper! o_O

Developer’dan bir tahmin istemek..! 🚬

Çoğumuz karşımıza gelen yeni bir geliştirmeyi tahminlerken İyimserlik Ön yargısına (The Optimistic Bias) düşeriz. Hele görev zor ise ve uzun vadeli bir iş ise herhangi bir ön araştırma yapmadan sözler veririz. Eee sonuçta beyin glikoz yakmaktan kaçacak tabi...

https://www.monkeyuser.com/2022/estimate/

Ne zaman bir Developer iyimser yorumlar yapsa tetikleniyorum. Çünkü verilen cevabın İyimserlik Ön yargısı ile verilmediğinden emin olmak isterim. Bu aşamada “En kötü senaryomuz ne olabilir?”, “Bu özellik nereyi bozabilir?”, “Koda bir 5 dakika bakıp öyle bir cevap verelim” gibi temel sorular işin daha zor kısımlarının düşünülmesini sağlayarak bu ön yargıdan kurtarabiliyor.

Not: Mesleğe yeni başlayan Developer kardeşlerim koda bakmayı, yada hemen zaman vermemeyi bir zayıflık veya iş bilmezlik gibi görebiliyorlar. Hiç endişe etmesinler kendinize güvenip doğru zamanı verebilmek için yeterli zaman istemek hiç ayıp değil.

DEV: Bu Engine’deki bazı özellikler isterleri karşılıyor. CTO: Biz daha önce bir projede onu denemiştik, çok başımızı ağrıtmıştı. DEV: Hm! Tamam.

Yukarıdaki diyaloğu çoğumuz yaşamışızdır. Literatüre göre konuşursak Bandwagon Effect denmesinde bir sakınca görmüyorum. Çünkü bir başkası öyle yapıyor diye, sizde yaparsanız bilişsel bir ön yargıya düşmüş olma ihtimaliniz yüksektir.

Bir CTO’nun (individual contributor tipindeki) veya Senior’ün önerdikleri, söyledikleri her zaman doğru değildir. Bu unvanları aldıkları için sizden daha üstün veya iyi değillerdir. Bu arkadaşlar yılların bilgi birikimine sahiptirler, onlarca proje bitirmişler büyük deneyim kazanmışlardır, bu tecrübelere karşın bir sürü ön yargı biriktirmişlerdir. Yılların getirdiği tecrübeler güncel olmayan ön yargılar oluşturabilir, yıllardan beri bazı şeyleri yanlış anlamış olabilirler. O nedenle fikirleri, söylemleri hep challenge etmeniz ön yargılı kararları elmenize yardımcı olur.

[embed]

Son

Yine hunharca yazmışım. Yazı sonunda vereceğim ulvi bir mesajımda yok. Buraya kadar okuduysanız yazılımsal tartışmalardaki safsataları avlayabilecek bir farkındalık sağlayabilmişimdir diye düşünüyorum…

Kaynaklar:

• Safsatalar Ansiklopedisi
• Safsatalar
• https://www.logicallyfallacious.com/
• https://safsatakilavuzu.com/