Daily Archives: 27 Kasım 2009

No Silver Bullet ya da Sihirli Değnek Yok

Yazılım Mühendisliği , , , , , ,

Frederick Brooks, 1987 Nisan ayında IEEE’nin Computer dergisinde “No Silver Bullet: Essence and Accidents of Software Engineering” başlıklı bir makale yayınladı. (Makalenin aslını burada, Türkçe çevirisini burada bulabilirsiniz.) Makale temel olarak yazılım mühendisliğinin doğasını inceliyor ve bu alanda o ana kadar olan gelişmeleri masaya yatırıyor. İlk yayınlandığında yazılım dünyasının klasikleri arasına giren, yazılımın neliği hakkında düşünce dünyamızı aydınlatan bu makale, lehinde ya da alehinde pek çok düşüncenin ortaya çıkmasını sağlamıştır. Makale, daha sonra yazarın, yine klasiklerden olmuş “The Mythical Man Month” isimli  kitabında da yer aldı. Chapel Hill’deki University of North Carolina’da Bilgisayar Bilimleri bölümünü kurup, 1964 ve 84 yılları arasında da bölümün başkanlığını yapan Prof. Brooks aynı zamanda IBM System/360’ın da babası olarak bilinmektedir.

Brooks makalesinde, Aristo’nun ayrımından yola çıkarak yazılımın asli ve arızi zorlukları olduğunu ifade ediyor. Brooks’a göre yazılımın asli zorlukları, yazılımın kavramsal olan doğasının bir sonucudurlar. Yazılımın kavramsal doğasının en belirleyici özellikleri ise karmaşıklık, uyumluluk, değişebilirlik ve görünmezlik olarak sıralanıyor. Yani yazılımlar öncelikle kavramsal yapılardır ve her zaman karmaşıktır, devamlı ortama uyum sağlaması beklenir, daima değişir ve hiç bir zaman görünür değildir. Brooks’a göre yazılım var oldukça yazılımcılar, yazılım geliştirmenin kavramsal taraflarını içeren ve geliştirilecek yazılımı tanımlama, tasarlama ve test etme gibi çalışmalarda bu dört özellikten kaynaklanan zorluklarla bir şekilde uğraşacaklardır. Makalede yazılım süreçlerinde olan ve yazılımı kodlamak ya da olması gerekene uygunluğunu test etmek gibi diğer çalışmaların ise arızi yani ikincil olduğu, dolayısıyla bu çalışmalardaki zorlukların, yazılım için olmazsa olmaz zorluklar olmadığı vurgulanıyor. Makalenin temel olarak savunduğu tez şu üç cümlede özetlenebilir: Bu dört özellik, yazılımın tabiatını oluşturdukları için yazılım geliştiriciler her zaman ve muhakkak bu dört özellikten kaynaklanan zorluklarla baş etmek zorundadırlar. Teknolojide ya da yönetimde bulunacak hiçbir yenilik, yazılım mühendisliğini daha üretken, güvenilir ve basit yapma adına önümüzdeki 10 senede 10 katlık bir kazanç sağlamaycaktır. Ayrıca yazılım dünyasında kurtarıcı olarak sunulan yeniliklerin hiçbirisi bu asli özellikleri ortadan kaldırmaz; olsa olsa arızi özelliklerini iyileştirir. İnsanoğlunun yazılım tecrübesi arttıkça, yazılım üretim hızında, yazılımın kalitesinde vs. tabi ki kazanımlar olacaktır. Fakat bu kazanımların, bilgisayar donanım endüstrisinde olduğu hızda olması hayal bile edilmemelidir. Bu yüzden Amerikan folklorunda var olan kurt adamları yere seren gümüşten kurşunu yazılım dünyasında aramak beyhudedir. Kurt adamları öldüren tek şey olan “gümüş kurşun”un bizim kültürümüzde tam bir karşılığı olmasa bile, “sihirli değnek” kavramı kastedilen manayı ifade etmektedir. Yani yazılım dünyasında ortaya çıkan yeni diller, yeni programlama yaklaşımları, yeni araçlar vs. hiç bir zaman sihirli bir değnek olmayacaklardır. Bu yenilikler yazılımı çok daha kolay hale getiremeyecekler, yazılımın devamlı değişken olan tabiatını daha durağan yapamayacaklar, yazılımın uyum sorununu ortadan kaldıramayacaklar ya da yazılımı görünür hale getiremeyeceklerdir.

Makalenin önemi, yazılım geliştirme kavramıyla alakalı ciddi soyutlamalar yapması ve bu soyutlamaları analitik olarak değerlendirmesindedir. Makale, kendisini okuyan her yazılımcının dünyasında yeni ufuklar açmıştır ve açmaya da devam etmektedir. Bu yüzden makalenin savunduğu iddialar, makalenin yayımlanmasından sonra “işte benim gümüş kurşunum bu” gibisinden yazılardan, yazılım konferanslarında konu ile ilgili panellere kadar pek çok şekilde tartışılmıştır. Yazılımcı olmak isteyen ya da olan herkesin bu makaleyi okuması ve üzerine kafa patlatması son derece elzemdir.

Yazarın makalesinde ileri sürdüğü iddiaları ispatlamak için vermiş olduğu örneklerin, o yılların tecrübe ve anlayışına uygun olduğu açıkça görülebilir. Fakat bu makalede ileri sürülen iddiaların artık geçersiz olduğu anlamına gelmez. Aksine makalenin yazılmış olduğu zamandan bugüne geçen 20 yılı aşkın sürede yazılım dünyasında yaşananlar, makalede ileri sürülen iddaları kuvvetlendirici pek çok yeni delil sağlamıştır. Şimdi bu dört asli özelliğe bir kere daha göz atalım.

Karmaşıklık: Yazılım doğası gereği karmaşıktır çünkü bir yazılımda ifade edilen durumlar diğer mühendislik uygulamalarına hatta bilgisayarlara göre bile sayıca çok daha fazladır. Yazılımlar diğer pek çok diğer mühendislik uygulamalarında olduğu gibi aynı parçaların farklı şekillerde bir araya getirilmesiyle oluşmazlar, dolayısıyla yazılımın büyümesi yeni parçalar demektir, aynı parçaların daha büyük ebatta olanlarının kullanılması değildir. Bir yazılım sistemini meydana getiren parçalar birbirleriyle doğrusal bir şekilde haberleşmezler, aralarındaki iletişim daha çok doğrusal olmayan bir şekilde gerçekleşir. Bu tür karmaşıklıklar yazılımı anlamayı, anlatmayı, geliştirmeyi ve test etmeyi zorlaştırır. Yazılımın doğasının bir parçası olan karmaşıklık yazılımı sadece teknik olarak zor kılmaz, yazılım projelerini yönetmeyi de zorlaştırır.

Yazılımlar, aradan geçen 20 küsür senede daha da karmaşık hale geldi. Bu durum, sadece yazılımların daha fazla module, satıra vs. sahip olması yani ebat açısından daha büyük hale gelmesiyle açıklanamaz. Aradan geçen sürede yazılımlar hayatın içine çok daha fazla girdi. Yazılımlar artık algoritmik olmaktan çok süreç odaklı. Yazılımlar günümüzde ezici bir çoğunlukla bir grup iş yapış şeklini ya da süreci hayata geçiriyor. İş süreçlerindeki akışların karmaşıklığı, iş kurallarının sayısı ve detayı, iş süreçlerine dahil olan kullanıcıların sayısı, sürece katılım şekli ve süreçle alakalı yetkileri, iş süreçlerini yerine getiren yazılımların karmaşıklığını ciddi bir şekilde arttırıyor. Yazılımların iş ve gündelik hayatın bu kadar içine girmesi, geçmişe göre daha sıradan kişilerin bu yazılımların kullanıcıları olması anlamına geliyor. Bu da yazlımın veriyi kullanıcıdan almasında daha dikkatli olmasını gerekli kılıyor; yazılımların kullanılabilirliği ciddi bir problem olabiliyor.

Topolojik açıdan zamanımızda üretilen yazılımlar, bundan 20 küsur öncesine göre çok daha dağınık (distributed). Yazılımların büyük çoğunluğu web üzerinden hizmet veriyor, ciddi bir kısmı web servislerini kullanıyor. Global bir köye dönüşen dünyamızda kıtalar arası işbirlikleri, dağınık entegrasyon projelerinin sayısını bir hayli arttırmış görünüyor. Dolayısıyla artık yazılımlar ağlarda çalışacak şekilde tasarlanıyor. Bu durum da haliyle karmaşıklığı arttırıyor.

Nesne merkezli dillerin gelişmesi ve yaygınlık kazanamasının, yazılımın karmaşıklığını yönetmede bize güç sağladığı açıktır. Nesne merkezli diller, gerçekliği soyutlayıp yazılım yapılarına aktarmada, nesne merkezli olmayanlara göre çok daha güçlüdürler. Nesne merkezli dillerin 1960’lı 70’li yıllarda Simula 67 ve Smalltalk ile gündeme gelmesine rağmen bu kadar yaygın kullanım alanı bulması 90’lı yılların ortasından ititbaren Java ile mümkün olmuştur. Bunun kanımca iki sebebi vardır: İlki, “Java Nedir?” başlıklı yazıda da kısaca açıklandığı gibi, zamanın yaygın olan nesne merkezli dili C++’ın çok aşağı seviyeli ve güvenirliği düşük bir dil olması yanında nesne yapılarını uygulamada yeterince açık olmayıp, ciddi bir nesne kültürü oluşturmaktan uzak kalmasıdır. İkincisi de ilkiyle ilgili olmakla birlikte, daha çok geliştirilen yazılımların hayatımıza ve iş dünyamıza ciddi bir şekilde girmiş olmasıyla alakalıdır.  Yazılımların gündelik hayatın içine girmesi, gerçekliği ifade etmede nesne yapılarını rahat bir şekilde uygulayabilmemizi gerekli kıldı. Bu durum da Java’nın, C++’ın yerini alma sürecini çok kısalttı.   Bu noktada, Java gibi hem nesne merkezli hem de platformdan bağımsız bir dilin özellikle sunucu ve mobil tarafta çok yaygın bir kullanım alanı kazanması ve platformlardaki farklılıkları soyutlaması, karmaşıklığı kesinlikle azaltmıştır. Öte taraftan yine Java ile açık kaynak kod felsefesini destekleyen irili ufaklı, Ruby ve benzeri pek çok dilde geliştirilen bileşen (component) ve çerçeve (framework) yapıları, yazılımcıların üretim hızlarını ve üretilen yazılmın kalitesini arttırmıştır.

Tasarım şablonlarının (design patterns) nesne merkezli dillerle birlikte yaygın bir şekilde kullanılır olması, mimari tabanlı yazılım tasarlama yaklaşımının yaygınlık kazanması, tasarım şablonlarını ve farklı mimari modelleri kullananan bileşen ve çerçevelerin pek çok yazılım projesinde değişik yoğunluklarda kullanılması, anlamayı kolaylaştırarak karmaşıklığı azaltmıştır. Bu yapıların yaygın bir şekilde kullanılması yazılımcılar arasında bir dil oluşturmuş ve iletişimi, tarif etmeyi ve aktarmayı daha kolay hale getirmiştir.

Yazılım elemanlarını modelleme notasyonu olarak standart hale gelmiş olan UML’in, yazılımı, projenin değişik safhalarında modellemek amaçlı kullanılır olması, karmaşıklığı yönetmede kolaylıklar sağlamıştır. Çünkü UML, yazılımın farklı safhalarında ortaya çıkan farklı kavramları, çok güçlü grafiksel soyutlamaları yardımıyla algılamamıza katkıda bulunmuş, bu yapıların iletişimini kolaylaştırmış, hatta çok teknik olmayan kişilerle bile bir iletişim köprüsü kurulmasına yardım etmiştir.

Yazılım projesininin başından sonuna kadar yönetilmesinde bir çerçeve çizen XP ya da UP gibi metodolojiler, projede neyin en zaman ve kim tarafından yapılacağını ve nelerin üretecileğini öğreterek karmaşıklığı azaltmaya yardım etmişlerdir. Yazlım geliştirmenin belli safhalarına hitap eden, örneğin kullanım şekli tabanlı ihtiyaç analizi (use case-based requirement analysis), cephe merkezli programlama (aspect-oriented programmming) ya da test güdümlü programlama (test-driven programming) gibi tekniklerin, ilgili safhalarda kolaylık sağladığı açıktır.

Öte taraftan bütün bu kavram ve tekniklerin, karmaşıklığın bir kısımını soyutlayıp, üzerlerini örtüp bizden uzak tutarken, hiçbir maliyetlerinin olmadığı düşünmek çok safça olur. Bu yapılar da yeterince karmaşıktır ve seçim, öğrenilme ve uygulanma konusunda fazladan yük gewtirdikleri de kesindir. Öncelikle hangi bileşene, hangi çerçeveye ya da hangi mimari ve metodolojik yaklaşıma ihtiyacınız olduğunu belirlemek başlı başına bir karmaşıklıktır. Bu konuda yazılımcıların yaklaşımı, genel olarak “daha önce başarıyla uyguladığından vazgeçme”dir. Bu konuda yapılacak yanlış bir seçimin projeyi doğrudan başarısızlığa götürebileceği de aşikardır. Benzer zorluk öğrenme konusunda da vardır. İşe yeni aldığınız yazılım mühendisiniz, kullandığınız tasarım şablonlarını, bileşen ve çerçeve yapılarını, uyguladığınız mimari ve metodolojik yaklaşımları biliyorsa, çok hızlı bir şekilde projenize girebilir demektir. Aksi taktirde ya bu yapıları öğrenmek için ona zaman tanıyacaksınız ya da hızlıca projeye dahil olup, bütün bunları yolda öğrenecek. Bu gibi yapıları iyi bir şekilde öğrenmenin, en az bir ciddi projede baştan sona kullanmakla mümkün olabileceği düşünülürse, karmaşıklığı bu yapılarla alt etmenin ciddi bir maliyeti olduğu ve bu maliyetin önemli bir kısmının da karmaşıklıktan oluştuğu açıktır.

Uyumluluk: Aradan geçen sürenin, yazılımların uyumlulukları konusunda yazılımcılara daha fazla sorumluluk yüklediği açıktır. Öncelikle yazılımların hayatımıza daha fazla girmesi, tipik bir projede var olan kullanıcı tipi ve entegrasyon ucu sayısını arttırdı, eskiden elle yapılan veri alışverişlerinin gerçek zamanlı (real-time) olmasını gerekli kıldı. Yazılımlar artık daha fazla çevre birimi ya da iç ve dış sistemle haberleşiyorlar. Ağ yapılarının gelişmesi, gerek Internet gerek ise intranette çalışan uygulamaların, birbirlerinden daha çok haberdar olmalarını gerektiriyor. Eskiden elle ya da email veya FTP gibi protokollarla yapılan veri aktarımları artık gerçek zamanlı yapılıyor. Bütün bunlar yazılımların kendisine uyum sağlayacağı daha çok ortamla ilişkide olması anlamına geliyor ki bu da yazılımların uyumluluk sorumluluklarını arttırıyor.

XML ve web servisleri gibi standartların geliştirilmiş olması, yazılımların kendileriyle haberleştikleri çevre birimlerinin eskiye göre nispeten daha standart arayüzlere sahip olmaları, uyumluluk konusunda yazılımcılara elbette yardım etmektedir. Fakat tüm bunlar günümüz yazılımlarının daha uyumlu olması gerektiği gerçeğini ortadan kaldırmamaktadırlar.

Değişebilirlik: Hayatın ve iş yaşamının hızlanması, değişimi, başarının ya da başarısızlığın en önemli faktörü haline getirdi. Değişimi yönetebilenler ayakta kalırlarken yönetemeyenlerin akibetleri, ne kadar köklü olurlarsa olsunlar, hep aynı son olmakta. Bu durum, hayatımıza ve iş dünyamıza olabildiğince giren yazılım sistemlerinin de zamanın bu hızlı akışına ve değişime ayak uydurmalarını gerektirmektedir. Bilişim teknolojileri, artık iş yapmanın bir olmazsa olmazı olduğuna göre, yazılımların üzerindeki değişim baskısı, eskisine göre çok daha fazla artmış durumdadır.

Nesne merkezli diller, kodlamadan çok bir düşünme ya da modelleme aracı olarak kullanıldıklarında, yazılımda değişimi öngörülen kısımları, değişmesi pek de muhtemel olmayan diğer kısımlardan yalıtacak yapılar sunmaktadır. Hangi durumlarda nasıl yalıtım sağlanacağı temel olarak tasarım şablonlarının konusudur ve “dörtlü çete”nin (Gang of Four, Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides) Design Patterns isimli kitabında ayrıntılı bir şekilde açılanmıştır. Java gibi nesne merkezli diller ile tasarım şablonlarının ve mimari tabanlı yazılım tasarım yaklaşımının yaygınlaşması, bileşen ve çerçeve kullanımının artması, yazılımcıların değişimi yönetebilmelerine yardımcı olmaktadır.

Groovy ve Ruby gibi dinamik tipli dillerin, Java gibi statik tipli dillerin kısıtlarını ortadan kaldırmak üzere geliştirilmesi ve yaygın kullanım alanı bulması, yazılımcıların değişimi daha kolay yönetebilmelerine imkan tanımıştır. Bu gibi dinamik tipli diller ile çalışma zamanında koda yapılan değişikliklerin derlenmesine gerek yoktur, yapılan değişiklikler yazılımın davranışında anında görülür. İş dünyasından gelen değişim baskıları bu gibi dinamik dillerin ortaya çıkmasını ve yaygın kullanım alanı bulmasını tetiklemiştir.

Java ya da .NET gibi platform dillerinin ortaya çıkmış olması, özellikle Java platformunda geliştirilen bileşen ve çerçeve yapılarının tekrar kullanım konusunda yazılım dünyasına umut dağıtıyor olması bir artı olmakla birlikte, çığ gibi büyüyen değişim karşısında tek başına değişime ayak uydurmanın yolu olması da pek gözükmemektedir. Yukarıda bahsedilen dinamik diller ile tasarım şablonları, bileşen ve çerçeve yapılarını projelerde rahat bir şekilde uygulayabilmek de ancak uzun süreli eğitim ve tecrübeden sonra mümkündür. Baskının zaten zaman konusunda olduğu günümüz yazılım projelerinde bu yapıları uygulamak için yazılımcıların fazla fırsat bulamadıkları da açıktır.

UML gibi modelleme notasyonlarının yaygın kullanımı ve yazılımların artık bu notasyonlar ile belgelenmesi, yazılımların sadece karmaşıklıklarını yönetmemize yardımcı olmamış aynı zamanda yazılım içine gömülen bilgiyi yazılımın dışına çıkartarak, yazılım değişmesini yönetmeyi kolaylaştırmıştır. Fakat, yukarıdaki paragrafta ifade edilen negatif etkenler bu konuda da geçerlidir.

Görünmezlik: Yazılımlar görünmez olmaya devam ediyorlar. Yazılımı görünür kılmak çok da mümkün olmasa da yazılım elemanlarını ya da yazılımın değişik yönlerini gözde canlandırılabilir yapmak mümkündür. UML gibi notasyon dilleri, sahip oldukları güçlü soyutlamalar sayesinde, yazılımın farklı yönlerini daha rahat algılanır ve anlatılır hale getirmişlerdir.

Yukarıdaki paragraflarda bahsedilen tasarım şablonları, mimari tabanlı yaklaşım, bileşen ve çerçeveler de aslında yazılımlarla alakalı çok güçlü soyutlamalar barındırmakta ve yazılımı tahayyül etme gücümüzü arttırmaktadırlar. Fakat bu yapıların kendilerinin aynı zamanda, öğrenme ve başarılı bir şekilde uygulanma sürecinde ciddi bir görünmezlik yaratmakta olduğu da gözden kaçırılmamalıdır. Yukarıda da anlatıldığı gibi bu yapıları uygulayabilmenin gerektirdiği bilgi, tecrübe ve zaman da genelde yazılım projelerinin en eksik taraflarını oluşturmaktadır.

 

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

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

Yazılım Mühendisliğ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ı: 3174