Gümüş Kurşun Yok: Yazılım Mühendisliği’nin Asli ve Arızi Özellikleri – I

Gümüş Kurşun Yok: Yazılım Mühendisliği’nin Asli ve Arızi Özellikleri – I

Frederick P. Brooks, Jr.

(Bu yazı, Frederick Brooks’un IEEE Computer dergisinin Nisan 1987 sayısında yayınlanmış olan “No Silver Bullet: Essence and Accidents of Software Engineering“ başlıklı makalesinin ilk kısmının Türkçe çevirisidir. (Bu makaleye buradan ve buradan ulaşabilirsiniz.) Geri kalan kısmı da çevrildikçe burada yayınlanacaktır. Çevirinin PDF dosyasına buradan ya da buradan ulaşabilirsiniz. Çevirideki her türlü hata benimdir. Öneri ve eleştirileriniz için akin@javaturk.org adresinden bana ulaşabilirsiniz.)

Halk kültürümüzün kabuslarında ortaya çıkan canavarların en çok korkutanı kurt adamlardır, çünkü onlar, tanıdık bir sima iken, aniden dehşet verici bir hale dönüşürler. Bu yaratıklar için insanlar da onları yere serecek gümüşten yapılmış kurşun ararlar.

Benzer şekilde yazılım projeleri de, en azından teknik olmayan yöneticiler için aynı karakteri taşırlar;  ilk başta genelde masum görünüşlüdürler ve herşey yolunda gibidir ama tutturulamamış planlara, aşılmış bütçelere ve hatalı ürünlere sahip bir canavara dönüşeme yeteneğine sahiptirler. Bu yüzden yazılım projeleri için de, aynı donanım maliyetlerindeki düşüş hızında bir maliyet düşüşü sağlayacak, gümüş bir kurşun arayan, umutsuz çığlıkları duyar dururuz.

Fakat önümüzdeki 10 yıllık ufka baktığımızda herhangi bir gümüş kurşun görünmemektedir. İster teknolojide isterse yönetim tekniklerinde, üretkenlik, güvenirlik ve basitlikte, 10 katlık bile bir ilerleme sağlayacak bir gelişmenin olması mümkün değildir. Bu makalede, yazılım problemlerinin tabiatını ve teklif edilen kurşunların özelliklerini inceleyerek bunun neden böyle olduğunu göstemeye çalışacağım.

Öte taraftan, şüphecilik karamsarlık değildir. Her ne kadar heyecan verici buluşlar olmasa ve böyle bir şeyin zaten yazılımın doğasıyla çeliştiğini düşünsem de pek çok cesaret verici yenilikler olmaktadır. Bu yenilikleri geliştirmek, yaymak ve kullanmak konusunda dispilinli ve kararlı olmak, 10 katlık bir gelişmeyi sağlamalıdır. Bu konuda müthiş bir yol olmasa da en azından yol vardır.

Hastalığı ortadan kaldırmaya ilk adım, şeytanlarlarla ilgili teorileri bir kenara bırakıp mikrop teorisine dönmektir. Yani ilk adım, umudun başı olarak, sihirli çözümlerden medet ummayı bırakmaktır. Bu konuda söylenebilecek şey, ilerlemenin büyük gayretlerle, ancak adım adım olacağı ve temizliğe, kararlı ve aralıksız bir özenin verilmesinin gerektiğidir. Yazılım mühendisliği dünyasında bugün olan biten de budur.

Zor Olmak Zorunda mı? Asli Zorluklar

Gümüş bir kurşunun olmaması sadece şu an görünürde olan birşey değildir, yazılımın doğası, onun gelecekte de olmasını pek de ihtimal dahilinde kılmamaktadır. Elektroniğin, tranzistörlerin ve büyük çaplı entegre devrelerin bilgisayar donanımı için yaptığını hiçbir buluş yazılımın üretkenliği, güvenirliği ve basitliği için yapmayacaktır. Hiç bir zaman, her iki yılda bir, iki katına çıkan kazanımlar göremeyeceğiz.

Birincisi, şu teslim edilmelidir ki, anormallik yazılımdaki gelişmenin yavaşlığı değil, bilgisayar donanımındaki ilerlemenin çok hızlı oluşundadır. Medeniyetin başlangıcından bu yana hiç bir teknoloji 30 yılda 1 milyon katında bir performans kazanımı elde edemedi. Hiç bir başka teknolojide ileri performans ile düşük maliyet arasında bir seçimde bulunulamaz. Bütün bu kazanımlar, bilgisayar üretiminin montaj endüstrisi olmaktan çıkıp bir süreç endüstrisine dönüşmesinin sonucudur.

İkinci olarak, yazılım teknolojisinde ne hızda bir ilerleme umabileceğimizi görmek için bu teknolojilerin zorluklarını inceleyelim. Aristo’ya uyarak bu zorlukları asli yani yazılımın doğasında var olanlar ile arızi yani bugün yazılımın üretiminde olan ama aslında doğasında olmayanlar olmak üzere ikiye ayırıyorum.

Bir yazılım varlığının aslı, içiçe geçmiş kavramlardan oluşmuş bir yapı olmasıdır: Veri kümeleri, veriler arasındaki ilişkiler, algoritmalar ve fonksiyonların çağrıları. Bu asıl, böyle kavramsal bir yapının, pek çok farklı görünümün altındaki aynı yapı olmasından dolayı, soyuttur. Yine de böyle bir yapı yüksek bir kesinlikte ve zengin bir detaydadır.

İnancım şudur ki yazılım inşa etmenin zor tarafı böyle kavramsal bir yapıyı, tarif etmek, tasarlamak ve test etmektir, onu sunma/oluşturma eforu ya da sunumun/oluşturulanın olması gerekene sadakatini test etmek değildir. Hala pek çok sözdizim hatası yapıyoruz ama emin olun ki onlar pek çok sistemdeki kavramsal hatalarla kıyaslanamayacak kadar basit şeylerdir.

Eğer bu doğruysa, yazılım inşa etmek her zaman zor olacaktır. Tabiati itibariyle de gümüş bir kurşun hiçbir zaman olmayacaktır.

Şimdi de modern yazılım sistemlerinin bu indirgenemez aslının doğal özelliklerine bir bakalım: Karmaşıklık, uyumluluk, değişebilirlik ve görünmezlik.

Karmaşıklık: Yazılım varlıkları, belki de büyüklük itibarıyla diğer insan yapılarından daha karmaşıktırlar çünkü hiçbir parçası birbirinin benzeri değildir (en azından dilin ifadelerinin üzerindeki yapılarda). Zaten benzer olsalar, bu iki benzer parçayı – açık ya da kapalı – tek bir yordam olarak birleştirirdik. Bu açıdan bakıldığında yazılım sistemleri, tekrarlı parçaların bir arada olduğu bilgisayarlar, binalar ya da otomobillerden, temelden ayrılır.

Dijital bilgisayarlar zaten insanların bina ettiği pek çok şeyden daha karmaşıktır: Örneğin çok fazla sayıda durumları vardır. Bu onları anlamayı, anlatmayı ve test etmeyi zaten zor kılar. Yazılım sistemleri ise bilgisayarlardan onlarca kat daha fazla duruma sahiptirler.

Benzer şekilde bir yazılım varlığını büyütmek sadece aynı elemanların daha büyük ebattakilerini tekrarlamak değildir, farklı elemanlarla sayıca büyümek demektir. Pek çok durumda elemanlar birbirleriyle doğrusal olmayan bir şekilde iletişimde bulunurlar ve bütünün karmaşıklığı, doğrusal iletişimde oldukları duruma göre çok daha fazla artar.

Yazılımın karmaşıklığı asli bir özelliktir, arizi değildir. Bu yüzden bir yazılım varlığının karmaşıklığını ortadan kaldıran bir tanım, çoğu zaman onun aslını da ortadan kaldırır. Üç yüz senedir matematik ve fizik bilimleri, modellerden özellikler elde edip, bu özellikleri deneyle test ederek, karmaşık olayların basitleştirilmiş modellerini yapıp ciddi ilerlemeler elde ettiler. Bu paradigma başarılı oldu çünkü modellerde  önem verilmeyen karmaşıklıklar, ilgili olayın asli özelliklerinden değildi. Karmaşıklıklar asli olduğunda başarılı olamazdı.

Yazılım ürünleri geliştirmedeki klasik sorunların pek çoğu, bu asli karmaşıklıktan ve ebata göre doğrusal olmayan büyümeden kaynaklanmaktadır. Karmaşıklıktan takım üyeleri arasındaki iletişimin zorluğu ortaya çıkmaktadır ki bu da ürün hatalarına, aşılmış bütçelere ve gecikmiş planlara yol açmaktadır. Karmaşıklıktan, programın, olması muhtemel bütün durumlarını ortaya koymanın zorluğu, dolayısıyla da bunları daha az seviyede bir anlama ortaya çıkmaktadır ki bu da güvenirliği ortadan kaldırmaktadır. Fonksiyondaki karmaşıklık, fonksiyonu çağırmada zorluğa yol açar ki bu da programları kullanmayı zorlaştırır. Yapıların karmaşıklığından, yan etki oluşturmaksızın programları yeni fonksiyonlara sahip olacak şekilde genişletmenin zorluğu çıkar. Yapıların karmaşıklığından, gözde canlandırılamayan durumlar oluşur ki bunlar da güvenlik açıklarına sebep olur.

Karmaşıklıktan sadece teknik sorunlar çıkmaz, yönetim sorunları da baş gösterir. Karmaşıklık genel bakışı zor hale getirir ki bu durum da kavramsal tutarlılığa engel olur. Karmaşıklık bütün sıkıntılı noktaların bulunup kontrol altına alınmasını zorlaştırır. Karmaşıklık, öğrenme ve anlama konusunda o kadar büyük bir yük oluşturur ki çalışanların işten ayrılmaları bir yıkım haline gelir.

Uyumluluk: Karmaşıklıkla karşılaşma noktasında yazılımcılar yalnız değillerdir. Fizikçiler “temel” parçaçık seviyesindeki son derece karmaşık nesnelerle uğraşırlar. Fakat bir fizikçi, kuarklarda olsun, birleşik alan teorilerinde olsun hepsi için genel geçer prensiplerin bulunacagına dair sağlam bir inançla çalışır. Einstein, doğanın basitleştirilmiş açıklamalarının olması gerektiğini çünkü Tanrı’nın kaprisli ya da rastgele davranmayacağını ileri sürmüştü.

Böyle bir inanç, bir yazılım mühendisini kesinlikle rahatlatmaz. Çünkü üstesinden gelmek zorunda olduğu karmaşıklığın büyük çoğunluğu rastgele karmaşıklıktır ki pek çok insani kurum ya da sistem tarafından mantıksızca oluşturulmuştur ve yazılım mühendisinin arayüzleri bu yapılarla uyum içinde çalışmalıdır. Yazılım mühendisinin geliştirdiği bu arayüzler, arayüzden arayüze, zamandan zamana değişir ama bu durumun sebebi ihtiyaçlar değildir, sadece Tanrı yerine farklı kişiler tarafından tasarlanmış olmalarıdır.

Pek çok durumda yazılım uyumlu olmalıdır çünkü sahneye en son gelen odur. Diğer pek çok durumda da, yazılımın uyum  yeteneğinin yüksek olduğu düşünüldüğü için uyumlu olmak zorundadır. Fakat bütün bu durumlarda karmaşıklığın büyük çoğunluğu, diğer arayüzlere uyumdan kaynaklanmaktadır ki böyle bir karmaşıklık sadece yazılımın tekrardan tasarlanmasıyla basitleştirilemez.

Değişebilirlik: Yazılım varlıkları sürekli olarak değişim baskısıyla karşı karşıyadırlar. Tabi ki binalar, arabalar ve bilgisayarlar da öyledir. Fakat imal edilen şeyler imalattan sonra çok seyrek değişirler; ya daha sonraki modellerle yer değiştirirler, ya da asli özellikleri, aynı temel tasarımla üretilen sonraki kopyalarının içine gömülür. Otomobillerin geri çağrılması son derece nadirdir; piyasaya yayılımış bilgisayarların değişmesi de pek sık olmaz. Bu ikisi durum da, piyasaya yayılımış yazılımların değişmesinden çok daha nadiren olur.

Bu durum bir yönüyle, bir sistemin yazılımının, o sistemin fonksiyonlarını meydana getirmesi ve fonksiyonların da değişimin baskısını en fazla hisseden taraf olmasındadır. Bu durum diğer bir yönüyle de yazılımın daha kolay değiştirilebilmesindendir, çünkü yazılım tamamen zihinseldir ve sınırsızca değiştirilebilir. Gerçekte binalar da değişir, ama değişimin yüksek maliyeti ki herkes tarafından bilinir, değiştireceklerin isteklerini kursaklarında bırakır.

Bütün başarılı yazılımlar değişir. Burada iki süreç vardır. İlki, yazılım ürünü faydalı bulunur, insanlar da onu esas alanının dışındaki ya da kenarındaki durumlar için denerler. Fonksiyonlarını genişletme baskısı daha çok, temel fonksiyonlarını seven ve kullanan kullanıcılardan gelir.

İkincisi, başarılı yazılım, kendisi için yazıldığı makinanın normal hayatından çok daha uzun yaşar. Yeni bilgisayarlar olmasa bile yeni diskler, yeni ekranlar, yeni yazıcılar gelmeye devam eder  ve yazılım, bütün bu yeni olanaklar getiren yeni araçlara uyum sağlamak zorundadır.

Kısaca yazılım ürünü, uygulamalar, kullanıcılar, kurallar ve makina araçlarının kültürel matrisinde gömülü olarak bulunmaktadır. Bunlar sürekli değiştiğinden, onlardaki değişimler ister istemez yazılım ürününü de değişmeye zorlayacaktır.

Görünmezlik: Yazılım görünmez ve gözde canlandırılamaz. Geometrik soyutlamalar güçlü araçlardır. Bir binanın kat planı, hem mimarın hem de müşterinin, mekanı, trafik akışlarını, görünümü değerlendirmelerine yardımcı olur. Çelişkiler ve unutulanlar açığa çıkar. Mekanik parçaların küçültülmüş çizimleri ve moleküllerin şekilleri, her ne kadar soyutlama olsalar da, aynı amaca hizmet eder. Geometrik gerçeklik, geometrik bir soyutlamayla yakalanır.

Yazılımın gerçekliği tabiati itibariyle mekanda gömülü değildir. Dolayısıyla da yazılım, arazilerin haritaları, silikon yongaların diyagramları, bilgisayarların bağlantı şemaları gibi hazır bir geometrik sunuma sahip değildir. Yazılım yapılarının diyagramlarını çizmeye girişir girişmez,  bir değil ama birkaç tane birbiri üzerine getirilmiş genel yönlü grafikler elde ederiz. Birkaç graifk kontrol akışını, data akışını, bağımlılık şablonlarını, zamandaki adımları, isim-uzay ilişkilerini  temsil eder. Bu grafikler düzlemsel bile değildir, çok daha az hiyerarşiktir. Gerçekte böyle bir yapının üzerinde kavramsal bir kontrol oluşturmanın yollarından birisi bir ya da daha fazla grafiğin hiyerarşik olması için bağlantıları kesmeye çalışmaktır. [1]

Yazılım yapılarını kısıtlamak ve basitleştirmek yolundaki ilerlemelere rağmen yazılım yapıları, doğaları itibariyle canlandırılamaz olamaya devam edecektir ve bu durum da zihnin, en güçlü kavramsal araçlarının bir kısımını kullanmasına imkan vermeyecektir.

Böyle bir eksiklik sadece bir zihindeki tasarım sürecini engellemekle kalmaz aynı zamanda birden fazla zihin arasındaki iletişimi de sekteye uğratır.

(Çevirinin devamı gelecektir.)

Toplam görüntülenme sayısı: 3260