- Yalnızca yazılıma özgü olduğu düşünülen gereksinim değişiklikleri ve belirsizlik, yinelemeli işler ve geçici çözümler geleneksel mühendislikte de yaygındır; iki alanın farklarından çok ortak yönleri vardır
- Geleneksel mühendislik Waterfall, yazılım ise Agile’dır şeklindeki ayrım aşırı basittir. Fiziksel üretimde yineleme maliyeti yüksek olduğu için ön tasarım daha fazladır, ancak tünel, inşaat ve elektronik alanları da kademeli geliştirme ve sahada uyarlama kullanır
- Tedarikçilerin kapanması, üretim ekipmanlarının değişmesi, beklenmedik toprak özellikleri gibi geleneksel mühendislik de planları altüst eden sorunlar yaşar; bu yüzden yalnızca yazılımın özellikle öngörülemez olduğunu söylemek zordur
- Asıl fark, yazılımın yüksek tutarlılığı ve hızlı değiştirilebilirliği ile görece esnek kısıtlarındadır. Fiziksel ürünler malzeme sapmaları ve aşınmayı, dayanım ve boyut gibi sert kısıtları, geri alınması zor değişiklikleri kabullenmek zorundadır
- Hızlı düzeltme, deney ve doğrulamayı kolaylaştırır; ancak fiziksel kusurları kodla etrafından dolanarak çözme baskısı da yaratabilir. Her mühendislik alanı diğerlerinin tasarım, doğrulama ve otomasyon yöntemlerinden öğrenebilir
Yazılımın özel olduğuna dair savunma mantığı
- Petrol rezervuarı, yağla dolu bir balon değil gözenekli kaya yapısıdır; bu yüzden ani basınç kaybının yerel bir boşluktan mı, yoksa denize açılan bir delikten mi kaynaklandığını anlamak zordur
- Küçük boşluklara fındık kabukları enjekte edilerek yavaşça doldurulur, basınç dengelenir ve yapının içinde kalınıp kalınmadığı test edilir
- Norveç’te petrol şirketlerinin fındık kabuklarının en büyük alıcıları olması örneği, geleneksel mühendisliğin de beklenmedik malzemelere ve saha müdahalelerine dayandığını gösterir
- Yazılım ile geleneksel mühendislik karşılaştırılırken, lisanslama veya titizlik farkları nedeniyle yazılım mühendislikten daha düşük görülürken aynı zamanda yazılım, genel mühendislik çerçevesiyle anlaşılamayacak özel bir alan hâline de getiriliyor
- Gereksinimler olağanüstü hızlı değiştiği için önceden planlama ve mühendislik yöntemleri uygulanmasa da olur argümanı bir savunma mekanizması olarak işler
- NoEstimates hareketi, geleneksel mühendislikten farklı olarak yazılım tahmininin zor olduğu gerekçesiyle tahminin kendisini ortadan kaldırmaya çalışır
- Ancak yazılımda acı verici görülen sorunların çoğu diğer mühendislik alanlarında da vardır; iki tarafı da deneyimlemiş mühendisler bu iki işin özünün birbirine yakın olduğunu düşünür
Sık dile getirilen beş fark
- Geleneksel mühendisliğin tamamını tek bir alan gibi ele almak veya inşaat mühendisliğiyle özdeşleştirmek, alt alanlar arasındaki farkları görünmez kılar
- Yazılım ile geleneksel mühendislik arasındaki evrensel farklar olarak sıkça sayılanlar şunlardır
- Geleneksel mühendislik Waterfall’a, yazılım ise Agile’a uygundur
- Geleneksel mühendislik öngörülebilirdir, yazılım ise öngörmesi zordur
- Mühendislik esas olarak üretimdir, kod ise tasarımdır; dolayısıyla “kod tasarımın kendisidir”
- Geleneksel mühendislik, yazılım mühendisliğinden daha titizdir
- Yazılım, geleneksel mühendislikten çok daha hızlı hareket eder
- Bunların bazılarında gerçek farklar olsa da çoğu yanlıştır veya yargı için gereken kritik bağlam eksiktir
Waterfall ve Agile şeklindeki basit ayrım
- Yaygın anlatıya göre Winston Royce 1970’te mimari süreci örnek alarak Waterfall’u oluşturdu; gereksinim değişikliklerine kırılgan olan bu yöntem 2001’de Agile Manifesto ile yer değiştirdi
- Gerçekte Waterfall, bugünkü algılandığı kadar katı veya yaygın değildi
- 1970’ler ve 1980’lerde geliştiriciler geçici planlar ya da Spiral Model, V Model gibi çeşitli kademeli modeller kullanıyordu
- Agile, kopuş niteliğinde bir devrimden çok, o dönemdeki akışın doğal bir sonucu gibidir
- Geleneksel mühendisliğin daha fazla ön tasarım ve ayrı test süresi kullandığı doğrudur; ancak bu, Waterfall’un katılığından çok yineleme maliyetinin ekonomisinden kaynaklanır
- Yineleme ne kadar çok zaman ve para gerektirirse, tek bir işi daha uzun planlamak o kadar mantıklı olur
- Bir devre kartı ilk seferde çalışmazsa fabrikaya geri gönderilmesi gerekir; bu da binlerce sterlin ve 2 haftalık takvim ekleyebilir
- Tasarım ile uygulama arasındaki sınır da net değildir
- İnşaat mühendisinin ölçekli modeli veya otomotiv mühendisinin estetik ve aerodinamiği test etmek için yaptığı kil gerçek boyutlu model, hem tasarım hem de uygulama olarak görülebilir
- Diğer sektörlerde de Agile’a benzer yöntemler vardır
- Yeni Avusturya Tünel Açma Yöntemi yinelemeli geliştirmeye ve sahada doğaçlama müdahaleye dayanır
- Handbook of Industrial Engineering, departmanlar arası işbirliğini ve hızlı müşteri geri bildirimini vurgular
- İnşaat mühendisliği de yapım başladıktan sonra saha sorunlarını çözmek için açık iletişim ve uyarlama odağına kayar
Geleneksel mühendisliği de öngörmek zordur
- Tamamlanmış bir köprüye veya ürüne bakınca süreçte yaşanan sürtünmeyi, maliyet aşımını ve gecikmeleri kaçırmak kolaydır
- Bir duvarın 1 inç yanlış örülmesi veya kritik bir tedarikçinin kapanması bile planları sarsabilir
- Yazılımda baskın framework veya dil her 1-2 yılda bir değişiyor gibi görünebilir; ancak geleneksel mühendislik de araçlarda ve üretim ortamında değişim yaşar
- Bir yarı iletken foundry’si yeni üretim ekipmanı kullanmaya başlarsa çip tasarım planları da değişir
- Bu, kütüphaneler kadar hızlı olmasa da değişim olmadığı anlamına gelmez
- İnşaat sırasında egemenliğin değişmesi, doğrulanmış bir prosedürün aniden kalıcı biçimde başarısız olması veya geliştirme sürecinin sonlarına doğru yeni bir gerçeğin keşfedilmesi de yaşanabilir
- Köprü temeli çalışmalarına başladıktan sonra belirli bir toprağın beklenenden farklı donduğunu ve deprem sırasında aşırı sıvılaştığını keşfederseniz tasarımdan başlayarak yeniden başlamak gerekir
- Yalnızca yazılımın özellikle öngörülemez olduğu düşüncesi, diğer mühendislik alanlarının gerçek çalışma süreçlerini görmemekten kaynaklanır
“Kod tasarımın kendisidir” iddiası
- “Kod tasarımın kendisidir”, UML ile kusursuz bir model oluşturup ardından kodu otomatik üretmenin yeterli olduğu düşüncesine tepkiydi
- CPython çekirdek geliştiricisi ve eski Boeing sistem entegrasyon mühendisi Nick Coghlan, bunu yazılım ile önceki işi arasındaki temel fark olarak görür
- Uçak, hava trafik kontrolü, anten dizileri gibi bağımsız birçok sistem ekibinin uyumlu arayüzler oluşturmasını koordine ediyordu
- Bir yarı iletken mühendisi için CPU’nun ilk devre şemasından foundry’den çıkan nihai çipe kadar tüm süreç tasarımdır; üretim ise tasarımı teslim edip çipi almak olan görece kolay bir aşama olabilir
- Tamamlanmış bir çipte veya mekanik üründe kusur varsa tasarım değiştirilmelidir; bu nedenle tasarım ve üretim birbirinden ayrılmaz
- Makine mühendisliğindeki “fettling”, üretim sürecindeki küçük kusurlara uyacak şekilde tasarımı ayarlama işidir
- Üretimin tasarımı değiştirdiği, değişen tasarımın da yeniden üretimi değiştirdiği bir döngü oluşur
- Tasarımın kapsamı da belirsizdir
- Mimari özet, biçimsel şartname, ayrıntılı çizimler farklı düzeylerde tasarımdır
- Köprü tasarım çizimi gibi karmaşık projelerde birçok katmanda yinelenen ayrıntılar bulunur
- Yapıma en çok zaman ve para harcanması, köprü ve bina merkezli bazı inşaat mühendisliği işleri için geçerlidir; bunu tüm geleneksel mühendisliğin temsili görüntüsü olarak genellemek mümkün değildir
- İnşaat mühendisliği de şehir inşası için gereken çeşitli alanları kapsar; bu yüzden yalnızca köprü ve binalarla sınırlı değildir
Titizlik hakkındaki yanlış anlama
- Geleneksel mühendislik ilk ilkelerden başlayarak dikkatli akıl yürütürken yazılımın kopyala-yapıştırmaya dayandığı ayrımı gerçek işi yansıtmaz
- Yazılımın görece düşük görünen titizliği yalnızca kültürel bir mesele değil, uygulama ve testin kolay olduğu malzeme özelliklerinden doğan mantıklı bir ödün olabilir
- Bir varsayımı doğrulamanın en kolay yolu çoğu zaman doğrudan uygulayıp çalıştırmaktır
- Deneysel bilgiyi hızla toplama eyleminin kendisi de titiz bir doğrulama yöntemidir
- Geleneksel mühendislik ürünlerinin yazılımdan daha tutarlı ve sistematik olduğu varsayımı da doğru değildir
- Yazılım, kayıtların korunması ve kapsamlı doğrulama konularında kimi zaman daha ileridedir
- Geleneksel mühendislikte kritik bilgilerin Excel dosyalarında veya eski evrak dolaplarında saklanıp eskidiği ya da zarar gördüğü örnekler de çoktur
- Yazılımda doğal karşılanan otomatik testleri devreye almak isteyen birçok geleneksel mühendislik mühendisi de vardır
- Fiziksel yapılarda da gerektiğinde braket eklemek gibi geçici çözümler sürekli kullanılır
Gerçek fark 1: Tutarlılık
- Yazılım tamamen mantıktan sentezlenir ve yay gibi aşınmadığı için diğer mühendislik çıktılarından çok daha tutarlıdır
- Bir sıralama fonksiyonu, anormal girdi olmayan sayı listelerini yalnızca %95 oranında sıralıyorsa bunu normal davranış olarak kabul etmek zordur
- Fiziksel malzemelerde ve parçalarda teorik değerlerden sapmalar varsayılan olarak vardır
- Dirençler 1Ω’dan yüz milyonlarca Ω’a kadar sunulur ve renk bantları teorik direnç değerini gösterir
- Yeşil, mavi ve kırmızı bantlar 5.600Ω anlamına gelir; ancak altın tolerans bandı varsa gerçek değer en fazla %5 farklı olabilir
- Aynı dirençten 100 adet içinde bazıları 5.320Ω, bazıları 5.880Ω olabilir; bu yüzden her biri ölçülmelidir
- Aşınma ve sıcaklık değişimi de dikkate alındığında sapma daha karmaşık hâle gelir
- Tüm fiziksel malzemelerde benzer sorunlar vardır; vida üreticisi Fastenal da paslanmaz çelik vidaların alüminyum levhalarda kullanılmaması konusunda uyarır
Gerçek fark 2: Değişim hızı
- Yazılım, diğer mühendislik sistemlerinden çok daha hızlı değiştirilebilir
- Geleneksel mühendislikte şartname paylaşıldıktan sonra fabrikanın veya makine atölyesinin üretimini ve kurulumunu, ardından haftalar süren testleri beklemek gerekir
- Bazı mühendislik değişikliklerinde her seferinde bütçeden 5.000 dolar eksilmesi gibi maliyet nettir
- Kod değiştirildikten sonra tüm testler saniyeler içinde çalıştırılabilir
- Yazılım dışı alanlar içinde kimya mühendisliği hıza en yakın olanıydı; ancak 1 dakikalık geçişler bile hayal edilmesi zor düzeydedir
- Diğer mühendislik alanlarının tasarım araçlarında ve simülasyonda daha fazla yazılım kullanmasının nedeni de fikirleri uygulamadan önce hızla prototipleştirebilmeleridir
- Hızlı değiştirme yeteneğinin olumsuz yönleri de vardır
- Elektronik veya mekanik bir cihazın sorunu tam çözülmezse yazılım mühendisleri üzerinde bunu kodla geçici olarak aşmaları yönünde baskı yoğunlaşır
- Bu bağımlılık ölümcül sonuçlara yol açabilir
- 2019’daki iki Boeing 737 MAX kazasında 300’den fazla kişi öldü
- Soruşturmalarda neden olarak otomatik uçuş kontrol sistemi MCAS’teki hata gösterildi
- Boeing, sonradan keşfettiği uçağın aerodinamik özellikleriyle ilgili sorunu fiziksel tasarımla düzeltmek yerine MCAS’i ekledi
Gerçek fark 3: Kısıtlar ve geri alınamaz değişiklikler
- Geleneksel mühendislik ürünleri ağırlık, dayanım, direnç, sıcaklık gibi mutlaka uyulması gereken fiziksel sınırlara sahiptir
- Çip tasarımında, nanosaniyenin kesirlerine karşılık gelen zaman payları bile diğer ekiplerle müzakere edilebilir
- Yazılımda da bellek kapasitesi, sensörün 10 döngülük yanıtı, API çağrı limitleri gibi kısıtlar vardır
- Ancak yazılım kısıtları çoğu zaman aşıldıkça durumun kötüleştiği yumuşak kısıtlardır; geliştirme hızı veya basit algoritmalar uğruna sınırlar biraz ayarlanabilir
- Geleneksel mühendisliğin kısıtları çoğu zaman aşılırsa ürünün çalışmadığı sert kısıtlardır
- Bir kutunun genişliği biraz fazla olsa bile kapıdan geçemez
- Petrol sondaj tesisine kurulacak bir vidalı konveyörün odadan birkaç inç daha yüksek olduğu örnekte, ekipmanı küçültmek ya da üstteki dört kat nedeniyle tavanı yükseltmek mümkün değildi
- Tavanda delik açılarak ekipman içeri alındı; üst kattaki insanların takılıp düşmemesi için deliğin çevresine bir kutu yerleştirildi
- Bu değişiklik tesis yapısında kalıcı olarak kaldı ve sonraki tüm değişikliklerde dikkate alınması gerekti
- Yazılım mühendisleri geçici çözümleri geri alabilir; ancak geleneksel mühendislikte fiziksel geçici çözümler kolayca kalıcı yapılar hâline gelir
Farklı, ama özel değil
- Yazılımın kendine özgü güvenlik sorunları vardır; ancak inşaat mühendisliğinde hava koşulları, kimya mühendisliğinde kimyasal özellikler gibi her alanda ayrı zorluklar bulunur
- Tüm mühendislik alanları önceden soyut düşünmeyi, düzenli çalışmayı ve uygun geçici çözümleri önemser; değişen gereksinimler ve bilinmeyen belirsizliklerle karşılaşır
- Alanlar birbirinden yalıtık olduğu için yazılım mühendisinin makine mühendisliğini bilmemesi kadar, kimya mühendisliği mühendisi de diğer mühendisliklerin gerçek işlerini bilmekte zorlanır
- Yazılım özel olmadığı için diğer mühendislik alanlarından iyileştirme yolları öğrenebilir; kayıt, doğrulama ve otomasyon gibi konularda geleneksel mühendisliğin yazılımdan öğrenebileceği noktalar da vardır
- Devam yazısı Mühendisliğin bize öğretebilecekleri ve bizden öğrenebilecekleri, iki tarafın değiş tokuş edebileceği somut dersleri ele alır
1 yorum
Lobste.rs yorumları
Yazının büyük kısmına katılsam da, yazılım mühendisliğinin titizliği konusunda aşırı iyimser. Bugün bile otomatik testlerin, özellikle de birden çok katmanda sağlam testlerin geliştirme sürecine dahil edilmesi olağan bir şey değil; geliştiricinin kendisini tek kontrol noktası olarak gördüğü ya da kuruluşların süreçleri engel sayıp ortadan kaldırdığı da oluyor.
Sektör, kanıtlanmış en iyi uygulamaları sistematik hale getirmeden birkaç yılda bir tekerleği yeniden icat ediyor. Standartlaşmış olanlar da çoğunlukla şirketten şirkete anlamı büyük ölçüde değişen gevşek bir ortak sözlükten ibaret; “çevik” ya da “test” bunun tipik örnekleri. Birçok geliştirici testi yalnızca birim testi düzeyinde düşünürken, bazıları bileşen ve entegrasyon testlerini de dahil ediyor; ancak kimi şirketlerde yalnızca bunlardan geçtikten sonra üretim ortamına dağıtım yapılıyor.
Daha önce yazdığım yorumda olduğu gibi, sağlıklı bir kuruluşta kod incelemesi kaliteyi güvence altına alan birden fazla süreçten biri olmalı; üretime dağıtıma karar veren tek kapı olmamalıdır. Kod birleştirmeden sonraki kalite güvence süreçlerinin fiilen ortadan kalktığı çok sayıda ekip ve şirket var.
Burada amaç sorumluluğu sulandırmak değil; daha kod yazılmadan önce kaliteyi sürece içkin hale getirmek. Birden fazla rolün spesifikasyonları ve gereksinimleri tartıştığı Three Amigos oturumları, test güdümlü geliştirme, IDE’ye ve her kontrol aşamasına entegre statik analiz, geliştiricilerden ayrı kalite güvence ve test otomasyonu uzmanları gibi şeylere ihtiyaç var.
İnşaat mühendisliğinde tek bir kişi bir köprünün hem tasarımcısı, hem yapımcısı, hem de tek sorumlusu olmaz. Hesaplama ve dokümantasyon, yeniden hesaplama, devlet onayı, inşaat sırasında denetim ve inceleme gibi birden çok aşama vardır; müstakil evler bile çizim, onay, ruhsat ve denetim süreçlerinden geçer. Mühendislik felaketleri de çoğu zaman birden fazla aşamada önlenememiş tüm sürecin başarısızlığıdır.
Yazılım geliştirmeyi inşaat mühendisliğiyle karşılaştıracaksak, süreç seviyesinin hiç de aynı olmadığını da kabul etmeliyiz. Çoğu durumda olsa olsa yasal gerekliliklerin etrafından dolaşıp en ucuz evi yapan konut geliştiricilerine benziyoruz.
Bu yüzden MRI kontrol yazılımı gibi alanlar dışında kalan genel yazılımlarda, test ve doğrulama maliyeti ile bunun etkisi arasındaki denge noktası inşaat mühendisliğinden kaçınılmaz olarak farklıdır.
Üçü de çok iyi, okumanızı öneririm. Geçmiş tartışmalara da birlikte bakılabilir:
https://lobste.rs/s/fv8swh/crossover_project (proje duyurusu)
https://lobste.rs/s/lmvroa/are_we_really_engineers (yeniden tartışma)
https://lobste.rs/s/8j8sdc/are_we_really_engineers (bir başka yeniden tartışma)
Glenn Vanderburg’ün bu konuşması da konuyla çok yakından ilgili.
Yazılım geliştirme ile geleneksel mühendislik arasındaki en büyük fark, değişikliğin yarattığı sürtünmedir. Yazılım görece düşük maliyetle değiştirilebilir ve esnektir; bu da tamamen yeni olasılıkların önünü açar.
Geleneksel mühendislik de daha fazla simülasyon ürettikçe, fiziksel ve kimyasal sınırlar içinde yazılıma benzer biçimde değiştirilebilirliği genişletebilir.
“Bir sıralama fonksiyonuysa, patolojik olmayan sayı listelerini yalnızca %95 olasılıkla sıralamasını beklemeyiz” sözü artık LLM tarafından üretilen kod için gerçekten geçerli. Çoğu zaman çalışır, ama her zaman çalışmaz.
~hwayne’in hesabını neden devre dışı bıraktığını merak ediyorum.