The Mythical Man-Month
Frederic Brooks’un The Mythical Man-Month kitabı yazılım geliştirme literatüründe klasik kitaplardan birisidir. Yazılım geliştirmede insan faktörü, kültür, sorunlar, kariyer, organizasyon vs. bir çok konuda bu kitaba referans verildiğini, bir çok kişi tarafından “must read” olarak belirtildiğini görebilirsiniz.
Ben bir kaç defa kitabı okumaya yeltendim ancak yarıda bıraktım, dili yabancı geldi anlamakta zorlandım, bahsedilen konuların günümüze yansımalarını bulmakta zorlandım. Sonunda kitabı bitirmeye karar verdim, bunu yaparken de benimle aynı durumda olan insanlara kitap hakkında genel bir intiba vermek adına özet bazı notlar almaya çalıştım.
Sonuç olarak geldiğim nokta kitabı baştan sona okumak çok gerekli değil. Günümüzde de yaşanılan, en azından daha üst düzeyde yaşandığını düşündüğüm bazı sorunlara değinen bölümleri okumak yeterli. Kitabın 17. bölümünde önceki bölümlerde bahsedilen konular maddeler halinde verilmiş, kitap’da nereyi okumalıyım sorusuna cevap bulmak adına ilk önce o bölüm de okunabilir.
Kitabın ilk versiyonu 1975 yılında basılmış, günümüzdeki teknoloji, yönetim, pazarlama gibi alanların geldikleri nokta itibariyle kitabın güncelliğini kaybettiğini düşünenler olduğu gibi, kitapdaki bahsedilen özellikle insan ile ilgili sorunların hala geçerli olduğunu düşünenler de var bu da zaten kitabın hala popüler olmasının temel nedenlerinden birisi. Yani bugün yaşadığımız, belki de kendimize özel zannettiğimiz bir çok problem, 40yıl, belki 50-60yıl önce de, belki bizler henüz hayata bile gelmeden önce de yaşanıyordu ve insanlar bu problemleri çözmek için kafa yoruyordu, bugün hala kafa yoruyor. Neymiş bu değişmeyen sorunlar veya bunların kaynakları diye bakınca da ilk sırada insan’ı görüyorsunuz. 40yılda teknoloji çok değişti ama görünen o ki teknolojideki insan faktörü o kadar değişmemiş.
Kitap’ın yazılma amacı Brooks tarafından “Yazılım geliştirmeyi yönetmek neden bu kadar zor?” sorusuna cevap vermek olarak belirtiliyor.
Kitabın bölümlerini özet olarak anlatmaya çalışacağım.
“The Tar Pit” bölümünde yazılım projeleri bir bataklığa giren ve orada yavaş yavaş batan hayvanlara benzetiliyor. Yazılım projelerinin bu sorununu çözmek için öncelikle problemi anlamalıyız denip, sistem programlama’nın ne olduğu, yazılım geliştirmenin kefiyli ve kederli, zor yanları başlıkları altında üç ana konuya değiniliyor.
Brooks, “bu kadar süre ne yapıyorlar ki ben bu yazılımı çok daha kısa sürede yazarım” diyen kişilerin ürettiği yazılımlar ile kurumsal olarak üretilen yazılımlar ve sistem yazılım ürünlerinin arasındaki bazı farklara değiniyor. Bu farklar ciddi oranda maliyetleri değiştiren, üç katına, dokuz katına çıkaran farklar. Bir yazılımın ürün olabilmesi için yapılması gereken bazı şeyler; genel geçer olmasının sağlanması, testinin yapılmış olması, dökümantasyonunun yapılmış olması, güncellemelerinin yapılabilmesi, yapılması. Bu tarz gereksinimler, aynı fonksiyonlara sahip olsa bile bunların olmadığı bir yazılımdan üç kat daha fazla maliyet çıkmasına neden olabilecek gereksinimlerdir. Eğer bir sistemin bir bileşeni olacak şekilde yazılım üretmeniz gerekiyor ise burada da arayüzler, entegrasyonlar gibi konulara dikkat etmeniz gerekiyor, bunlar da kendi başına olan(stand-alone) bir yazılımda üç kat daha fazla maliyet çıkarabilecek gereksinimler. Birden fazla yazılım bileşeninden bir ürün ortaya çıkaracaksanız da maliyetiniz dokuz katına kadar çıkabilir.
Yazılım üretmenin kefiyli yanları:
- Bir şeyler tasarlayıp, yapmanın, üretmenin verdiği keyif.
- Diğer insanlara faydalı bir şeyler yapmanın verdiği keyif.
- Karmaşık bir puzle’ın bir birine kenetlenmiş hareketli parçalarına benzeyen sanal nesnelere biçim vermenin ve onların beraber çalışmasını izlemenin, ürettikleri sonuçları değiştirebilmenin büyüsü.
- Sürekli öğrenmenin verdiği keyif.
Yazılım üretmenin kederli, zor yanları:
- Yaptığınız işi mükemmel yapmak ya da mükemmeleştirmek zorundasınız, hata yaptığınızda veya küçüçük bir şeyi eksik yaptığınızda her şey durabiliyor.
- İnsanların bir birlerine bağımlılıkları. Bir insanın amacının, kaynaklarının, bilgisinin diğer insanlara sıkı sıkıya bağlı olması, sizin kendi işinizin şartlarını, amacınızı çoğu zaman kendi başınıza belirleyememeniz. Başkalarının yazdığı, kötü yazılmış, testleri olmayan, dökümantasyonu olmayan kodları kullanmak, o kodları düzeltmek zorunda olmak gibi.
- Büyük şeyler tasarlamak eğlenceli ancak bazen gizlenmiş küçük bir hatayı bulmak için, zahmetli, sıkıcı, zorlayıcı şekilde saatlerce çalışmanız gerekebilir.
- Projenin sonlarına doğru hataları bulmanın daha zor olması ve debugging ile daha çok zaman geçirilmesi.
- Uzun zamandır üzerinde çalışılan ürün henüz tamamlanmadan demode olması, yeni fikirlerin yeni yaklaşımların ortaya çıkması.
Kitaba ismini de veren “The Mythical Man-Month” bölümü yazılım maliyetlendirmedeki sorunlardan bahsediyor. Burada eleştirilen temel konular süre ve insan’ın bir birinin eş değeriymiş gibi görülmesi, yani teoride; bir ay on adam eşittir on adam/ay, yarım ay yirmi adam eşittir on adam ay olması, ancak pratikte bu iki durumun bir birine eşit olmadığı. Bir diğer konu ise bu mantalite ile geç kalan yazılım projelerini yetiştirmek için projeye daha fazla insan konulması.
Projelerde neden bu kadar çok takvimsel problemler yaşanıyor?
- Maliyetlendirme yaparken genellikle yanlış bir yaklaşım olarak herşeyin iyi gideceğini varsayıyoruz. Yazılımcıların çoğu maliyetlendirme konusunda fazla iyimser kalıyor.
- Efor ve ilerlemeyi bir birine karıştırıyoruz, adam ve ay’ın bir birinin yerine geçebilir olduğu kabullenmesi ile maliyetlendirme yapıyoruz. Dokuz ayda doğacak bir çocuğu dokuz kadının bir ayda doğuramayacağı gerçeğini çoğu zaman kaçırıyoruz.
- Verdiğimiz maliyetler çok fazla belirsizlik içeriyor ve yazılım yöneticileri bunu kabullenmede ve yönetmede çok başarılı değiller.
- Takvimdeki ilerleme iyi bir şekilde gözlemlenemiyor. Diğer mühendislik dallarındaki bu konuda rutin şeyler yazılım mühendisliğinde radikal yenilikler olarak görülüyor.
- Takvimde geri kalınmaya başlandığında bu soruna geleneksel ve doğal cevap daha fazla adam gücü eklemek oluyor. Bu yangına benzin dökmek gibi sorunları daha da büyütüyor. Daha fazla yangın daha fazla benzin gibi sonu yok olma ile biten bir süreç başlıyor.
“The Surgical Team” bölümünde özellikle genç yöneticilerden işitilen şöyle bir şikayet konu ediniliyor: Yüzlerce programcının olduğu bir projeden ise birinci sınıf, yetkin insanlardan oluşan küçük bir takımın tercih edilmesi. Ancak bu küçük takım çok büyük projelerin gerçekleştirilmesine yetmeyecektir veya böyle küçük bir takımın büyük bir projeyi gerçekleştirmesi yıllarca sürecektir.
Küçük takımlar olsun ancak büyük projeleri nasıl yapacağız problemine çözüm olarak Harlan Mills’in “surgical team” önerisi sunuluyor. Öneri şu şekilde: Büyük işlerin her bir parçası bir takım tarafından ele alınsın ancak bu takım her bir elemanının işin bir parçasını alıp yapması şeklinde değil, bir cerrahi ekip gibi, işin ana sorumlusu ve yapanı bir cerrah var ve ona yardımcı olan, onun işini daha iyi yapabilmesini, daha rahat olabilmesini dolayısı ile daha üretken olabilmesini sağlayan diğer insanlar var şeklinde organize olsun.
Peki bu cerrahi takımdaki anestezi uzmanı kim, hemşireler kim, iş bölümü nasıl yapılacak?
Cerrah: Mills bu kişiyi şef programcı olarak adlandırıyor. Sistemin gereksinimlerini tanımlayan/yöneten, tasarımı yapan, kodu yazan, testi yapan, dökümantasyon yapan bir kişi. Deneyimli, teknik yetenekleri üst seviyede.
Yardımcı Pilot: Cerrahın yaptığı tüm işleri yapabilen daha az deneyimli birisi. Cerrah’ın fikirlerini yorumlayabilecek, alternatif düşünceler ortaya koyabilecek, bazı durumlarda cerrah’ın hata yapmasını engelleyebilecek birisi.
Yönetici: Patron cerrah, kişiler, terfiler, para, lokasyon vs gibi konularda son söz onun ancak bunların hepsine yetişemeyeceği için bu işlerde yönetici takıma karşı bir ara yüz gibi davranır.
Editör: Dökümantasyondan cerrah sorumlu, editor cerrah tarafından üretilmiş draft dökümanları alır ve onları gözden geçirir gerekli düzenlemeleri yapar.
İki tane sekreter: Yönetici ve editor’un birer tane sekreteri vardır. Yönetici sekreteri proje yazışmalarını ve ürün ile ilişkili olmayan dökümanları yönetir.
Program Katibi: Takımın tüm teknik kayıtlarının bakımından sorumludur. Teknik kayıtlar makine kodu dosyaları ve insanların okuyabileceği dosyaları kapsar.
The Toolsmith(Tam bir türkçe karşılık bulamadım): Takım tarafından ihtiyaç duyulan utility servislerinin ve araçlarının yapılması, kurulması, bakımı gibi işlerden sorumludur.
Testçi: Test durumlarının hazırlanmasından ve koşulmasından sorumludur.
Programlama Dilinin Avukatı: Zor problemlerde kullanılan programlama dili ile nasıl çözümler üretilebileceğini bulan kimsedir.
Günümüzde tercih edilen self-organize, cross-functional takım gibi kavramlar ile bu önerinin ne kadar uyuştuğu tartışılır ancak o yıllarda büyük bir projeyi kontrollü şekilde götürebilmek ve takımın bir bütün gibi davranmasını sağlamak adına otoriteyi takım bazında bir kişide toplayan bu şekilde bir takım organizasyonu önerisi çıkmış.
“Aristocracy, Democracy, and System Design” bölümünün odak noktası “conceptual integrity”, Türkçeye kavramsal bütünlük olarak çevrilebilir belki. Kavramsal bütünlük daha çok bir sistemin iç tasarımı ile ilgili. İç tasarımının aynı felsefe aynı mantık ile sanki tek bir elden çıkmış gibi uyumlu bir bütün olması.
Binaların kavramsal bütünlüğü ve bunu sağlayanın binanın tasarımının tek bir mimarın elinden çıkması örneği burada kullanılmış. Yazılımda aynı mantık ile ilerlemek ne kadar doğru sorusunun cevabı aranıyor. Yazılımda sistemi tasarlayan mimarlar ile sistemin gerçekleştirimini yapanları bir birinden ayırmamız bunu sağlar mı? Aristokrasi kısmı sistemi tasarlayan elit bir mimari grubunun bulunması için metafor olarak kullanılıyor. Demokraside ise sistemin tasarımı yatayda mimarlar, programcılar şeklinde dağılıyor. Yazar aristokrasinin, yani yatayda bir dağılma yerine dikey bir hiyerarşide tasarım ve gerçekleştirimi ayırmanın kavramsal bütünlüğü daha iyi sağlayacağını, uzun vadede projenin süresini kısaltacağını ve iletişimi daha kolay hale getireceğini savunuyor.
“The Second-System Effect” bölümünde bir mimarın ikinci sistemi genellikle en kötü tasarlanmış sistem olur tezi işleniyor. Birinci sistemin altından başarı ile kalkan mimar ikinci sistemde çok fazla açılabilir ve bu sistem çok karmaşık tasarlanmış(over design), çok fazla gereksiz fonksiyon içeren bir sistem olabilir.
“Passing the Word” bölümü daha önceki iki bölümde üzerinde durulan kavramsal bütünlük ile ilgili. Bir mimarın veya mimari grubun kararlarının bin kişilik bir ekipte herkes tarafından duyulduğundan, anlaşıldığından ve yapıldığından nasıl emin olunacak. Bunun ile ilgili kullanıcı bakış açısıyla sistemin özelliklerinin yazdığı bir dökümantasyon olması, ürünün formal ve formal olmayan tanımlarının standartlarının olması, düzenli olarak farklı gruplar ile toplantılar yapılması, mimari ekibe telefon ile gelen soru/cevapların kayıt altına tutulup yayınlanması, bağımsız bir ürün test ekibinin olması gibi öneriler sunulmuş.
“Why Did the Tower of Babel Fail?” bölümü babil kulesi projesinin başarısız olmasının nedenleri ile başlıyor. Hikayenin derinliğini tam olarak bilmemekle beraber tarihsel olarak babil kulesi inşa edilmişti diye biliyorum ancak yazar böyle bir metafor kullanıyor bu bölümde. Babil kulesi neden başarısız oldu; İletişim ve organizasyondaki sorunlar nedeniyle.
İletişim ve organizasyon büyük projelerinin başarısızlığındaki en büyük 2 etken. Bu iki konuda başarılı olabilmek için neler yapmak gerekiyor sorusuna cevap verilmeye çalışılıyor. Büyük bir proje içerisinde sağlıklı bir iletişim için önerilen çözümler; telefon görüşmeleri gibi informal yöntemler, düzenli toplantılar ve proje çalışma klavuzu(workbook). Proje çalışma klavuzuna özel bir önem verilerek bazı detaylar veriliyor. Bu klavuz proje ile ilgili tüm dökümantasyonların tutulduğu ortam ve burada üstesinden gelinmeye çalışılan iki sorun: Tüm proje ekibinin güncel klavuza ulaşmasının sağlanması ve klavuzun güncel tutulması.
Organizasyon için: yetki ve sorumlulukların dağılımı bakış açısıyla ağaç yapısı hiyerarşiler tercih ediliyor ancak bu yapı iletişim anlamında yeterli olmuyor. İletişim temelli düşünürsek hiyerarşinin network şeklinde olması gerekiyor. Bunun için bir çok teknoloji gurubunda organizasyon komite, grup gibi oluşumları içerecek şekilde matrix organizasyon yapısında oluyor. “The Surgical Team” bölümden olduğu gibi bazı rollerden bahsedilmiş ve bu rollerden “producer”: Organizasyonel olarak yönetim işleri ile uğraşan rol, ve technical director: Teknik olarak yönetim işleri uğraşan rol, rollerinin nasıl konumlanabileceği ile ilgili alternatifler(“producer”, “technical director”‘un yöneticisidir veya tersi gibi) üzerinde durulmuş.
“Calling the Shot” bölümü yazılım maliyetlendirmesi ile ilgili. Burada bir yazılımın ortalama ne kadar instruction, statement içereceği ve bir yazılımcının ayda, yılda ne kadar bunlardan yazabileceği gibi temeller üzerinde duran bir kaç yaklaşım örnek verilmiş.
Benim fikrim: Günümüzde maliyetlendirme anlamında çok kullanılan yöntemler değil benim gördüğüm kadarıyla. Mesela üst seviye bir dil kullanırsanız instruction sayısı azalacağı için maliyetleriniz de düşecektir gibi bir sonuç var. Elbette bu bir etkendir ancak tek başına bir etken değildir, üst seviye bir dil kullansanız bile maliyetiniz alt seviyede kullanılan bir dile göre yüksek olabilir, proje, insan, ortam, müşteri gibi farklı etkenlerin devreye girmesiyle.
“Ten Pounds in a Five-Pound Sack” bölümü programların kullandığı memory ve disk alanlarının büyüklüklerinin maliyete etkisiyle ilgili. Kitabın yazıldığı yıllar donanımdaki memory, disk gibi kaynaklar günümüze oranla oldukça az ve çok pahalı olduğu için bir programın etkin bir şekilde memory ve disk kullanması yazılım geliştirmede günümüze oranla önemli bir etkendi. Günümüzde de hala bazı alanlarda(özellikle gömülü sistemlerde) bu konu önemli. Burada temel olarak bahsedilen konu programın performansı ve kullandığı kaynaklar arasındaki dengeyi, yani performans/maliyet dengesini iyi tutturmak.
“The Documentary Hypothesis” bölümü yazılım projelerinin dökümantasyon ihtiyaçları ile ilgili. Yazılım ürünlerinin veya yazılım projelerinin genel olarak hangi tip dökümanlara sahip olması gerektiği anlatılıyor.
Bahsedilen döküman tipleri;
- Hedefin, amacın anlatılması
- Yazılımın özelliklerinin anlatılması
- Takvim
- Bütçe
- Organizasyon
- Yerleşim
- Maliyetler, tahminler, fiyatlar
Neden formal dökümanlara ihtiyaç duyarız sorusuna cevap olarak;
- Alınan kararların yazılması gerekir,
- Alınan kararların diğer kişiler ile iletilmesini sağlamak için döküman gerekir,
- Yönetimsel dökümanlar yöneticiye bir veritabanı ve kontrol listesi verir
“Plan toThrow One Away” bölümü yazılım projelerinin kaçınılmaz gerçeği değişim ile ilgili. Bir yazılımın ilk versiyonunun kullanıcının istediği şekilde olması çok düşük bir ihtimal dolayısı ile bu yazılım eninden sonunda değişecek. Öncelikle bu değişimi istisnai bir durum olarak beklemekten ziyade bu işin bir gerçeği olarak kabul etmek gerekiyor, sonra da bu değişime planlama, tasarım, organizasyon seviyelerinde hazır olmak gerekiyor.
Sistemin değişime hazır olarak planlanması için moduler tasarım, moduller arası ara yüzlerin detaylı tanımı, kapsamlı dökümantasyon gibi kavramlar ön plana çıkarılmış.
Organizasyonun değişime hazır olması için iki konudan bahsedilmiş, birincisi yöneticinin işler kötüye gittiğinde duruma müdahale edebilecek iki veya üç tane üst seviyede programcıya yani kahramana sahip olması. Bir diğeri de yöneticilerin ve teknik insanların bir birleri arasında değişilebilir olmaları. Bu yüzden ünvan’ların kaldırılması gibi önerilen çözümler var.
Öncelikle yazılım projelerinde değişim’in bir gerçek’den ziyade bir sorun olarak görülmesi hala yaşadığımız bir problem. Bu gerçeğin görmezden gelinmesi ve planların, süreçlerin buna göre yapılması da daha büyük bir problem. Bunların çözümünde iki üç tane kahraman yazılım mühendisi kullanılması da hala günümüzde pratikte kullanılan yöntemlerden. İşin teorisinde, özellikle çevik yaklaşımlarda değişim kabul edilmiş bir gerçek ve buna göre değerler, prensipler ve pratikler modellenmiş durumda.
“Sharp Tools” bölümü yazılım geliştirmede kullanılan araçlar üzerinde. Burada anlatılanlar yazarın OS/360 projesi üzerinden anlatıldığı için günümüze bir eşleştirme yapmakta zorlandım. Donanım olarak bahsedilen araçlar; bilgisayarlar, simülatorlar, dökümantasyon için bilgisayarlardan bahsedilmiş. Üst seviye programlama dillerinin kullanımı ve interaktif programlama araçlarına da kısaca değinilmiş.
“The Whole and the Parts” bölümünde istenildiği gibi çalışan bir programı nasıl inşa etmek gerekir, bu program nasıl test edilmeli ve bu programın parçaları nasıl entegre edilmeli gibi sorulara cevap verilmeye çalışılıyor. Üç alt bölüm oluşturulmuş; hataları engellemek için tasarım, bileşen hata ayıklama ve sistem hata ayıklama şeklinde. Tasarım kısmında daha önceki bölümlerde bahsedilen kavramsal bütünlüğün sağlanması, kodlar yazılmadan önce test spesifikasyonlarının yazılması, top-down design gibi yöntemlerden bahsedilmiş. Top-design yöntemi yazılım üst seviyeden alt seviyeye doğru adım adım tasarlama olarak anlatılıyor.
Bileşen hata ayıklama yazılım geliştirme sırasında yapılan hata ayıklama yöntemlerini içeriyor, makine üzerinde hata ayıklama, memory dump’ları, snapshot’ları alma gibi yöntemlerden bahsedilmiş.
Sistem hata ayıklama bölümünde bir sisteme gireçek olan bileşeni sistem içinde test etmenin maliyeti yüksek olduğu için bileşenlerin mümkün olduğunda hatalardan arındırılmış olarak sisteme eklenmeleri gerektiği, sisteme kontrollü bir şekilde(sıra ile) bileşenlerin eklenmesi gerektiği gibi yöntemlerden bahsedilmiş.
“Hatching a Catastrophe” bölümü geç kalan yazılım projeleri ile ilgili. Bir projenin bir yıl geç kalmış durumda kalmaması için neler yapılabilir sorusu üzerinde duruyor. “Milestone” kavramı üzerinde duruluyor, milestone’ların proje planında somut olmasını tavsiye ediyor. Yani bir milestone ya bitmiştir ya bitmemiştir şeklinde bir yaklaşımı var. PERT(Program evaluation and review technique), critical path gibi proje yönetiminde günümüzde de kullanılan yöntemlerden bahsedilmiş. Organizasyonel anlamda da projenin geç kalmasını engellemek için rol karmaşalarından kurtulunması, halı’nın altına süpürülen bazı gerçeklerin olmaması öneriler arasında. Son olarak proje izleme grubu gibi ayrı bir grubun projenin ilerleyişini kontrol edip raporlamasının daha sağlıklı bir yöntem olduğundan bahsedilmiş.
“The Other Face” bölümü yazılım projelerindeki dökümantasyon ile ilgili. Yazılımın makineye değil kullanıcıya bakan yüzü olarak değerlendirildiği için bölümün başlığı diğer yüz şeklinde. Yazılımın bu diğer yüzünün de makineye bakan yüzü kadar önemli olduğuna vurgu yapılmış. Hangi dökümanlara ihtiyacımız var sorusunun cevabı olarak; Amaç, ortam, geçerli girdiler, beklenen çıktılar, fonksiyonlar, kullanılan algoritmalar, kullanım klavuzu, çalışma zamanları gibi alanlardan bahsedilmiş.
Nasıl dökümante etmeliyiz sorusuna flow-chart’lar kullanılması ve kendi içinde dökümantasyon barındıran programlar başlıkları altında cevap verilmeye çalışılmış. Kendi içinde dökümantasyon barındıran programdan kasıt düzgün isimlendirmeler ve kod içindeki yorumlar. Bu yöntemin avantajı olarak güncel ve kolay ulaşılabilir olması, dezavantajı olarak da kod büyüklüğünün artması gösterilmiş.
Günümüzde kod içinde “deodorant” olarak kullanılmayan, nasılı değil nedeni açıklayan yorumlar yazılması tavsiye ediliyor. Yaşayan dökümantasyondan, yaşayan ve çalıştırılabilen dökümantasyon(specifications, bdd, cucumber vs.) gibi kavramlara geçiş var.
“No Silver Bullet- Essence and Accident in Software Engineering” bölümü kitabın yazılım dünyasında en çok referans gösterilen bölümlerinden birisi muhtemelen. Burada anlatılan konu; Verimli, güvenli, basit yazılımları üretebilmek için diğer tüm yöntemlerin üzerine çıkan tek bir geliştirme, yönetim tekniğinin veya teknolojinin olmadığı. Yani tüm sorunlarınızı bir anda çözebilecek bir sihirli değnek yok yazılım dünyasında.
Peki neden böyle sorusuna cevap olarak yazılım projelerinin zorlayıcı ve kalıcı olduğu düşünülen zorluklarına değinilmiş. Bu zorluklardan bazıları; Neyin inşa edileceğine karar vermenin veya tamamıyla karar verebilmenin imkansız oluşu, karmaşıklık, yazılım projeleri geliştirilirken ve geliştirildikten sonra gelebilen sürekli değişiklik istekleri ve yazılım projelerini alt seviyede görsel olarak ifade edebilmenin imkansız oluşu.
Zaman içinde kurtarıcı olarak görülen bazı yazılım geliştirme yöntemlerinden, dillerinden ve bunlar ile ilgili bazı sorunlardan bahsedilmiş, bazıları; Nesneye dayalı programlama, Yapay zeka, Uzman sistemler, Otomatik programlama, Grafiksel programlama, kullanılan bilgisayarlar vs.
Genel geçer tüm problemleri çözen değil ama yazılım projelerindeki bazı zorlukların üzerinden gelmenizi sağlayacak bir kaç yönteme de değinilmiş; Gereksinimlerin sürekli iyileştirilmesi ve protype yöntemi, Incremental geliştirme(yazma ve inşa etme arasındaki fark) ve yetkin/güçlü tasarımcılara sahip olma.
Kitaptaki No Silver Bullet bölümü orjinal olarak 1986’da bir sempozyuma makale olarak gönderilmiş. Kitabın bu bölümünden sonraki bölümleri 1995 yılında kitabın 20.yılı anısına tekrar basıldığı zaman ekleniyor. No Silver Bullet “Refired” bölümü aradan geçen dokuz yılda No Silver Bullet(NSB olarak kısaltılmış) kavramının hangi noktada olduğunu yorumluyor. NSB’nin orjinal iddiasında on yıl diye bir kavram da geçiyor. Yani herhangi bir methodoloji on yıl boyunca kurtarıcı olamaz diye de düşünebiliriz. Bu bölümde aradan dokuz yıl geçti ne oldu ne bitti şeklinde ilerliyor. NSB kavramına gelen farklı kişilerden yorumlar’ın üzerinde duruluyor. Karmaşıklık, verimlilik, object oriented tasarım, yeniden kullanılabilirlik gibi kavramların geldiği noktalar hakkında yorumlar var.
Nihai olarak bu bölümde gelinen nokta, yazılım teknolojilerinde bu sihirli yöntemin gelmesini beklemeyin, gelmeyecek, dolayısı ile adım adım süreçlerinizi, projelerinizi iyileştirmeye bakın.
“Propositions of The Mythical Man-Month True or False?” bölümü kitabın 1975 yılında yazılmış 15 bölümünde, aradan geçen yirmi yılda(1995’de yazılıyor bu bölüm) kitabın değindiği konuların hangilerinin geçerliliğini koruduğu çıkarsamasını yapabilmek için özet bilgi veriyor. Bazı güncel yorumlar da dahil edilmiş. Aslında benim yukarıda yapmaya çalıştığımın biraz daha geniş kapsamlısı olarak düşünülebilir ancak maddeler olarak verilen cümleler arasındaki ilişkiyi kurmak çok kolay olmuyor.
“The Mythical Man-Month after 20 Years” bölümü 1995 yılı itibariyle yazılım dünyasında gelinen noktayı ve kitabdaki bazı bölümlerin neden hala geçerliliğini koruduğunu anlatıyor. Kitabın geçerliliğini koruması ile ilgili iki ana neden öne sürülmüş, birincisi yazılım geliştirme disiplilerinin yeterince hızlı gelişmediği, donanım teknolojilerinin daha önce hiç bir alanda görülmemiş kadar hızlı geliştiği ancak yazılım geliştirme disiplinlerinin bunun gerisinde kaldığı dolayısı ile yirmi yıl önce yaşanılan bazı sorunların hala geçerliliğini koruduğu söylenmiş. Bir diğer neden kitapda bahsedilen konuların bazıların doğrudan insanlar ile ilgili olması ve insan psikolojisinin ve davranışlarının da değişiklik göstermediği.
Bu bölümde, kavramsal bütünlük, mimarın rolü, waterfall modeli, iterative modeller, yazılımda insan faktörü gibi konulara güncel, yani 1995 yılı itibariyle, tekrar bakılmaya çalışılmış.
Bence kitapda gerçekten güncel anlamda, okurken bir şeyler hissedebileceğiniz bölümler; The Mythical Man-Month, The Second-System Effect, Plan to Throw One Away, No Silver Bullet- Essence and Accident in Software Engineering, “No Silver Bullet” Refired, Propositions of The Mythical Man-Month True or False?, The Mythical Man-Month after 20 Years.