Fred Brooks geçen ay 91 yaşında öldü.. En çok satan yazılım geliştirme yönetimi kitabı sayesinde, Yazılım Mühendisliği Üzerine Efsanevi Adam-Ay Denemeleribir programlama ve yönetim efsanesi oldu.
On yıllar boyunca birçok teknoloji lideriyle tanıştım ama çok azı Brooks kadar etkileyiciydi. Onu etkinliklerde birkaç kez görmeme rağmen, onunla yalnızca Kuzey Karolina Üniversitesi bilgisayar bilimi bölümünün başkanıyken bir kez konuştum.
Steve Jobs gibi bazı teknoloji liderleri dehalarını bir nova gibi gösteriyor. Brooks gibi diğerleri sessiz, esprili ve kendi tarzlarında eşit derecede parlak.
Kitap olmasaydı bile, Brooks bilgisayar tarihinde en ünlülerden biri olarak ünlü olurdu. birden fazla bilgisayar mimarisinde kullanılabilecek bir işletim sistemi geliştirmek için liderler: IBM’in OS/360.
Tesadüf eseri, 360 derleyici benim ilk bilgisayar dilim oldu. Adil uyarı: Hiç kimsenin anadili IBM 360 Assembler olmamalıdır.
360 İş Kontrol Dili’ne (JCL) gelince, aynı zamanda Brooks’un bunu “herhangi bir yerde, herhangi biri tarafından tasarlanmış en kötü bilgisayar programlama dili” olarak adlandırdığını öğrendim. Sadece ana bilgisayarlardan Unix mini bilgisayarlara geçmemin “nedenleri” olduğunu söyleyeceğim.
Kişisel olarak Brooks, “Verdiğim en önemli tek karar, değişmekti. 6 bit bayttan 8 bit bayta IBM 360 serisi, böylece küçük harflerin kullanılmasını sağlar. Bu değişiklik her yere yayıldı.”
Evet bu doğru. Hepimizin kullanarak büyüdüğü 8 bit, 16 bit, 32 bit ve 64 bit bilgisayar mimarilerinin tümü Brooks’la başladı.
Heck, çipler ve bilgisayar tasarımları için “mimari” kelimesinin kendisi ondan geliyor.
Ancak çoğumuzun hatırladığı, özlü yönetim ifadeleriyle onun kitabıdır. Şimdi, keşke onları ofislerimizde daha çok kullansaydık!
Bunlardan en bilineniyle başlayalım: Brooks yasası: “Geç kalmış bir yazılım projesine insan gücü eklemek onu daha geç yapar.”
Tekrar tekrar, bunu patlatan şirketler görüyorum.
Bu günlerde çoğu zaman, bu gaf, oh, diyelim ki, her şeyin geliştiriciler Cuma öğleden sonra ofise gelir çalışmalarını haklı çıkarmak ve bir sprint üzerinde çalışmak. Evet, gerçekten de Elon Musk ve Twitter’ı düşünüyorum.
Yine de sadece Musk değil. İşinizde, herhangi bir projenin sonunda onları kapı dışarı etmek için her zaman bir ton fazla mesai saati harcıyorsanız, yanlış yapıyorsunuz demektir. Elbette, bazen buna ihtiyaç duyulur; ama bu bir alışkanlık haline gelirse, bir yönetim probleminiz var demektir.
Bununla ilgili bir Brooksizm, “dokuz kadın bir ayda bebek yapamaz” şeklindedir. Veya, yine Musk’ı seçerseniz, dokuz gömülü sistem Tesla programcısını getiremez ve bir ay içinde yeni bir sosyal ağ özelliği oluşturamazsınız. Ya da üç ay, hatta dokuz ay da olabilir.
Bununla ilgili başka bir soru da şudur: “Büyük bir yazılım projesi nasıl bir yıl gecikir? Cevap: Her seferinde bir gün!” Çözüm, her yönetim düzeyinde bireysel kilometre taşlarını karşılamaya dikkat etmektir.
Brooks ayrıca, özellik şişkinliğinden kaçınabilen ve zamanlarını alabilen, yakından yönetilen küçük yazılım ekipleri fikrini de destekledi.
Ne de olsa Brooks, “iyi yemek gibi iyi bir yazılımın üretilmesi zaman alır” demişti.
Şimdi bazı insanlar açık kaynağın bunu çürüttüğünü söyleyebilir. Açık kaynaklı manifestoda Katedral ve ÇarşıBrooks, bir “katedral” tarzını savundu. Buna karşılık, gevşek bir şekilde organize edilmiş Linux ve açık kaynak geliştiriciler, yazılım güncellemelerini erkenden ve sık sık çıkardılar.
Ama durum gerçekten böyle mi?
Linux’un nasıl geliştirildiğine daha yakından bakarsanız, birçok geliştirici göreceksiniz. Ancak Linus Torvalds liderliğindeki çok daha küçük bir bakıcı grubu tarafından yönetiliyorlar. Kod eklemelerinin kendisi birçok küçük değişiklikten oluşur.
Rust’ı Linux’a veya WireGuard VPN’e eklemek gibi önemli değişikliklerin gerçekleşmesi yıllar alır.
Orta çağda çarşıların genellikle katedral arazilerinde kurulduğunu belirtmekte fayda var.
Brooks ayrıca gümüş mermilere karşı dikkatli olmamız gerektiği konusunda da bizi uyardı.
“Ne teknolojide ne de yönetim tekniğinde, on yıl içinde verimlilikte, güvenilirlikte ve basitlikte tek bir büyüklük sırası bile vaat eden tek bir gelişme yoktur.” Kısacası, ekibinizden biri size en son içgörülerini, keşiflerini veya icatlarını vaat ederse “Dünyayı Değiştirecek!” onlara inanma.
Elbette dünyayı değiştiren gelişmeler var.
Son zamanlarda bulut bilgi işlem, Docker/konteynerler ve uç bilgi işlem akla geldi. Ancak bunların hiçbiri düşündüğünüz kadar çabuk olmadı.
Hepsinin olgunlaşması ve önemli hale gelmesi yıllar aldı. derken Docker’ın görünüşte ani başarısı sizi şaşırtmış olabilir, konteyner teknolojisi 2000 yılına ve FreeBSD Hapishanelerine dayanmaktadır.
Son olarak, günümüzün en önemli geliştirme trendi olan DevOps da Brooks’un çalışmasına çok şey borçludur.
Herkesin bir proje üzerinde iletişim kurmasına büyük bir inancı vardı. (Yazılım sorunlarına daha fazla çalışma saati harcayarak çözmeyi imkansız kılan şey, etkili iletişim ihtiyacıdır.)
Doğru, artık bunu genellikle Git’te ve CI/CD araçlarıyla yapıyoruz, ancak iletişim, 60’ların başında yapıldığı gibi, başarılı programlama ve iş projeleri için hayati önem taşıyor.
Ve Brooks’un amacı başarılı olmaktı.
Telif hakkı © 2022 IDG Communications, Inc.