Hayati Kritik Sistemlerle İnovasyon

Her işletmenin “kritik” bir altyapısı vardır. Genel olarak bu, sistem çevrimdışı olursa, işin bazı kısımlarının (veya tamamının) teknisyenler tekrar çalıştırana kadar durma noktasına geleceği anlamına gelir. Bu genellikle büyük yazılım, donanım veya ağ yükseltmeleri gerektiğinde ortaya çıkar: yeni dağıtılan sistemler, sistem arızasına neden olan beklenmeyen hatalar içerir veya kullanıcılar yeni sisteme aşina olmadıkları için yeni sistemde hata yaparlar ve teknisyenler bunu yapana kadar üretkenlik durur. dağıtım hataları üzerinde çalışın veya kullanıcıları eğitin. Çoğunlukla, yeni teknolojinin gelişmiş performans ve verimliliği vaadi karşılığında bir kesinti süresi veya azalan üretkenlik kabul edilebilir bir risktir, ancak bu evrensel değildir. Çoğu işletme, fazla gelir riske atmadan veya müşterilerini kızdırmadan belirli bir kesinti süresini karşılayabilir.

Ancak, değiştirmeniz gereken sistemler , can güvenliğinin sistemi güvenilir bir şekilde kullanabilmeye bağlı olduğu hayati önem taşıyan sistemler olduğunda ne olur?

Bu makale, zamanımızın çoğunu harcadığımız daha geleneksel yazılım geliştirmeden uzaklaşıyor ve bunun yerine hayati önem taşıyan sistemlerde insan unsuruna bir göz atıyor. Bu konudaki düşüncelerim, bir 911 ambulans hizmeti için Bilgi Teknolojileri Direktörü, uluslararası bir insani afet müdahale organizasyonu için teknoloji uzmanı olarak deneyimlerimden ve doktoramdan kaynaklanmaktadır. Massachusetts Teknoloji Enstitüsü'nde tamamlanan İnsan Sistemleri Entegrasyonunda.

Başlamadan önce, bunun sizinle neden alakalı olabileceğini açıklamak istiyorum. Projenizin aslında hayati öneme sahip bir sistem içerdiği açık olmasa da, düşündüğünüzden çok daha olasıdır. Aşağıdakilerin tümü ve sayısız daha fazla konu hak kazanır:

• Otomotiv. Bir araç üreticisi veya tedarikçilerinden herhangi biriyle bir proje üzerinde mi çalışıyorsunuz? Kendi kendini süren bir araba girişimi tarafından üniversiteden mi alındınız? Otomatik frenleme, hız sabitleyici, şerit kontrolü, bilgisayarlı görme, engel tanıma, elektronik motor kontrol modülleri vb. Bunların her biri, arızanın ölümcül olabileceği hayati önem taşıyan bir sistemdir.
• Havacılık. 30.000' havadayken, neredeyse tüm sistem arızaları hayati önem taşıyabilir. Boeing 737 MAX ile ilgili son olaylar göz önüne alındığında, otopilot ve bilgisayarlı uçuş kontrolünün hayati önem taşıyan bariz sistemleri var, ancak aynı zamanda düşünmeyeceğiniz pek çok şey de var. Evde, HVAC sisteminizdeki fan arızalanır ve biraz duman çıkarırsa, pencereyi açın veya biraz temiz hava almak için dışarı çıkın. Atlantik ötesi bir uçuş sırasında hiç pencereyi açıp dışarı çıkmayı denediniz mi? Kuzinedeki elektrik prizlerinden içecek arabasının tekerleklerindeki frenlere kadar en temel sistemler bile uçakta hayati öneme sahip olabilir.
• iletişim. Çoğu geliştirici veya mühendis, kariyerlerinin bir noktasında, şu veya bu kapasitede bir iletişim sistemi projesi üzerinde çalışacaktır. Birçok insan için telekomünikasyon başlangıçta hayati önem taşımaz; ne de olsa medeniyet, telefonlar ve internetten önce gayet iyiydi. Telekomünikasyon altyapısının tahrip olduğu afet bölgelerine konuşlanmış biri olarak size gerçekte ne olduğunu anlatayım: insanlar çok hastalanır veya yaralanır ve 911'i arayamaz; yaşlılar çocuklarını arayıp eczaneden reçetelerini almalarını isteyemezler; acil müdahale ekipleri, sevk görevlileriyle veya birbirleriyle iletişim kuramazlar; ve aile üyeleriyle iletişim kuramayan insanlar endişelenir ve onları bulmaya çalışmak için kendilerini son derece tehlikeli durumlara sokar. İletişim sistemleri kesinlikle hayati öneme sahiptir.

Günümüzün teknolojiye büyük ölçüde bağımlı olduğu dünyasında, asla yarı-önemli olduğunu düşünmediğiniz projeler, hayati önem taşıyan bir sistemin hayati bir bileşeni haline gelebilir.

Ama Bozulmadıysa Tamir Etmeyin

Teknolojik bir sistemle ilgili olarak “miras” kelimesini hiç duydunuz veya kullandınız mı? Uzun süredir devam eden gelenekler, soy ve eski zor zamanların düşüncelerini çağrıştıran güçlü bir kelime. Mühendislik dünyasında, uzun süredir var olan ve güvenilir bir şekilde çalıştığı kanıtlanmış ve genellikle riski azaltmak için arzu edilen bir özellik olarak görülen tasarımları belirtmek için kullanılır. Gerçekte, riskten kaçınma nedeniyle asla güncellenmeyen eski teknoloji için bir örtmecedir ve sistem arızalarının korkunç sonuçlara yol açabileceği endüstrilerde yaygındır.

Miras yazılım ve donanıma olan bu yakınlığın arkasında iyi bir neden var. Çalıştığı biliniyor, bilinmeyen hataların ortaya çıkması olası değil ve maliyetleri istikrarlı ve öngörülebilir. Mükemmel bir örnek uzay uçuşu endüstrisidir: Rus Soyuz uzay aracı, 50 yılı aşkın bir süredir, bu süre zarfında yalnızca küçük revizyonlarla astronotları uzaya fırlatmaktadır ve güvenilir ve emniyetli olduğu için kullanılmaya devam etmektedir. Ne yazık ki, bu aynı zamanda modern tasarımlara kıyasla son derece verimsiz olduğu anlamına geliyor: Soyuz, miras donanımını kullanarak astronotları uzay istasyonuna uçurmak için NASA'ya koltuk başına 81 milyon ABD Doları tutarken, SpaceX ve Boeing'in her biri 58 milyon ABD Doları tutarında koltuk sunması bekleniyor. modern roket tasarımlarını kullanarak.

Çok az kişinin hala çalışan eski sistemleri yükseltmek istemesi anlaşılabilir; yöneticiler riski istemiyor, teknisyenler dolaptaki gizemli sunucuyla 12 yıllık çalışma süresiyle uğraşmak istemiyor ve müşteriler yeni tasarımlar öğrenmek zorunda kalmak istemiyor. Ne yazık ki, risk minimizasyonu ile maliyet tasarrufu arasında bir dönüm noktası vardır: yüksek riskli ortamlarda bile, miras tasarımlarının eninde sonunda yükseltilmesi gerekecektir .

Bu makalenin geri kalanı, sistemleriniz ilk müdahale ekipleri, askeri birimler veya uçaklar tarafından kullanılanlar gibi hayati öneme sahip olduğunda bunu yapma sürecindeki daha önemli adımlardan bazılarını kapsar.

Pirinci ikna etmek

Tecrübelerime göre, sürecin muhtemelen en zor adımı, karar vericileri ve paydaşları güncellemelerin gerekli olduğuna ikna etmektir. Yaşam açısından kritik ortamlarda çalışan sistemler genellikle kapsamlı yasal düzenlemeler ve organizasyon politikası tarafından yönetilir; bu, onları yalnızca risk alıp parayı harcamaları gerektiğine değil, aynı zamanda kolayca çeşitli olabilecek şeylerle meşgul olmaları gerektiğine ikna etmeniz gerektiği anlamına gelir. yıllarca bürokratik bant kesme. Karşılaşacağınız en güçlü muhalefet, büyük olasılıkla, yeni teknolojiyi tanıtarak kuruluşu açacağınız potansiyel sorumluluğu ıstıraplı ayrıntılarla ortaya koyacak olan hukuk ekibinden olacaktır. Haklılar: sorumluluk önemli bir sorundur ve bir şey bozulursa ve birisi yaralanırsa veya ölürse, bu büyük bir etik, itibar ve mali yük olabilir.

İster bir Fortune 500 şirketiyle, ister yerel gönüllü itfaiye teşkilatınızla çalışıyor olun, her zaman aynı şeye iner: para. Şirketler bunu kaybetmek istemiyor ve kar amacı gütmeyen kuruluşların ilk etapta çalışacak çok şeyi yok. Bir organizasyonun liderliğini hayati öneme sahip bir sistemi değiştirme riskini almaya ikna etmenin tek güvenilir yolu, olasılıksal olarak, kaybetmekten ziyade para kazanma/tasarruf etme olasılıklarının daha yüksek olduğunu veya bunu yapabileceklerini göstermektir. teknolojilerini modernize ederek ve güvenliği artırarak sorumluluklarını azaltmak.

Bunun anlamı, matematiği yapmanız gerektiğidir. Hatalar (kuruluşunuzdaki önceki dağıtımlara veya diğer kuruluşlardan alınan verilere göre) nedeniyle uzun süreli kesinti veya gelecekte çökmeler olma olasılığı nedir? Başarısız olursa beklenen etki nedir ve bunun maliyeti ne olur? Tersine, beklenen performans veya güvenilirlik kazanımları nelerdir ve bunların değeri nedir? Öne çıkma ihtimalinizin yüksek olduğunu gösterebilirseniz, yeşil ışık yakmanız için iyi bir şans var.

Seninle alakalı değil

Mühendislerin kendilerine benzer niteliklere sahip kişiler tarafından kullanılmak üzere bir şeyler inşa ettiklerini ima eden "mühendisler tarafından, mühendisler için" deyimine aşina olabilirsiniz. Bu son derece yaygın bir olaydır ve 1990'ların başında bilgisayar kullanılabilirliği araştırmalarının yükselişini hızlandıran ana faktörlerden biriydi. Mühendisler olarak, teknolojik sistemlerin nasıl çalıştığına dair genellikle ortalama son kullanıcıdan farklı zihinsel modellere sahibiz, bu da son kullanıcının nasıl çalıştığını zaten bildiği varsayımıyla sistemler tasarlama eğilimine yol açar. Geleneksel sistemlerde bu, hatalara ve mutsuz müşterilere yol açar; hayati önem taşıyan sistemlerde ölüme yol açabilir.

Air France Flight 447 örneğini düşünün. 1 Haziran 2009'da Airbus A330, Rio de Janeiro'dan Paris'e giderken Atlantik Okyanusu üzerindeydi. Buz kristalleri pitot tüplerini tıkayarak hava hızı ölçümlerinde tutarsızlıklara neden oldu. Uçuş bilgisayarı, uçağın kendisini yanlış hava hızı verileriyle güvenilir bir şekilde uçuramayacağını kabul ederek otomatik pilotu devre dışı bıraktı. Daha sonra kendisini, pilotların bilgisayarın normalde izin vermediği manevraları yapmasına izin veren “genişletilmiş uçuş zarfı” moduna yerleştirdi. Sistemi kuran mühendislerin “otomatik pilot kendini devre dışı bırakırsa, bunun nedeni muhtemelen pilotların ekstra kontrole ihtiyaç duyabileceği bir durum olduğudur” diye düşündüklerini hayal edebilirsiniz! ”

Bu, ne tür şeylerin otopilotun devreden çıkmasına neden olabileceğini anlayan mühendisler için doğal bir düşünce dizisidir. Pilotlar için durum böyle değildi. Tüm hava hızını kaybedip okyanusa düşene kadar "STALL" uyarılarını görmezden gelerek uçağı dik bir yukarı tırmanmaya zorladılar. Tüm 228 yolcu ve mürettebat öldürüldü. Eylemlerinin tam motivasyonu konusunda birden fazla fikir olsa da, hakim teori, pilotların uçuş bilgisayarının uçağı durduracak kontrol girdilerini önleyeceğini varsaydıklarıdır (bu normal uçuş zarfı için doğrudur) ve bunun farkına varmamıştır. mühendislerin bilgisayarın kararlarını yönlendiren mantığın zihinsel modelini paylaşmadıkları için genişletilmiş zarf moduna geçmişti.

Biraz dolambaçlı bir yol olsa da bu bizi asıl konumuza götürüyor: Belirli koşullar altında kullanıcıların yapmasını istediğiniz eylemler, kullanıcıya doğal gelen eylemler olmalıdır.

Kullanıcılara belirli prosedürleri izlemeleri talimatı verilebilir, ancak her zaman yapılacak doğru şeyi hatırlamayacaklar veya yüksek stres koşullarında neler olduğunu anlamayacaklar. Yazılımları, kontrolleri ve arayüzleri, kullanıcıların doğal olarak yapmaları gereken şeyleri yapmak istemelerini sağlayacak şekilde sezgisel bir şekilde tasarlamak sizin sorumluluğunuzdadır.

Bunun anlamı, son kullanıcıların tasarım ve geliştirme sürecinin her bir aşamasına dahil olmasının kesinlikle kritik olduğudur. Kullanıcıların muhtemelen ne yapacakları konusunda herhangi bir varsayım yapılamaz; hepsi kanıta dayalı olmalıdır. Arayüzler tasarladığınızda, bunların kullanıcılarda uyandırdığı düşünce kalıplarını belirlemek ve gerektiği gibi ayarlamak için çalışmalar yapmalısınız. Yeni sistemlerinizi test ettiğinizde, gerçek kullanıcılarla gerçek ortamlarda, gerçekçi koşullarda test etmelisiniz. Ve ne yazık ki tasarımlarınızı değiştirdiğinizde bu adımları tekrar tekrar yapmanız gerekiyor.

Her karmaşık sistem benzersiz olmasına rağmen, özellikle evrensel olarak uygulanması gereken üç tasarım düşüncesinden bahsetmek istiyorum:

• Kontroller, başlattıkları eylemleri temsil etmelidir. Neyse ki, bu oldukça yaygındır ve genellikle GUI düğmeleri için ilgili simgelerin veya fiziksel kontroller için ilgili şekillerin seçilmesi şeklinde görülür. “Yeni Dosya” düğmeleri boş bir kağıt simgesi kullanır ve uçaktaki iniş takımı kollarında tekerlek şeklinde bir topuz bulunur. Ancak, memnun olmak kolaydır. “Kaydet” düğmeleri için neden hala 3.5” disket simgelerini görüyoruz? 25 yaşından küçük biri disketin ne olduğunu biliyor mu? Temsili olduğunu düşündüğümüz için kullanmaya devam ediyoruz ama aslında artık değil. Kontrol temsillerinin kullanıcılar için anlamlı olmasını sağlamak için sürekli çaba gerektirir, ancak bunu süreklilikle dengelemek de gerekli ve zordur.
• Bir uyarı sistemi bozulursa, tespit edilebilir olmalıdır. Yanıp sönen kırmızı gösterge gibi bir sorun olduğunda devreye giren uyarı ışıklarını sıklıkla kullanırız. Bir kullanıcının dikkatini çekmek için harika, ancak ışık yanarsa ne olur? Apollo ay görevlerinde kullanılan uzay aracının her türlü sistem için onlarca uyarı ışığı vardı, ancak bunlar geleneksel bir şekilde çalışmıyordu. Bir sorun olduğunda aydınlatmak yerine, her şey yolundayken yanık kalıyor ve bir sorun olduğunda sönüyordu . Bu, yanmış bir uyarı ışığının astronotların potansiyel olarak ölümcül bir sistem hatasını kaçırmasına neden olmamasını sağladı. Bu tasarımı kullanmanız gerektiğini söylemiyorum, çünkü ampuller 1960'lardan bu yana güvenilirlik konusunda uzun bir yol kat etti, ancak bu, bazı planlamalarınızın ne kadar derinlemesine olması gerektiği konusunda bir fikir veriyor. Bir sistem kaç kez çöktü, ancak günlüğe kaydetme veya bildirimler düzgün çalışmadığı için bundan haberiniz yoktu?
• Mod geçişleri kullanıcı için açık olmalıdır. Bir Airbus A330, kullanıcı fark etmeden normal kontrol modundan gelişmiş kontrol moduna geçerse ve uçak aniden kullanıcının yapabileceğini düşünmediği şeyler yaparsa ne olur? Kendi kendini süren bir araba otomatik pilotunu devre dışı bırakarak beklenmedik bir şekilde kullanıcıyı tam kontrolde bırakırsa ne olur? Modda veya işlevsellikte, kullanıcının eylemlerinde ani bir değişiklik gerektiren herhangi bir büyük geçiş olduğunda, ancak kullanıcının ne olduğunu anlaması bir veya iki dakika sürdüğünde ne olur? Karmaşık bir sistemde çeşitli çalışma modları gerekli olabilirken, modlar yeterli bildirim, açıklama ve bunu yaparken kullanıcı ile etkileşim olmadan geçiş yapamaz.

Hayati Kritik Sistemleri Mağazadan Çıkarma

Sektördeki en iyi uygulamalara uygun olarak, hayati önem taşıyan yeni sistemlerin devreye alınması için bir beta aşaması çok önemlidir. Yeni teknolojinizin testleri, hataların ve kullanılabilirlik sorunlarının çoğunu düzeltmenize yardımcı olmuş olabilir, ancak gerçek dünya ortamlarında diğer sistemlerle birlikte kullanılması gerektiğinde gizli tehlikeler ortaya çıkabilir. Sistem mühendisliği disiplininde bu, “ortaya çıkma” olarak bilinir. Ortaya çıkan özellikler, "bir uygulamanın bileşenleri ile çevreleri arasındaki etkileşimden kaynaklanan beklenmeyen davranışlardır" ve doğaları gereği laboratuvar ortamında tespit edilmesi esasen imkansızdır. Temsili bir son kullanıcı grubunu dikkatli bir denetim altında yeni sisteminizi denemeye davet ederek, bu özelliklerin çoğu tespit edilebilir ve tam ölçekli dağıtımda ortaya çıkabilecek olumsuz sonuçlar açısından değerlendirilebilir.

Müşterilerimle mimarlık tartışmalarında sıklıkla ortaya çıkan bir başka konu da aşamalı bir sunumdur. Bu, önceden var olan bir sistemin öğelerini, sonunda her şey değiştirilene kadar yeni bir sistemin öğeleriyle kademeli olarak değiştirmek ile her şeyi bir kerede değiştirmek arasındaki seçimdir. Her birinin artıları ve eksileri vardır: aşamalı bir sunum, kullanıcıların kademeli olarak yeni tasarıma alışmasını sağlayarak değişikliklerin yönetilebilir miktarlarda gelmesini ve kullanıcıların bunalmamasını sağlar; öte yandan, süreci uzun süreler boyunca sürükleyebilir ve sürekli bir geçiş durumuyla sonuçlanabilir. Anında kullanıma sunma, "yara bandını söküp atmaları" ve işleri hızlandırmaları açısından faydalıdır, ancak ani sert değişiklikler kullanıcıları bunaltabilir.

Hayati kritik sistemler için, aşamalı sunumların genellikle daha güvenli olduğunu buldum, çünkü bir üretim ortamında ayrı bileşenlerin aşamalı olarak değerlendirilmesine izin veriyorlar ve bir şeyin geri alınması gerekiyorsa daha küçük geri dönüşlere izin veriyorlar. Ancak bu, duruma göre değerlendirilmesi gereken bir şey.

Sapmanın Normalleştirilmesi

Tamam, yani kullanıcı testiniz sezgisel bir sistem tasarlamanıza yardımcı oldu, beta aşamanız acil sorunları belirledi, aşamalı sunumunuz kullanıcıların tasarım konusunda rahat olmalarını sağladı ve her şey sorunsuz çalışıyor. İşin bitti, değil mi? Ne yazık ki değil.

Sisteminizle ilgili sorunlar kaçınılmaz olarak ortaya çıkacaktır, bunun üstesinden gelemezsiniz. Kullanıcılar bu sorunlarla karşılaştıklarında, sorunu teknik ekibe bildirmek yerine genellikle geçici çözümler geliştirirler. Geçici çözümler, gazilerden çaylaklara "ipuçları" olarak paylaşılan standart uygulama haline gelecek. Sosyolog Diane Vaughan bu fenomeni tanımlamak için bir deyim icat etti: "sapkınlığın normalleşmesi". Kullanıcılar sapkın davranışlara o kadar alışırlar ki, bunun aslında sapkın olduğunu hatırlayamazlar.

Klasik örnek Uzay Mekiği Challenger'dır: katı roket güçlendiricilerdeki bir bileşenin fırlatma sırasında düzenli olarak aşındığı gözlemlendi ve herkes roket bileşenlerinin aşınmasının kötü bir şey olduğunu bilmesine rağmen, o kadar sık ​​​​oldu ki, düzenli olarak feragatname verildi ve kabul edildi. normal. 28 Ocak 1986'da, herkesin başlangıçta izin verilmemesi gerektiğini bildiği ancak normalleştiği sorun, Challenger'ın patlamasına ve yedi astronotun ölümüne neden oldu.

Hayati kritik bir sistemin yöneticisi olarak, bu tür olayların olmasını önlemek sizin elinizde. Kullanıcılarınızın sistemle nasıl etkileşime girdiğini inceleyin. Onları birkaç gün gölgeleyin ve beklenmedik geçici çözümler kullanıp kullanmadıklarını görün. Önerilen değişiklik ve iyileştirmeleri istemek için periyodik olarak anketler gönderin. Kullanıcılarınız sorunları siz olmadan çözmenin yollarını bulmadan önce sisteminizi geliştirmeye zaman ve çaba ayırın.

Baskı Altında Performans Eğitimi

Kullanıcılar stres, adrenalin dalgalanmaları ve tünel görüşünden muzdarip olduğunda, hayati öneme sahip sistemlerdeki arızalar sıklıkla meydana gelir. Air France 447'deki pilotların başına geldi, ilk kalp krizi geçiren hastada kalp monitörlerini nasıl çalıştıracağını hatırlayamayan sağlık görevlilerinin başına geldi ve ateş altındayken telsizlerini düzgün çalıştıramayan askerlerin başına geldi.

Bu riskin bir kısmı, daha önce tartışıldığı gibi sezgisel tasarımlar kullanılarak iyileştirilir, ancak bu tek başına yetersizdir. Özellikle yüksek stres senaryolarının meydana geldiği ancak nadiren meydana geldiği ortamlarda, kullanıcılarınızı sadece sisteminizi nasıl çalıştıracaklarını değil, aynı zamanda bu koşullar altında nasıl net düşüneceklerini de eğitmeniz önemlidir. Kullanıcılar işletim ekipmanıyla ilgili eylemleri ezberlerse, öğrendikleri eylemler artık uygun olmayabileceğinden beklenmedik arızalarla baş edemezler; Stres altında mantıklı ve net düşünmek için eğitilirlerse, değişen koşullara yanıt verebilir ve bir şeyler bozulduğunda sisteminizin canlı kalmasına yardımcı olabilirler.

Çözüm

Açıkçası, hayati öneme sahip yazılımları geliştirmek, dağıtmak ve sürdürmek, tek bir makalede ayrıntılı olarak anlatılabileceğinden çok daha karmaşıktır. Ancak, dikkate alınması gereken bu alanlar, böyle bir proje üzerinde çalışmayı düşündüğünüzde ne bekleyeceğiniz konusunda daha iyi bir fikir vermenize yardımcı olabilir. Özetle:

• Her şey sorunsuz çalışırken bile yenilik gereklidir
• Yöneticileri riske değer olduğuna ikna etmek zordur, ancak rakamlar yalan söylemez
• Son kullanıcılar sürecin her adımında yer almalıdır
• Gerçek ortamlarda gerçek kullanıcılarla gerçekçi koşullar altında test edin ve yeniden test edin
• İlk seferde doğru yaptığınızı varsaymayın; çalışıyor olsa bile, kullanıcılarınızın size bahsetmediği, tespit edilmemiş sorunlar olabilir.
• Kullanıcılarınızı sadece sistemi nasıl kullanacakları konusunda değil, aynı zamanda nasıl net düşünecekleri ve stres altında nasıl uyum sağlayacakları konusunda eğitin.

Kapanışta, ne kadar planlama, test ve bakım yaparsanız yapın, güvenlik açısından kritik olan karmaşık sistemlerde işlerin bir noktada ters gideceğini belirtmek isterim. Bu sistemler hayati önem taşıdığında, bir arızanın can veya uzuv kaybına yol açması oldukça olasıdır.

Sorumlu olduğunuz bir şeyle ilgili böyle bir trajedi yaşanması durumunda, vicdanınıza büyük bir yük bindirecek ve daha fazla dikkat etseydiniz veya daha çok çalışsaydınız, bunu önleyebileceğinizi düşüneceksiniz. Belki bu doğrudur, belki değildir, ancak olası her olayı öngörmek imkansızdır.

Titizlikle çalışın, ukala olmayın, dünyayı daha iyi bir yer haline getirmiş olursunuz.