- Uzay aracı tasarımı ve mühendislik projelerine uygulanan 40 pratik ilkeyi derleyen slaytlar
- Temel ilkeler olarak sayısal analiz, iteratif tasarım ve hata toleranslı tasarım vurgulanıyor
- Takvimin yalnızca tek yönde ilerlediği ve ilk tahminlerin her zaman eksik hesaplandığına dair gerçekçi bir uyarı içeriyor
- Uzay mühendisliğinin ötesinde yazılım, sistem ve startup tasarımının geneline doğrudan uygulanabilir
- Mühendislik yargısında tekrar tekrar ortaya çıkan hataları önlemeye yardımcı olan gerçekçi bir kontrol listesi
Yasa 1 — Sayılarla kanıtlanan mühendislik
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- Mühendislik sayılarla yapılır; sayılar olmadan yapılan analiz yalnızca bir görüştür
- Mühendislik öğrencilerinin matematik öğrenmeye neden bu kadar çok zaman ayırdığının sebebi
- Mühendislikte başarı nicel olarak ölçülebilir olmalıdır
- "Benim sistemim daha hızlı" → ne kadar daha hızlı?
- "Benim sistemim daha ucuz" → maliyeti ne kadar?
- "Benim sistemim daha basit" → basitlik nasıl ölçülür?
Yasa 2 — Hata toleranslı tasarım
- "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
- Bir uzay aracını kusursuz tasarlamak sonsuz çaba gerektirir; bu yüzden bazı şeyler ters gitse de çalışacak şekilde tasarlamak iyi bir fikirdir
- %100 güvenilirlik gerektiren sistem tasarımından kaçınılmalı
- Başarısızlık örnekleri: Deep Water Horizon, Fukushima
- Uçak kontrol sistemlerinde kullanılan üçlü mantık denetimi (3 way logic checking) yöntemine örnek
Yasa 3 — İteratif tasarım süreci
- "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
- Tasarım iteratif bir süreçtir ve gerekli iterasyon sayısı, şu ana kadar yaptığınız sayıdan her zaman bir fazladır
- İyi tasarım asla tamamlanmış olmaz
Yasa 4 — Hayal kırıklığıyla başa çıkmak
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- En iyi tasarım çabalarınızın sonunda nihai tasarımda işe yaramaz hale gelmesi kaçınılmazdır; bu hayal kırıklığıyla yaşamayı öğrenin
- Bhargava Yasası: 10 araştırma projesinden yalnızca 1'i endüstriyel uygulamaya geçer
- En büyük ticari başarı, en iyi teknik tasarım anlamına gelmez
- Örnek: Nokia N95 vs 1. nesil iPhone
Yasa 5 (Miller Yasası) — Üç nokta bir eğriyi belirler
- "Three points determine a curve."
- Üç nokta bir eğriyi belirler
- Veri setlerinde her zaman bir desen bulunur
- Bu desenin ölçüm gürültüsünden değil, araştırılan gerçek olgudan kaynaklanıp kaynaklanmadığı doğrulanmalı
- Akademi ve özellikle lisansüstü öğrencileri bu kuralı görmezden gelmeye yatkın
Yasa 6 (Mar Yasası) — Veriye aşırı uyum tuzağı
- "Everything is linear if plotted log-log with a fat magic marker."
- Log-log grafikte kalın bir keçeli kalemle çizildiğinde her şey doğrusal görünür
- Bigg Yasası: "Matematiksel araca aşık olma; o sana karşılık vermez"
- Veriye aşırı uyum (over-fit) yasak
Yasa 7 — Liderlik ve ekip kurma
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- Herhangi bir tasarım çalışmasının başında ekip lideri olmayı en çok isteyen kişinin, bunu yapabilecek yeterliliğe sahip olma ihtimali en düşüktür
- Dilbert çizgi romanı, gerçek mühendislik şirketi deneyimlerinin biraz abartılmış bir yansımasıdır
- Liderliğin bir kısmı doğuştandır, ancak önemli bir bölümü öğrenilmelidir
- Yöneticilerin bazen 'temellere saygı göstermediği (respect the basics)' durumlar olur
- Bir endüstri mühendisine MBA hakkında sorun
Yasa 8 — Optimum nokta ortalarda bir yerdedir
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- Doğada optimum nokta neredeyse her zaman ortalarda bir yerdedir; optimumun uç bir noktada olduğunu söyleyen iddialara şüpheyle yaklaşın
- Standart örnek: optimal güç aktarımı (Optimal power transfer)
- Uygulama örneği: optimal sensör direnci (optimal sensor resistance)
Yasa 9 — Bilgi eksikliği mazeret değildir
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- İhtiyacınız olan tüm bilgilere sahip olmamak, analize başlamamak için asla tatmin edici bir mazeret değildir
- Daha eksiksiz bir analiz için hangi değerlere ihtiyaç duyulduğu belirlenmelidir
Yasa 10 — Tahmin ve kestirim
- "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
- Şüphedeysen tahmin et; acil durumda kestir. Ama gerçek sayılar geldiğinde geri dönüp ortaya çıkan dağınıklığı mutlaka düzelt
- Mühendisler böyle yetiştirilir; falcı değilsiniz
- Bu meslekte hızlı düşünmekten çok iyi düşünmek daha önemlidir
Yasa 11 — Baştan başlamak
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- Bazen sona ulaşmanın en hızlı yolu her şeyi atıp yeniden başlamaktır
- Bunu ne zaman yapmanız gerektiğini öğrenmek zaman alır
- Pek çok sektörde bunun yapılması gereken ama yapılmayan çok sayıda örnek vardır
- Rus insanlı keşif uzay istasyonu Almaz: mükemmel bir teknik tasarımdı, ancak fırlatıldıktan sonra bilgisayar kontrollü keşif uyduları tarafından demode hale geldi
- İlk dönem 'otomobiller'
Yasa 12 — Tek bir doğru cevap yoktur
- "There is never a single right solution. There are always multiple wrong ones, though."
- Tek bir doğru çözüm hiçbir zaman yoktur; buna karşılık her zaman birden fazla yanlış çözüm vardır
- Açık fikirli olun
- Mühendislik bir din değildir
- Teknik sapkınlık (Technical apostasy) tamamen kabul edilebilir
- Örnek: mekanik otomatik hesaplama
- II. Dünya Savaşı'nda ana akım yaklaşımdı
- Dijital donanımın bu alana hakim olması 1960'lara kadar sürdü
Yasa 13 — Gereksinim temelli tasarım
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- Tasarım gereksinimlere dayanır; gereksinimlerin söylediğinden bir parça bile "daha iyi" bir şey tasarlamanın haklı bir gerekçesi yoktur
- Müşteriler ihtiyaç duymadıkları özellikler için ödeme yapmaktan hoşlanmaz
- Uygulamanın ihtiyaç duyduğu güvenilirlik düzeyi bulunmalı ve tasarım buna göre yapılmalıdır
- Söylemesi kolay, uygulaması zordur
Yasa 14 (Edison Yasası) — 'Daha iyi', 'iyi'nin düşmanıdır
- "'Daha iyisi', 'iyinin' düşmanıdır."
- 'Daha iyi', 'iyi'nin düşmanıdır
- Aslında Voltaire'e ait bir alıntıdır
- Sistemin yeterince iyi (good enough) bir duruma ulaştığını fark etmek gerekir
- Mükemmellik sonsuz kaynak gerektirdiğinden, bir sistem her zaman daha iyi hale getirilebilir
- Bkz. Yasa 13
Yasa 15 (Shea Yasası) — Arayüzler esastır
- "Bir tasarımı iyileştirme yeteneği esas olarak arayüzlerde ortaya çıkar. Burası aynı zamanda her şeyi mahvetmenin de başlıca yeridir."
- Tasarımı iyileştirme yeteneği çoğunlukla arayüzlerde ortaya çıkar; burası aynı zamanda işleri bozmanın da başlıca noktasıdır
- Tek bir sistemi gerçekten çok iyi anlayan çok sayıda mühendis/teknisyen vardır
- Birden fazla farklı sistemi gerçekten çok iyi anlayan kişiler nadirdir
- Örnek: karmaşık donanım ve yazılım etkileşimleri içeren sistemlerde sorunlar genelde arayüzlerde ortaya çıkar
Yasa 16 — Geçmiş analizlere körü körüne güvenmeyin
- "Daha önce benzer bir analiz yapan kişiler, çağların bilgeliğine doğrudan bağlı değildi. Bu nedenle onların analizine sizinkinden daha fazla inanmak için bir neden yoktur. Hele ki onların analizini kendi analizinizmiş gibi sunmak için hiç neden yoktur."
- Benzer bir analiz yapan önceki kişiler çağların bilgeliğine doğrudan bağlı değildi; bu yüzden onların analizine sizinkinden daha fazla güvenmek için bir neden yoktur ve özellikle onların analizini kendi analizinizmiş gibi sunmak için hiçbir neden yoktur
Yasa 17 — Yayınlardaki doğruluk
- "Bir analizin basılı olarak yer alması, onun doğru olma olasılığıyla hiçbir ilişki taşımaz."
- Bir analizin basılı bir yayında yer alması, doğru olma ihtimaliyle ilgisizdir
- 1970'lerden ünlü bir görüş:
- "1200 baud muhtemelen telefon modemlerinin ulaşabileceği en yüksek hız olacak"
- "Coding is dead" sözüyle bilinir
- Trellis coded modulation, 1990'lara kadar bu hızı 50kbps seviyesine çıkardı
Yasa 18 — Geçmiş deneyimin iki yüzü
- "Geçmiş deneyim, gerçeklik kontrolü sağlamak için mükemmeldir. Ancak fazla gerçeklik, aksi halde değerli olabilecek bir tasarımı mahvedebilir."
- Geçmiş deneyim gerçeklik kontrolü sağlamak açısından mükemmeldir; ancak fazla gerçeklik, aksi halde değerli olabilecek bir tasarımı mahvedebilir
Yasa 19 — Alçakgönüllülüğün önemi
- "Bu alandaki diğer herkesten çok daha zeki olma ihtimaliniz size karşı büyük ölçüde düşüktür. Analiziniz terminal hızınızın ışık hızının iki katı olduğunu söylüyorsa, warp drive'ı icat etmiş olabilirsiniz; ama büyük olasılıkla hata yapmışsınızdır."
- Bu alandaki diğer herkesten çok daha zeki olma olasılığınız çok düşüktür; analiziniz son hızınızın ışık hızının iki katı olduğunu söylüyorsa warp drive'ı icat etmiş olabilirsiniz ama çok daha büyük ihtimalle bir yerde hata yapmışsınızdır
Yasa 20 — Sunumun önemi
- "İyi bir sunumla desteklenen kötü bir tasarım eninde sonunda başarısızlığa mahkûmdur. Kötü bir sunumla desteklenen iyi bir tasarım ise anında başarısızlığa mahkûmdur."
- Kötü bir tasarım iyi bir sunumla eninde sonunda başarısız olur; iyi bir tasarım kötü bir sunumla ise hemen başarısız olur
- Örnek: Avro C102 — dünyanın ikinci ticari jet yolcu uçağı (13 gün farkla)
- Avro Arrow geliştirmesine destek olmak için iptal edildi
Yasa 21 — Eğitimin özü
- "Sınıfta duyduğunuz her şeyin yarısı saçmalıktır. Eğitim, hangi yarının hangisi olduğunu anlamaktır."
- Sınıfta duyduklarınızın yarısı işe yaramaz; eğitim, hangi yarının hangisi olduğunu çözmektir
- Profesörler kasıtlı olarak zamanın %50'sini boşa harcamaya çalışmaz
- Hızla değişen ve evrilen alanlarda hangi becerilerin gerekli olacağını tahmin etmeye çalışırlar
- Örnek: kuantum bilişim
- Önümüzdeki 20 yıl boyunca mühendis olarak çalışmak için vazgeçilmez bilgi de olabilir, 2030'lara kadar yalnızca akademik ilgi konusu da olabilir
Yasa 22 — Dokümantasyonun önemi
- "Şüphe duyduğunuzda dokümante edin. (Dokümantasyon gereksinimleri, bir programın sona ermesinden kısa süre sonra en yüksek seviyeye ulaşır.)"
- Şüphede kaldığınızda dokümante edin; dokümantasyon gereksinimleri bir program sona erdikten kısa süre sonra en yüksek seviyeye ulaşır
- Sorunu çözemiyorsanız cehaletinizi gizlemeyin
- Sorunun nedenini dokümante edin
- Başka biri sorunu çözmenin yolunu bulabilir
Yasa 23 — Takvimlerin kurmaca oluşu
- "Geliştirdiğiniz takvim, müşteriniz sizi ona uymadığınız için işten çıkarana kadar tam bir kurgu eseri gibi görünecektir."
- Hazırladığınız takvim, müşteri sizi ona uyamadığınız için kovana kadar tam bir kurgu gibi görünecektir
Yasa 24 — İş kırılım yapısı
- "Buna 'Work Breakdown Structure' denir; çünkü üzerine biraz Structure uygulamazsanız geriye kalan Work, siz bir Breakdown yaşayana kadar büyümeye devam eder."
- Buna 'Work Breakdown Structure' denir; çünkü bir yapı dayatmazsanız kalan iş, siz çökene kadar büyümeye devam eder
Yasa 25 (Bowden Yasası) — Test başarısızlığından sonra analiz
- "Bir test başarısızlığının ardından, baştan beri negatif marjlara sahip olduğunuzu gösterecek şekilde analizi rafine etmek her zaman mümkündür."
- Test başarısızlığından sonra, en başından beri negatif marjlar olduğunu gösterecek biçimde analizi ayrıntılandırmak her zaman mümkündür
- Örnek: Kanada Ulaşım Kazaları Araştırma Güvenlik Kurulu ve Federal Havacılık İdaresi (FAA) kaza raporları
- Bazı başarısızlıklar hayal gücü eksikliği nedeniyle meydana gelir (Frank Borman parafrazı)
- Mühendislerin hata yapması affedilir, ancak hataları gizlemesi affedilmez
Yasa 26 (Montemerlo Yasası) — Aptalca şeyler yapmayın
- "Aptalca bir şey yapma."
- Mühendislik pratiğinde şaşırtıcı derecede uyulması zor bir kuraldır
- Temelleri unutmayın
- Kendi önceliklerinizi netleştirin
Yasa 27 (Varsi Yasası) — Takvimler tek yönlü ilerler
- "Takvimler yalnızca tek yönde hareket eder."
- Takvimler yalnızca tek bir yönde ilerler
- Sorunlara ve zorluklara karşı pay bırakın
- Test başarısızlığı
- Daha sonra ailevi acil durumlar
- Sizin hatanız olmasa da başka biri ihtiyaç duyulan ürünü geç teslim edebilir
- Her zaman kendiniz ve ekibiniz için takvimde pay bırakın
Yasa 28 (Ranger Yasası) — Bedava fırlatma yoktur
- "Bedava fırlatma diye bir şey yoktur."
- Bedava fırlatma diye bir şey yoktur
Yasa 29 (von Tiesenhausen'in program yönetimi yasası) — Maliyet ve zaman tahmini
- "Nihai program gereksinimlerine dair doğru bir tahmin elde etmek için, başlangıçtaki zaman tahminlerini pi ile çarpın ve maliyet tahminlerindeki ondalık noktayı bir basamak sağa kaydırın."
- Nihai program gereksinimlerine ilişkin doğru bir tahmin elde etmek için, ilk zaman tahminlerini π ile çarpın ve maliyet tahminlerindeki ondalık noktayı sağa bir basamak kaydırın
Yasa 30 (von Tiesenhausen'in mühendislik tasarımı yasası) — Sanatçı konseptinin etkisi
- "Yeni bir mühendislik sisteminin tasarımı üzerinde azami etki yaratmak istiyorsanız, çizmeyi öğrenin. Mühendisler eninde sonunda aracı her zaman ilk sanatçı konseptine benzeyecek şekilde tasarlar."
- Yeni bir mühendislik sisteminin tasarımı üzerinde mümkün olan en büyük etkiyi yaratmak istiyorsanız, çizim yapmayı öğrenin; mühendisler sonunda aracı her zaman ilk sanatçı konseptine benzeyecek şekilde tasarlar
Yasa 31 (Mo'nun evrimsel geliştirme yasası) — Teknolojinin temel sınırları
- "Ay'a, art arda daha uzun ağaçlara tırmanarak gidemezsiniz."
- Giderek daha uzun ağaçlara tırmanarak Ay'a ulaşamazsınız
- Teknolojinin/yaklaşımın temel sınırlarını anlamak faydalıdır
Yasa 32 (Atkin'in demo yasası) — Murphy yasası
- "Donanım kusursuz çalıştığında, gerçekten önemli ziyaretçiler ortalıkta görünmez."
- Donanım mükemmel çalıştığında, gerçekten önemli ziyaretçiler ortaya çıkmaz
Yasa 33 (Patton'un program planlama yasası) — Uygulamanın önemi
- "Şimdi kararlılıkla uygulanan iyi bir plan, gelecek haftaki kusursuz bir plandan daha iyidir."
- Şimdi kararlılıkla uygulanan iyi bir plan, gelecek haftanın kusursuz planından daha iyidir
- Sektördeki hata: 'kusursuz' teknolojiyi beklemek
- Siz beklerken rakip pazarın kontrolünü ele geçirir
Yasa 34 (Roosevelt'in görev planlama yasası) — Gerçekçi uygulama
- "Elinizde ne varsa onunla, bulunduğunuz yerde, yapabildiğinizi yapın."
- Olduğunuz yerde, sahip olduklarınızla, yapabildiğinizi yapın
- SF yazarı değilseniz, var olmayan bir teknoloji için tasarım yapmak anlamsızdır
Yasa 35 (de Saint-Exupéry'nin tasarım yasası) — Kusursuz tasarım
- "Bir tasarımcı, mükemmelliğe eklenecek hiçbir şey kalmadığında değil, çıkarılacak hiçbir şey kalmadığında ulaştığını bilir."
- Tasarımcı, eklenecek hiçbir şey kalmadığında değil, çıkarılacak hiçbir şey kalmadığında mükemmelliğe ulaştığını bilir
Yasa 36 — Zarafet, verimlilik, etkililik
- "Sıradan herhangi bir mühendis zarif bir şey tasarlayabilir. İyi bir mühendis sistemleri verimli olacak şekilde tasarlar. Büyük bir mühendis ise onları etkili olacak şekilde tasarlar."
- Sıradan bir mühendis zarif bir şey tasarlayabilir, iyi bir mühendis verimli sistemler tasarlar, büyük bir mühendis ise etkili sistemler tasarlar
- Zarif tasarım (Elegant design): standart kentsel su şebekesi sistemi
- Verimli tasarım (Efficient design): New York su şebekesi sistemi
- Etkili tasarım (Effective design): Kuzey/Güney Amerika yerli uygarlıklarının sulama sistemleri (bazıları 1000 yıldan uzun süredir çalışıyor)
Yasa 37 (Henshaw yasası) — Sorumluluğun açık çizgileri
- "Bir görevde başarının anahtarlarından biri, sorumluluğun açık hatlarını oluşturmaktır."
- Bir görevin başarısının anahtarlarından biri, net sorumluluk hatları oluşturmaktır
- Kişi kendi eylem ve kararlarının sorumluluğunu almalıdır
- Sorumluluk almayı reddeden mühendise (veya başka herhangi birine) güvenmeyin
Yasa 38 — Yetenekler gereksinimleri yönlendirir
- "Sistem mühendisliği ders kitapları ne derse desin, gereksinimleri yönlendiren şey yeteneklerdir."
- Sistem mühendisliği ders kitapları ne derse desin, gereksinimleri yetenekler yönlendirir
- Esas mesele, hangi yeni yeteneklerin geliştirildiğini fark etmektir:
- 1950'ler: transistör
- 1960'lar: entegre devre
- 1970'ler: mikroişlemci
- 1980'ler: ev bilgisayarı
- 1990'lar: internet
- 2000'ler: kablosuz/mobil bilişim
Yasa 39 — Yeni fırlatma aracı geliştirme yasağı
- Yeni bir insanlı uzay programını ucuz ve takvime uygun tutmanın üç anahtarı:
- Yeni fırlatma aracı yok
- Yeni fırlatma aracı yok
- Ne olursa olsun yeni bir fırlatma aracı geliştirmeye karar vermeyin
- Tamamen yeni bir ürünün her zaman mevcut bir ürünün evriminden daha iyi olacağına inanma cazibesinden kaçınılmalıdır
Yasa 40 — Uzay affetmez
- "Uzay tamamen affetmeyen bir ortamdır. Mühendisliği berbat ederseniz biri ölür (ve analizin büyük kısmı doğruydu diye kısmi puan da yoktur...)"
- Uzay hiç affetmeyen bir ortamdır; mühendisliği mahvederseniz biri ölür (ve analizin çoğu doğruydu diye kısmi puan verilmez)
- Büyük mühendislik kontrol felaketleri:
- Fukuşima, Çernobil
- De Havilland Comet (ticari yolcu uçaklarında cam köşelerinin neden yuvarlak olduğuna dair örnek)
- Eastern Airline Flight 401 (otomatik pilotun ticari bir uçağı Everglades'e yönlendirmesi)
- Therac-25 (Kanada yapımı bir radyoterapi cihazı)
- Richard Feynman'dan serbest çeviri: "Doğa kandırılamaz (Nature cannot be fooled)"
1 yorum
Hacker News yorumları
1990'larda Trellis coded modulation ile 50 kilobaud'a çıkıldığı sözü biraz farklı
Telefon hattının bant genişliği ve SNR özelliklerinden hesaplanan Shannon kapasitesi yaklaşık 30 kb/s düzeyindeydi ve V.34 modemler bu sınıra yaklaşıp 33.6 kb/s'ye kadar ulaştı
Ancak 80'lerden sonra telefon ağı, 'son mil' dışında zaten dijitalleşmişti. ISP tarafındaki modem dijital sesi doğrudan çıkış olarak verebilirse teoride 64 kb/s'ye kadar mümkün oluyordu, ama pratikte FCC güç sınırları nedeniyle yaklaşık 53 kb/s civarındaydı
O dönemde modem modülasyonu araştırma ekibinde çalışıyordum; analog düşünce yapısına alışkın mühendislerin dijital kanalın imkanlarını fark etmesi epey zaman almıştı
Sonra kablo modemlere geçip yeniden analog dünyaya döndüler
Eve kadar olan bölüm hâlâ analogsa yine de Shannon-Nyquist sınırına bağlı değil mi?
Eğer ISP modemi ile ev modemi arası filtresiz bir bakır hat olsaydı, doğrudan UART ile birkaç Mbps aktarım da mümkün olmaz mıydı?
Bu kısmı biraz daha net açıklamanızı isterim
Trellis kodlama dahil çeşitli kodlama ve sıkıştırma teknikleri sayesinde ve bugün bile US Robotics'in 56k modemini satın alabilirsiniz
Law 20 günümüz startup gerçekliğini çok iyi ifade ediyor
“İyi bir tasarım kötü bir sunumla karşılaşırsa anında kaybeder” sözünde olduğu gibi, ifade gücünün önemi mutlak
İyi anlatabilmek, anladığının da kanıtıdır
“Bunu 5 yaşındaki bir çocuğa anlatamıyorsan sen de anlamamışsındır” sözü aklıma geliyor
“En büyük ticari başarı en iyi teknik tasarım değildir” sözü hakkında
Nokia N95 ile ilk nesil iPhone karşılaştırması çok uygun değil. Bunun yerine ben Canyon’s Law of Design Optimization öneriyorum — müşterinin istediği metriklerle geliştiricinin optimize ettiği metrikler farklıdır ve müşteriyi haksız olduğuna ikna etmeye çalışmamak gerekir
İlk nesil iPhone'un formu ve arayüzü mükemmeldi ama işlevleri eksikti. 3G, GPS, üçüncü taraf uygulamalar ve kamera tarafı zayıftı
Asıl ticari başarı iPhone 3G ile geldi
Son slayt eksik
“Yukarıdaki tüm tavsiyeleri görmezden gel ve doğru olanı yap” ifadesi asıl mesele
Birbiriyle çelişen tavsiyeler arasında denge kurmak gerçek mühendisliktir ve teknik olarak da sosyal olarak da en zor hedeftir
“Önceki analiz mutlak gerçek değildir ve kendi muhakemene güvenmelisin” anlamına geliyor
Bu PDF yeni görünüyor ama Akin’s Laws of Spacecraft Design 2003'ten beri var
Web arşivi bağlantısından da doğrulanabiliyor
Daha ilk yasaya bakınca yazılım “mühendisliği”ne neden gerçek mühendislik demenin zor olduğu görülebilir
Uzun zamandır von Tiesenhausen'in yasasını alıntılıyorum
“Mühendisler sonunda ilk sanatçının konseptine göre tasarlar” gibi bir şeydi ve bunu web projelerinde de aynı şekilde hissettim
İlk dokümanı yazan kişi ya da toplantıda notları tutan kişi çoğu zaman ürünün yönünü belirliyor.
'Agile' dense de pratikte süreç yol bağımlı oluyor
MIT'de 2003'te uzay aracı tasarımı bitirme dersi almıştım ama bu listeyi görmedim
O zamanki proje daha çok uydu odaklıydı ve Akin'in felsefesi muhtemelen örtük biçimde içine işlemişti
Uzay mühendisliğinde muhafazakâr tasarım kültürü güçlü olduğu için ilerleme yavaştı; Elon Musk öncesinde değişim daha da ağırdı
Özellikle “uzay affetmeyen bir ortamdır ve mühendislik başarısızlığı doğrudan can kaybı demektir” cümlesi etkileyiciydi
Bu da 2003 Columbia felaketi dönemine denk geliyor
Muhtemelen Law 31 (mevcut teknolojinin sınırlarını anla), Law 11'i (her şeyi atıp yeniden başla) tetiklemiştir ve Law 16 da (önceki analize körü körüne güvenme) bunu desteklemiştir
Ben bakım gerektirmeyen ve değiştirmesi kolay sistemleri tercih ederim
Yazılım teknolojileri eninde sonunda yok olduğundan, donanım gibi her an değiştirilebilir bir yapı olmalı
“Tamamen yeni bir ürünün her zaman mevcut bir ürünün evrim geçirmiş halinden daha iyi olduğuna inanma cazibesinden kaçın” tavsiyesi özellikle çok yerinde