Yazılım geliştiricileri gibi mantıklı ve rasyonel insanlar arasında dahi, efsanelerin gücünü hiçbir zaman hafife almamalısınız. Bazı programcılar daha iyi tüm yargılara rağmen seçtikleri şeye inanmaya devam edecek.
Bunun klasik bir örneği, bir yazılım projesini daha fazla geliştirici ekleyerek hızlandırabileceğinize dair olan popüler mantık hatasıdır. Frederick P. Brooks bu teoriyi 1975 yılında, dönüm noktası niteliğindeki kitabı “The Mythical Man-Month”da çürüttü.
Brooks’un temel önermesi, ilerlemiş bir projeye daha fazla geliştirici eklemenin işi hızlandırmayacağıydı. Tam aksine daha da yavaşlatacaklar. İddia ettiği bu şey doğru idiyse, yazılım projeleri yönetimiyle ilgili diğer fikirlerin çoğu aslında hatalıydı.
Brooks’un örneklerinden bazıları bugün kullanılmıyor gözüküyor ama onun iddiası halen sapasağlam duruyor. O iddiasını ikna edici bir biçimde yapıyor. Ne yazık ki, az sayıda geliştirici bunu kalben benimsemiş gözüküyor. 35 yılı aşan bir sürenin ardından, programcılar arasında efsanevi düşünce yapısı halen yer buluyor. Aynı hataları yapmayı sürdürüyoruz.
Asıl utanılacak şey şu ki, birçok durumda büyüklerimiz yıllar öncesinde hataları işaret etti; tabi biz dikkat edersek. Günümüzdeki programlama efsanelerinden birkaçını burada paylaşıyoruz. Bunları birçoğu esasında eski hataların tekrarlarından başkası değil.
Programlama Efsanesi No. 1: Denizaşırıya yönelmek yazılımları daha hızlı ve daha ucuza üretir
Bu günlerde hiç kimse önemli bir yazılım projesini, bir denizaşırı (offshore) stratejisi olmaksızın başlatmayı düşünmüyor. Bunu tüm büyük yazılım firmaları yapıyor. Silikon Vadisi sermayedarları bu konuda ısrarlı. Bu gayet açık; ya da servis sağlayıcıları sizi buna inandırabilir.
Mantıklı gözüküyor. Kod geliştirme işini gelişmekte olan ekonomilere aktararak, yazılım firmaları daha az şey için daha fazla programcıyı çalıştırabilir. Bu da projelerini daha kısa zamanda daha küçük bütçelerle bitirebilmeleri anlamına geliyor.
Fakat durun! Bu Mythical Man-Month’daki mantık hatasının klasik bir örneği. Biz biliyoruz ki bir yazılım projesinde daha fazla kişinin olması projenin daha hızlı tamamlanması veya maliyetinin düşük olmasına bir yardımı yok; tam tersine. Denizaşırıya yönelmek işleri daha da kötüleştiriyor.
Brooks’a göre, “Bir yazılım projesine daha fazla insan eklemek toplam zahmeti üç şekilde arttırıyor: işin paylaştırılması, yeni insanların eğitilmesi ve artan haberleşmeyle.”
Paylaştırma ve eğitim için, dış kaynağa verilen projelerle evde yapılanların aynı derecede çaba gerektirdiğini varsayalım (tehlikeli bir varsayım). Dışkaynak için gereksinim duyulan iletişim zahmeti çok daha fazla. Lisan, kültür ve zaman dilimi farklılıkları ekstra sıkıntı. Daha da kötüsü, denizaşırı geliştirme ekipleri sıklıkla daha yüksek iş hacmine meyilli olduğundan zaman içinde iletişim nadiren iyileşiyor.
Denizaşırı korku hikâyelerinin sayısı hiç de az değil. Verebileceklerinden daha fazlasını vaat eden dış kaynakçılar yinelenen bir konu. Terminler uzadığında ve müşteriler işi kendi bünyelerinde bitirmeye zorlandıklarında, varsayılan olası maliyet tasarrufları ortadan kayboluyor.
Denizaşırıya yönelmek büyülü bir şey değil. Esasında, bunu doğru biçimde yapmak güç. Eğer bir dış kaynak düşük bir bedelle tüm problemlerinizi çözmeyi vaat ediyorsa, sağlıklı şüpheciliğinizi koruyun. Bu cazip teklif bütçenizden daha fazlasına mal olabilir.
Programlama Efsanesi No. 2: İyi kodcular uzun saatler çalışır
Hepimiz klişeyi biliriz. Popüler kültürde, programcılar gece yarılarına kadar oturup kod yazar. Pizza kutuları ve enerji içecekleri masalarının üstünü doldurur. Hafta sonu çalışırlar; esasında nadiren eve giderler.
Bu karikatürde bir miktar gerçek bulunuyor. Yakın zamanda gerçekleştirilen Amerikan Ulusal Sağlık Anketi verilerine göre, en çok uyku eksikliği yaşayan meslek gruplarından beşinci sıradaki programcılık. Özellikle video oyun endüstrisinde uzun çalışma saatleri yaygın; terminler yaklaştığında geliştiricilerin “dönüm noktalarına” karşı dayanıklı olması gerekiyor.
Ancak böyle olması gerekmiyor. Uzun çalışma saatlerinin verimliliği arttırmadığını gösteren yeteri kadar delil mevcut. Aslında, dönüm noktaları yardımcı olduğundan fazla acı verebilir.
Ekstra çaba sarf etmenin kötü bir tarafı yok. Fred Brooks, “gerektiğinden hızı koşmayı, gerektiğinden hızlı hareket etmeyi, ihtiyaçtan fazlasını çabalamayı,” övüyor. Ancak o aynı zamanda ilerlemedeki kafa karıştırıcı çabaya karşı uyarıyor.
Ekseriya, yazılım projeleri kronik takvim sarkmaları yüzünden gecikiyor, felaketler yüzünden değil, diyor Brooks. Belki ilk tahminler gerçekçi değildi. Belki projenin önemli aşamaları bulanık ve zayıf bir biçimde tanımlanmıştı. Veya belki de müşteri yeni gereksinim ya da yeni özellikler eklediğinde akışı değiştirdiler.
Her iki şekilde de sonuç değişmiyor. Küçük gecikmeler biriktiğinde, programcılar kriz moduna sürükleniyor ama onlar artık yakalanamayacak hedefleri tutturmak için ekstra gayret gösteriyor. Proje takvimi uzadıkça, moraller de bozuluyor.
Bazı programcılar düşme noktasına kadar çalışabilirler belki ama çoğunun diğer herkes gibi ailesi, arkadaşları ve kişisel yaşamları var. Herkes gibi onlar da ofisten ayrılmaktan memnun olacaklardır. Dolayısıyla kodcuları uzun saatler çalıştırmak yerine, bunu neden yapmak zorunda olduklarını bulmaya konsantre olun; ve tabi nasıl durdurabileceğinize. Bunu ücretsiz pizzadan daha çok seveceklerdir, hiç şüphesiz.
Programlama Efsanesi No. 3: Harika geliştiriciler 10 kat daha verimlidir
İyi programcıları bulmak zor ama harika programcılar efsanevi kişiler; en azından şehir efsanesi.
Eğer hikâyelere inanıyorsanız, oralarda bir yerlerde çok yetenekli hacker’lar var. Onlar “geliştiricilerin 10 katı gücünde” olarak anılıyor çünkü iddialara göre onlar sizin ortalama programcınızdan çok daha üretken.
Doğal olarak işçi bulma firmaları ve personel müdürleri kod dünyasının masalsı yarı tanrılarını bulmak için her şeyi yapabilirdi. Bununla birlikte çoğunlukla onlar Koca Ayak kadar nadir görünen varlıklar. Esasında, muhtemelen böyle birileri yok.
Ne yazık ki bu efsanenin ayıbı Fred Brooks’un kendisine düşüyor. Hemen hemen; ondan aktarılanlar hatalı. Brooks’ın gerçekte söylediği şey şu ki en iyi programcılar en kötü programcılardan 10 kat daha verimliydi, ortalama olanlarından değil.
Geliştiricilerin çoğu ortalarda bir yere denk geliyor. Eğer ekibiniz içerisinde gerçekten 10 kat verimli birisini görürseniz, geçmişte işe alım yaparken muhtemelen çok kötü tercihlerde bulunmuşsunuzdur (iyi olanlarıyla birlikte).
Brooks’un açıkladığı çalışma 1966’dan. Modern yazılım yöneticileri geliştirici verimlilik ölçümleri içerisine inançtan daha fazlasını yerleştirmeyi iyi bilir; çünkü onlar nadiren güvenilirdir. Öncelikle kod üretimi hikâyenin tamamını anlatmaz. Brooks’un kendisi en iyi programcıların dahi bir iş haftasının sadece yarısı kadarında kod ve debug yaptığını itiraf ediyor.
Bu demek değil ki bulabileceğiniz en iyi geliştiricileri işe almaya çalışmayın. Fakat süper inansı kodcuların gelmesini beklemek kötü bir işçi bulma stratejisi. On kat güçlü geliştiricilere takılmak yerine, on kat güçlü ekipler oluşturmaya odaklanın. Seçim yapabileceğiniz çok daha büyük bir yetenek havuzuna sahip olacaksınız. Bu da boşlukları dolduracağınız ve projenizin daha kısa zamanda tamamlanması anlamına geliyor.
Programlama Efsanesi No. 4: İleri teknoloji araçlar daha iyi sonuçlar üretir
Yazılım bir teknoloji işi olduğundan teknolojinin onun tüm problemlerini çözebileceğine inanmak çekici. Yeni bir programlama dili, iskeleti veya geliştirme ortamı maliyetleri düşürse, pazara çıkma süresini azaltsa ve kod kalitesini geliştirse, hem de tek seferde, hoş olmaz mıydı? Nefesinizi tutmayın.
Yeteri kadar işletme rakiplerine karşı üstünlük sağlamak için gelenek dışı dilleri kullanmayı denedi. Bir sosyal ağ olan Yammer ilk sürümünü Scala’da yazdı. Twitter yaşamına bir Ruby on Rails uygulaması olarak başladı. Reddit ve Yahoo Store’un her ikisi de Lisp’le geliştirilmişti.
Ne yazık ki bu tür deneylerin çoğu uzun yaşamadı. Scala gereksinimlerini karşılamadığında Yammer Java’ya geçti. Twitter ise Java’da karar kılmadan önce Ruby’den Scala’ya geçti. Riddit kodunu Python’da yazdı. Yahoo Store C++ ve Perl’e yöneldi.
Bu demek değil ki seçtiğiniz araç uygun değil. Ölçeklenebilirliğin ham performans kadar önemli olduğu sunucu ortamlarında platformlar özellikle önemli. Fakat, sözü geçen firmalarının tümünün moda dillerden anaakım olanlarına geçtiğini söylüyor.
Fred Brooks bunu on yıllar önce öngördü. “No Silver Bullet,” adlı makalesinde, “Hem teknoloji hem de yönetim tekniğinde, verimlilik, güvenilirlik, basitlik konusunda büyük boyutlu bir gelişme vaat eden, tek bir geliştirme yok.” diye yazıyor.
Örneğin, Amerikan Savunma Bakanlığı 1970 yılında Ada dilini geliştirdiğinde, onun hedefi programlamada devrim yapmaktı; öyle bir şansı olmadı. “Ada, nihayetinde bir diğer üst seviye dil,” diye yazdı Brooks 1986’da. Bugün olsa olsa niş bir araç.
Elbette bu hiç kimseyi yeni programlama dillerini keşfetmekten alıkoymayacak ve bu iyi bir şey. Sadece kendinizi kandırmayın. Kaliteli bir yazılım inşa ederken hedefiniz her zaman için çeviklik, esneklik ve marifettir. Ancak olgunlaşmış araçlar faydasız değil.
Programlama Efsanesi No. 5: Kodun üzerinde ne kadar çok göz olursa, o kadar az hata olur
Açık kaynak geliştiricilerinin bir düsturu var: “Yeterince göz varsa, tüm kusurlar yüzeyseldir.” Bu bazen Linus kanunu olarak da anılır ama ilk kullanan açık kaynak hareketinin kurucu düşünürlerinden biri olan Eric S. Raymond’dur.
“Göz” elbette kaynak koduna bakan geliştiricileri işaret ediyor. “Yüzeysel” ifadesi de hataların bulunmasının ve çözümünün kolay olduğu anlamına geliyor. Bundaki düşünce şu; açık kaynak özel yazılımlara karşı doğal bir avantaja sahip çünkü herhangi bir kişi kodu inceleyebilir, kusurları tespit edebilir ve gerektiğinde bunları düzeltebilir.
Ne yazık ki bu bir hayal. Çünkü hataların bulunabilir olması bulunacak olması anlamına gelmiyor. Günümüzde çoğu açık kaynak projesi destek verenlerden çok daha fazla kullanıcıya sahip. Birçok kullanıcı kaynak kodu incelemiyor bile. Bu da demek oluyor ki çoğu proje için anılan göz sayısı abartılıyor.
Daha da önemlisi, hataları bulmak onları çözmekle yanı şey değil. Herkes hata bulabilir; onların çözümü farklı bir mesele. Bir hatayı tespit eden herhangi bir çift gözün onu düzeltme yeteneğine sahip olduğunu varsaysak bile, Brooks’un Mythical Man-Month probleminin farklı bir varyasyonuyla karşılaşıyoruz.
2009 yılında gerçekleştirilen bir çalışma, çok sayıda farklı geliştiriciler tarafından yamalanan kod dosyalarının, küçük, konsantre ekipler tarafından yamalananlara göre daha fazla hata içerdiğini ortaya çıkardı. Bu “odaklanmamış katkılar” üzerinde çalışarak, araştırmacılar Linus kanuna karşı bir anlam çıkardı: “Çok fazla aşçı çorbayı bozar.”
Brooks bu fenomenin fazlasıyla farkındaydı. “Program bakımındaki temel problem, bir kusurun düzeltilmesi bir başkasını ortaya çıkarma şansını (yüzde 20 ila 50 oranında) yükseltir,” diye yazmıştı. Bu yeni kusurları tespit etmek için regresyon testlerini çalıştırmak, tüm geliştirme süreci üzerinde önemli bir baskı olabilir. Çözümlerde ne kadar odaklanılmamışsa, durum o kadar kötüleşir. Bu gözlerinizi yuvalarından çıkarmaya yeter.
Programlama Efsanesi No. 6: Büyük programcılar en hızlı kodu yazar
Profesyonel bir yarış takımının işi, diğer herkesten önce aracı bitiş çizgisine getirmektir. Makinenin kendisi önemlidir ancak tüm farkı yaratan şey sürücünün ve teknisyenin zorlu, itinalı gayretidir. Aynı şeyi bilgisayar kodu için de düşünebilirsiniz. Ne yazık ki, el ile optimizasyon algoritmalarınızdan en yüksek performansı elde etmenin en iyi yolu değildir. Esasında, günümüzde bu nadiren geçerli.
Problemlerden birisi, programcıların kendi kodlarının gerçekte nasıl çalıştığı hakkındaki varsayımlarının genellikle yanlış olmasıdır. Üst seviye diller tasarımları itibariyle programcılarla altta yatan donanım arasında siper oluşturur. Sonuç olarak, kod yazarları faydasız, hatta zararlı olabilecek yollardan optimizasyonu denemeye kalkabilir.
İki değişkenin değerlerini değiş tokuş yapmak için bitwise operatörlerini kullanan XOR swap algoritmasını ele alın. Bir zamanlar bu verimli bir yöntemdi. Fakat modern CPU’lar pipeline’ları kullanarak birden fazla komutu paralel olarak çalıştırarak performansı arttırıyor. Bu XOR swap’te işe yaramıyor. Bugün XOR swap’i kullanarak kodunuzu optimize etmeye kalktıysanız, daha yavaş çalışabilir çünkü yeni CPU’lar farklı tekniklerden yararlanıyor.
Çok çekirdekli CPU’lar durumu daha da karmaşıklaştırıyor. Onların avantajından yararlanmak için, çok izlekli (multithreaded) kodlar yazmanız gerekiyor. Ne yazık ki paralel işlemi doğru yapmak güç. Bir izleği hızlandıran optimizasyonlar, diğerlerini kazara yavaşlatabilir. İzlek sayısı arttıkça programın optimizasyonu zorlaşıyor. Bir yordamın optimize edilebilir olması edilecek olması anlamına gelmiyor. Çoğu program zamanın yüzde 90’ında kodlarının sadece yüzde 10’luk bölümünde çalışıyor.
Birçok durumda en iyisi kendi araçlarınıza güvenmenizdir. 1975’te Fred Brooks bazı derleyicilerin, elle yazılan kodların yenemediği sonuçlar ürettiğini gözlemledi. Bu günümüz için de doğru. Bu yüzden gerekli olmayan manüel optimizasyonlarla zaman harcamayın. Kodunuzun verimliliğini geliştirme yarışında, geliştirici verimliliğin de o kadar önemli olduğunu hatırlayın.
Programlama Efsanesi No. 7: İyi kod ya “basit”tir ya da “mükemmel”
Çoğu mühendis gibi programcılar problemler için “mükemmel” veya “basit” çözümler bulmak hakkında konuşur. Tehlike, bunun yazılım kodunu değerlendirmede zayıf bir yola dönüşmesidir.
Bu tanımlar tam olarak ne anlama geliyor? Basit bir çözüm mükemmel olanın aynısı mı? Mükemmel bir çözüm bilgiişlemsel olarak verimli olan mı yoksa en az kod kullanan mı?
Her ikisini ararken çok fazla zaman harcayın ve iyi programlamanın felaketiyle karşılaşma riskini alın: zeki çözüm. O kadar zekicedir ki takımdaki diğer üyeler kodun nasıl çalıştığını anlayana dek oturup bulmaca çözmek zorunda kalır. Anladıktan sonra bile ona dokunmaya cesaret edemezler; parçalara ayrılır korkusundan.
Çoğu durumda, çözüm kendi iyiliği için çok zekicedir. 1974’deki kitapları “The Elements of Programming Style,”da Brian Kernighan ve P.J. Plauger, “Herkes debug işinin programı yazmaktan iki kat daha güç olduğunu bilir. Peki bunu yazacak kadar zekiyseniz, onu nasıl debug edeceksiniz?” diye yazmışlardı. Bu yüzden, başkası bunu nasıl yürütecek?
Yani, bir programlama problemine en “mükemmel” çözümü bulmaya konsantre olmak, diğer bir tür prematüre optimizasyondur. Problemi çözmek birincil hedef olmalıdır.
Bu yüzden okunması, yönetimi ve debug’ı kolay olan kodlar yazmak yerine kendilerini onurlandırmayla ilgileniyor gözüken programcılardan sakının. İyi kod o kadar basit olmayabilir. İyi kod mükemmel olmayabilir. En iyi kod çalışır, gayet güzel çalışır ve hatasızdır. Neden daha fazlası istensin?