Ö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.
