Gümüş Kurşun: Karmaşık Problemlere Sihirli Çözümler

Frederick P. Brooks ‘No Silver Bullet — Essence and Accident in Software Engineering’ isimli makalesinde yazılım projelerini kurt adamlara benzetir. Başlangıçta masum ve basit gözüken projelerimiz, zamanla geciken teslim zamanları, aşılan bütçeleri ve kusurlu çıktıları ile canavarlara dönüşebilirler. Bizler de aynı kurt adamlara karşı kullanılan gümüş kurşunlar gibi bu canavarlarları yenmek için farklı araçlar bulmaya çalışırız. Ancak gerçek hayatta ne kurtadamlar ne gümüş kurşunlar ne de özünde karmaşık olan problemler için sihirli çözümler vardır.

Brooks’un makalesi yazılım mühendisliği üzerine olmakla birlikte, temel yaklaşımı açısından günümüzde bir çok alana uygulanabilecek bir perspektife sahiptir. Yazılım mühendisliğinde yaşanan zorlukları iki ana kategori altında ele alır; yapılan işin özünden kaynaklananlar ve rastlantısal olarak karşılaşılanlar.

Rastlantısal zorluklar aslında daha çok araçlarla ilgili zorluklardır. Yazılım dünyasında güçlü bir tümleşik geliştirme ortamının olması ve yetkin yazılım kütüphanelerine erişebilmek gibi imkanlar yapılacak işi daha kolay yapmamıza yardımcı olabilir. Yazılım haricinde değerlendirirsek, örneğin içinde bulunduğumuz pandemi ortamında çevrimiçi ortak çalışma uygulamaları, iş takip ve yönetme sistemleri gibi araçlar işimizi yaparken daha verimli çalışmamızı sağlayabilirler. Bununla birlikte bu araçlar destek araçlarıdır, bunlara erişimimiz olması hayatlarımızı kolaylaştırmasına rağmen aslında çözmeye çalıştığımız problemleri direkt olarak etkilemezler.

Özden kaynaklanan zorlukları Brooks aşağıdaki dört ana başlık altında toplar:

• Karmaşıklık
• Uyumluluk
• Değişebilirlik
• Görünmezlik

“Karmaşıklık” bunlardan birincisidir. Ürünlerin büyüklüğü ve kapsamı arttıkça karmaşıklık doğrusal olmayan bir şekilde artar. Artan karmaşıklıkla takım üyeleri ve takımlar arasındaki iletişim zorlaşır, maliyet aşımları veya teslim zamanlarında gecikmeler yaşanabilir. Ürünün sunduğu bütün fonksiyonların nasıl davranacağını tahminlemek, test etmek ve bunların kullanıcılar tarafından kolayca kullanılabilmesini sağlamak zorlaşır. Yapısal karmaşıklıktan dolayı yeni eklenecek özelliklerin önceki özelliklerle nasıl bir etkileşimi olacağı veya ne gibi güvenlik zaafiyetlerine yol açacağı öngörülemez hale gelir.

“Uyumluluk” özden gelen zorlukların ikincisidir. Bir ürün veya uygulama diğer etkenlerden bağımsız izole bir ortamda yaşamaz, farklı sistemlerle etkileşime girmesi ve bu sistemlerle uyumlu bir şekilde çalışabilmesi gerekir. İş alanlarından, platformlardan, standartlardan veya yasalardan kaynaklanan gereksinimler ve regülasyonlarla da uyum içinde olmalıdır. Uygulama ve ürünlerin sadece kendi özellikleri değil, içinde bulunulan ekosistemin tamamı tasarlama ve geliştirme aşamalarında göz önünde bulundurulmalıdır.

Üçüncü zorluk “Değişebilirlik”tir. Brooks makalesinde yazılımın fiziksel ürünlere göre daha kolay değiştirilebilir olduğu için değişim baskısının çok daha yoğun olduğunu belirtir. Buna ek olarak, iyi bir yazılım, kullanıcıları o ürünü daha da zorlamaya ve hatta orjinal alanı hariç yerlerde de kullanmaya yönlendirebilir ve bunlar da ürünle ilgili yeni istekler ve değişim talepleri olarak karşımıza çıkabilir. Günümüze baktığımızda bu durumun sadece yazılım sektöründe yaşanmadığını görüyoruz. Ürünlere sahip olmak yerine hizmet alma veya kiralama yaklaşımın artması, alternatifler arasında karşılaştırmanın internet üzerinden kolayca yapılarak farklı ürün ve hizmetlere geçilebilmesi gibi faktörler, kullanıcıların taleplerinin hızla anlaşılıp en kısa zamanda gerekli değişikliklerin gerçekleştirilmesini kritik bir başarı faktörü haline getirmiştir.

Dördüncü ve son zorluk “Görünmezlik”tir. Yazılımların görselleştirilmesi zordur. Örneğin bir binanın kat planı hem mimar hem de müşteri için katlardaki alanları ve oluşacak trafik akışlarını net bir şekilde gösterir. Bir yazılımı görselleştirmeye çalıştığımızda ise tek bir diagrama indirilemediğini görürüz. Kullanıcı kontrolleri, data akışları ve yapısal bağımlılıklar için ayrı ayrı görselleştirmeler gerekir. Çeşitli teknikler kullanılarak bu diagramlar basitleştirilebilse bile bütün resmi bir anda kavranacak şekle getirmek çoğu zaman mümkün olmaz. Bu durum sadece tasarımın algılanmasını zorlaştırmakla kalmaz aynı zamanda birlikte çalışan kişilerin iletişimini engeller.

Brooks 1986 yılında yayınlanmış olduğu bu makalesinde bizlerin günümüzde de yaşadığı birçok zorluğu neredeyse nokta atışı yaparak tanımlamıştır. Sadece sorunları tanımlamakla kalmamış, makalesinin son bölümünde özden kaynaklanan zorluklar için ümit vadeden bazı çözümlerden de bahsetmiştir. Bunlar;

• Çözümü üretmek yerine satın almak veya kiralamak,
• Gereksinimleri hızlı prototipler ile netleştirmek,
• Ürünleri artımlı (incremental) olarak geliştirmek ve
• Harika tasarımlara ve tasarımcılara sahip olmaktır.

Brooks’un ilk önerisi karşılaştığımız zorluklar için hazır çözümler bulup bulamayacağımızı değerlendirmektir. Yazılım üretirken yaşanan zorlukları çözmek için en radikal çözüm yazılımı üretmemektir der. Ürünlerimizde karşılaştığımız zorluklar başkaları tarafından da yaşanmış ve halihazırda piyasada bunları gidermek için o konuda uzmanlar tarafından üretilmiş çözümler bulunuyor olabilir. Bu gibi durumlarda “Çözümü üretmek yerine satın almak veya kiralamak” bizlere sadece zaman kazandırmakla kalmaz, enerjimizi ve eforumuzu halihazırda çözülmüş problemler yerine ürünümüze yönlendirme fırsatı da sağlar.

Hiç ürününüze yeni bir özellik eklemeye çalışırken kendinizi bitmek bilmeyen toplantılar silsileleri içinde veya başı ve sonu arasında aylar hatta yıllar olan elektronik posta zincirleri içinde buldunuz mu? Peki, teorik olarak bu kadar süre detaylar üzerinde çalıştıktan sonra işe başladığınızda yaptığınız planların gerçekte uygulanamaz olduğunu veya düşündüğünüz gibi çalışmadığını keşfettiğiniz oldu mu? “Gereksinimleri hızlı prototipler ile netleştirmek” bu noktada özden gelen zorluklarla mücadelede kullanabileceğimiz bir diğer yöntemdir. Prototipler ucuz ve hızlı üretilebilir olmalarına rağmen ürünümüzle ilgili fikirlerimizi ve varsayımlarımızı test edebilmemiz için çok güçlü araçlardır. Basit çizimlerden herhangi bir kodlama yapmadan ekranlar arasında tıklayarak ilerlememizi sağlayan interaktif prototiplere kadar birçok yöntem artık yaygın olarak kullanılıyor.

Kullanabileceğimiz üçüncü yöntem “Ürünleri artımlı (incremental) olarak geliştirmek”tir. Brooks bunu inşa etmek yerine yetiştirmek olarak tasvir eder. Nasıl bir ağaç doğada bir anda var olmuyorsa, ağaç olmadan önce tohum, filiz, fidan gibi evrelerden geçiyorsa ürünler de aşama aşama olgunluğa varabilir. Bu şekilde geliştirilen ürünlerin bir çok avantajı vardır. Öncelikle üründe yapılan değişiklikler küçük bir kapsama sahip olacağı için sahaya çıkış ve sahadan geribildirim alma süreleri kısalır. Bununla birlikte her seferinde üründe az sayıda özelliği değiştirdiğimiz için kullanıcıların hangi değişiklikleri sevdiklerini hangilerini beğenmediklerini anlamamız ve buna göre harekete geçmemiz kolaylaşır. Canlıya çıkma süresinin kısalması sadece kullanıcıları değil, ürün üzerinde çalışan ekipleri de etkiler. Yıllardır üzerinde çalışılan ancak henüz canlıya çıkmamış bir ürün yerine basit de olsa bir iki özelliği ile kullanılmaya başlayan bir ürün moral ve coşku açısından çok büyük etkilere sahiptir diye ifade eder Brooks.

Son olarak, “Harika tasarımlara ve tasarımcılara sahip olmak”. İyi tasarımlara sahip olmak belki şans veya tasarımcının dehası sayesinde gerçekleşiyor diye düşünebiliriz ancak şans ve deha iyi bir tasarım pratiği uygulanmadığında ne kadar başarılı olabilir? İyi tasarım pratikleri öğretilebilir yöntemlerdir ve fırsat verildiğinde herkes bu alanda kendini geliştirebilir. Doğru yönlendirmeler, mentörlük, öğrenme ve deneme yanılma imkanları ve benzer zihniyete sahip olan kişiler ile girecekleri etkileşimlerle insanlar birlikte büyüyüp zorluklara birlikte çözümler üretebilir.

İnsana önem vermek, prototipler hazırlayarak ürünlerimizin nasıl çalışacağı hakkında fikir edinmek için deneyler yapmak, ürünlerimizi artımlı olarak geliştirip her adımda sahadan aldığımız geri bildirimlerle yönümüzde gerekli düzenlemeleri yaparak ilerlemek… Tüm bunlar uyguladığımız çevik ve yalın yaklaşımların temelinde yatan ana özelliklerdendir.

Brooks’un makalesi 35 yılı devirmiş olmasına rağmen halen güncelliğini ve değerini koruyor ve gelecekte de korumaya devam edecek gibi gözüküyor.

Referanslar:

Brooks, Fred P. (1986). “No Silver Bullet — Essence and Accident in Software Engineering”