“10x mühendis:” 50 yıl önce ve şimdi
Frederick P. Brooks, Jr. tarafından yazılan 'The Mythical Man Month' yazılım sektöründe gerçek bir klasiktir. İlk olarak 1975 yılında yayınlanan ve 1995 yılında güncellenmiş bir baskısı yapılan metin neredeyse 50 yaşında. Aradan çok zaman geçmesine rağmen kitap hala güncelliğini koruyor.
Kitabın başlığı, yazılım geliştirmenin “adam ayları” ile ölçülebileceği “efsanesini” hedef alıyor ve Brooks bunu takip eden sayfalarda bunu çürütüyor:
“[Yazılım projesinin] maliyeti gerçekten de adam sayısı ve ay sayısının çarpımı olarak değişir. İlerleme ise değişmez. Dolayısıyla, bir işin büyüklüğünü ölçmek için kullanılan bir birim olarak adam-ay tehlikeli ve aldatıcı bir efsanedir.”
Yazılımın ilk günlerinden itibaren bu kitabı gözden geçiriyor ve Efsanevi Adam Ayı'nın yayınlanmasından bu yana geçen 50 yılda nelerin aynı kaldığını, kitabın hangi öngörüleri doğru ya da yanlış bulduğunu ve bugün mühendislikte nelerin farklı olduğunu not alıyorum.
3. Bölüm “Cerrahi Ekip” başlığını taşıyor ve “10x mühendis” kavramından belki de ilk bahsedenlerden birini içeriyor. Brooks bunu şu şekilde ifade ediyor:
“Programlama yöneticileri uzun zamandır iyi programcılar ile kötü programcılar arasında büyük verimlilik farklılıkları olduğunu fark etmişlerdir. (...) Çalışmalarından birinde Sacknman, Erikson ve Grant bir grup deneyimli programcının performanslarını ölçüyorlardı. Sadece bu grup içinde en iyi ve en kötü performanslar arasındaki oranlar verimlilik ölçümlerinde ortalama 10:1, program ve hız alanı ölçümlerinde ise inanılmaz bir şekilde 5:1'dir! Kısacası, 20.000 $/yıl programcı [2024 şartlarında: 120 bin $], 10.000 $/yıl programcıdan [2024 rakamlarıyla: 60 bin $] 10 kat daha üretken olabilir.”
Brooks bu gözleme katılıyor ve radikal bir çözüm öneriyor: mümkün olduğunca az sayıda kıdemli programcıya sahip olun ve her birinin etrafında bir ekip oluşturun - tıpkı bir hastane cerrahının tüm bir ekibi yönetmesi gibi. Brooks, Harlan Mills'ten ödünç aldığı aşağıdaki yapının işe yarayabileceğini öne sürüyor:
Baş programcı. Brooks bu kişiye “cerrah” diyor. Şartnameyi yazar, kodu yazar, test eder ve dokümantasyonu hazırlar. 10 yıldan fazla deneyime ve geliştirme, matematik, işletme ve ihtiyaç duyulan diğer her konuda geniş bir uzmanlık yelpazesine sahiptir.
Yardımcı pilot. “Cerrahın alter egosu, işin herhangi bir kısmını yapabilir, ancak daha az deneyimlidir.” Bu biraz küçük bir çift programlama ortağı gibidir.
Dil avukatı. "Çoğu bilgisayar kuruluşunda bir programlama dilinin inceliklerine hakim olmaktan zevk alan bir ya da iki kişi vardır. Bu uzmanlar çok yararlı olurlar ve kendilerine çok danışılır." Bu rol, baş programcının genellikle bir programlama dili üzerinde derinlemesine çalışacak zamanı olmayacağı ve bu konuda bir uzmana güveneceği anlamına gelir. Çok ilginç bir ekleme!
Alet ustası. Programcı ve yardımcı pilotun işlerini daha iyi yapabilmeleri için geliştirici araçlarının oluşturulması ve bakımından sorumludur; örneğin editörlerin geliştirilmesi, daha iyi hata ayıklama işlevlerinin oluşturulması, yardımcı araçların ve makroların oluşturulması vb.
Test uzmanı. Test senaryoları ve verileri oluştururlar. Ayrıca testlerin iskelesinden de sorumludur.
Program memuru. “Ekibin teknik kayıtlarının bir programlama-ürün kütüphanesinde tutulmasından sorumludur, hem makine tarafından okunabilir hem de insanlar tarafından okunabilir dosyalardan sorumludur.”
Yönetici. Maaş bordrosu, ofis kiralama, bilgisayar satın alma vb. işlerden sorumludur.
Editör. Baş programcının yazdığı belgeleri düzenler ve üretime hazır hale getirir.
İki sekreter. “Yönetici ve editörün birer sekretere ihtiyacı olacak; yöneticinin sekreteri proje yazışmaları ve ürün dışı dosyalarla ilgilenecek.”
İşte çok üretken bir programcının etrafında kurulan bu “cerrahi ekip” böyle görünüyor:
Bana kalırsa bu ekip kurulumu hedefe yönelikti. Roller o zamanlar kesinlikle mantıklıydı, ancak herhangi bir iş lideri neden bir geliştiriciyi desteklemek için 9 kişiyi daha işe almak için imza atsın ki? 1975 yılında cevabın çok az olduğunu varsayıyorum.
2024'te Brooks'un önerdiği rollerin çoğuna gerek kalmadı ve “cerrahi ekip” araçlardaki ve çalışma şeklimizdeki gelişmeler sayesinde dönüştü:
Aletlerin 50 yıl içinde ne kadar geliştiği büyüleyici. 1975'te var olmayan ya da 1995'te yaygın olmayan araçlar ve yaklaşımlar şunlardır:
Git - video oyunları gibi çok büyük varlıklara sahip projeler için istisnalar dışında, endüstrinin çoğu tarafından kullanılan şu anda baskın sürüm kontrol sistemi
Kod incelemeleri: bunlar sürüm kontrolüne paralel olarak yaygınlaştı. Kod incelemeleri, bir görev üzerinde çalışırken eşleşme ihtiyacını azaltarak mühendislerin değişiklikleri takip etmesine ve birbirlerinden öğrenmesine olanak tanır.
CI/CD: tüm değişiklikler üzerinde otomatik testlerin çalıştırılması ve kodun otomatik olarak üretime dağıtılması.
Rollout ve rollback mekanizmaları. Brooks, yazılımı internet öncesi işletim sistemleri üretme bağlamında ele alıyor. İşletim sistemleri ve gömülü yazılımlar oluşturmak hala zor olsa da internet üzerinden yazılım güncellemeleri yaygındır ve hata düzeltmeleri daha sonra teslim edilebilir. Otomobiller buna iyi bir örnektir; modern araçların çoğu düzenli olarak donanım yazılımlarını ve işletim sistemlerini “havadan” yenilemektedir!
Dilleri ve çerçeveleri edinmek daha kolaydır. Günümüzde yeni bir dile başlamayı çok daha kolay hale getiren sayısız çevrimiçi kaynak, kum havuzları ve otomatik tamamlama ve derleme zamanı hataları için satır içi sinyalizasyon gibi gelişmiş IDE işlevleri bulunmaktadır. Güncel olarak, şu anda yapay zeka kodlama araçlarının üretkenlik üzerindeki etkisini keşfediyoruz.
Progress, eskiden bir lider geliştiriciyi destekleyen 10 kişilik bir ekibi, bir dizi araca ve daha büyük şirketlerde birkaç merkezi platform ekibine dönüştürdü.
“Hiyerarşik programlama” kavramının modası geçmiş gibi geliyor. Brooks'un modelinde dikkatimi çeken bir şey de hiyerarşik olması. “Baş programcı” bir mimar gibi hareket eder ve tüm planlamayı, çoğu yön belirlemeyi ve bazı kodlamaları yaparken, diğer herkes iyi tanımlanmış, destekleyici rollerde çalışır. Yardımcı pilot şöyle tanımlanıyor:
“tüm kodu yakından bilir. [Alternatif tasarım stratejilerini araştırırlar. [Açıkçası cerrah için felakete karşı bir sigorta görevi görürler. [Hatta kod yazabilirler ama kodun hiçbir kısmından sorumlu değildirler.”
Makine zamanı pahalı olduğu için bilgisayarlara erişimin daha kısıtlı olduğu zamanlarda bu düzen anlamlıydı, ancak bugün, üretim kodunu yazan giriş seviyesinde bir mühendisin bile olmaması savurganlık olurdu. O zamanlar kötü yazılmış kodların üretime geçmesini engellemek için kaynak kod kontrolü ve kod incelemeleri yoktu.
Bu, araçların bir ekibin sosyal dinamiklerini değiştirdiğini hatırlatan iyi bir örnek. Daha iyi araçlar sayesinde bugünlerde aşırı hiyerarşik ekip yapılarını reddedebiliyoruz.
Brooks'un “alet ustası” kavramı hala geçerli ama farklı. Daha iyi hata ayıklama araçları ve yardımcı programları oluşturmak için özel bir geliştiricinin rolü ve ayrıca buna yapılan bir ekleme ilgimi çekti:
“Merkezi olarak sağlanan herhangi bir hizmetin mükemmelliği ve güvenilirliği ne olursa olsun, her ekibin kendi alet ustasına ihtiyacı olacaktır. Onların görevi, başka herhangi bir ekibin ihtiyaçlarına bakmaksızın cerrahın ihtiyaç duyduğu veya istediği araçları görmektir.”
Brooks, bugün platform ekibi olarak adlandırdığımız merkezi bir alet ekibi olsa bile, ekibe özel bir alet uzmanının hala çok değerli olduğuna inanıyordu. Ancak araçlar, geliştirici ortamları, derleme araçları ve daha fazlası ayrıntılı şekillerde yapılandırılabildiği için bu ihtiyaç neredeyse tamamen ortadan kalktı.
Bir şirketteki tüm ekipler aynı CI/CD araçlarını kullanır, ancak yapılandırmaları biraz değiştirebilirler.
Bir mühendislik ekibi içinde, genellikle derleme sistemlerini ve paylaşılan ortamları diğerlerinden daha fazla değiştirmekten hoşlanan bir veya iki mühendis olduğu doğrudur. Ancak merkezi platform/altyapı ekiplerinde “gömülü” bir platform mühendisine ihtiyaç yoktur. Bu, kitabın çıkmasından bu yana geçen 50 yılda geliştirici araçlarının ne kadar geliştiğiyle ilgilidir.
“10x mühendisi” her zaman bir tartışma ve çekişme kaynağı olmuştur. Hepimiz diğerlerinden çok daha üretken görünen geliştiriciler görmüşüzdür. CTO'lar ve CEO'lar da bunu fark eder ve bazıları öne çıkan kişileri “10x geliştirici” olarak etiketler.
Bununla birlikte, çok fazla nüans vardır:
İşleri hızlı bir şekilde inşa eden bir geliştirici, bunu daha sonra birçok geliştiricinin değiştirmek için mücadele edeceği, bakımı mümkün olmayan kod yazarak yapabilir
“10x geliştirici”, bilgi biriktiren ve başkalarının kurdukları belirsiz sistemleri anlamasına izin vermeyi reddettiği için etkili olan biri olabilir
“10x geliştirici”, yüksek iş hacmine sahip bir işyerinde uzun süre çalıştığından çok daha üretken olabilir
Bir başka “10x geliştirici”, iyi bir iş anlayışına sahip, en kârlı projeler üzerinde çalışan ve diğer işlerden kaçınan biri olabilir
Başka bir “10 kat geliştirici” de, daha büyük bir ekip tarafından yapılan ve tamamladıkları iş için kredi almakta çok iyi olabilir
Bunun nereye varacağını görüyorsunuz. “10x geliştirici” davranışı aslında farklı bir etiket altında tespit edilmemiş toksik davranış olabilir. Bu arada, diğerleri tekrarlanamayan belirli bir bağlamın avantajına sahip olabilir. Bu kesinlikle karmaşık bir konu ve sektör genelinde 50 yılı aşkın bir süredir üzerinde düşünmeyi ve tartışmayı bırakmadığımız bir konu.
Bu yazı The “10x engineer:" 50 years ago and now başlıklı yazıdan çevrilmiştir.