Iowa seçim uygulaması oylamasının maskaralıkları üzerine düşünceler: Yazılım mühendisliğinde neden bu kadar kötüüz?
[Editörün notu] Kısa bir süre önce, Amerika Birleşik Devletleri'nde 2020 başkanlık seçimleri için Demokrat adayların ön seçimleri Iowa'da başladı.Iowa Demokratik Parti Grubu toplantısında, bir uygulama büyük bir kaosa neden oldu. Beklendiği gibi, bu genel seçim oylaması uygulaması sonuçları oylamadan iki saat sonra hızlı bir şekilde açıklayacak, ancak Uygulama arızalandı ve ertesi güne kadar hiçbir sonuç verilmedi.
Yazar | Jake Voytko
Sorumlu Derleyici | Xi Yan
Üretildi | CSDN (ID: CSDNnews)
Uygulama raporu, teknik sorunları ve tutarsızlıkları gösterir. Iowa Demokratik Partisi, siber saldırıya uğramadıklarını ancak Uygulamayı kullanırken teknik sorunlarla karşılaştıklarını açıklayan bir açıklama yaptı.
Iowa'nın, bölge yetkililerinin parti parti toplantılarının sonuçlarını daha kolay ve hızlı bir şekilde iletmesini sağlayacak bir uygulama geliştirmek için Shadow Company'ye 60.000 $ 'dan fazla para ödediği ortaya çıktı.
Ancak uygulama o gün bir saçmalığa dönüştü, genel bir seçimi alt üst etti ve neredeyse bir şirketi parçaladı.
Bundan sonra, bu makalenin yazarı, bu uygulama geliştirme kazası aracılığıyla, yazılım mühendisliği alanına ruhsal bir soru sorduğunu yazdı - yazılım mühendisliğinde neden bu kadar kötüyuz?
Sorun ne?
Sadece bir hafta sonra, herkes kazayı daha net anladı. Bu Uygulamanın genel bir Uygulama mağazasından ziyade bir Beta test programı aracılığıyla dağıtıldığı ve kullanıcıların Uygulamayı genel süreç aracılığıyla yüklemesinin zor olduğu ortaya çıktı. Kurulumdan sonra da tepkisiz hale gelme olasılığı çok yüksektir. Sorunları daha da kötüleştirmek için, bazı konferans konumları İnternet'e bağlanamaz, bu da İnternet'e bağlanamayan uygulamaları işe yaramaz hale getirir. Yedek bir plan kullandılar: konferans ekibinin kullandığı telefon hattını kullanmak, ancak maalesef hat sıkışıktı.
Daha sonra, yukarıdaki çizgi romanlar yazılım mühendisleri arasında hızla yayılmaya başladı. Ben de gördüm. Bu karikatürünü (ve Twitter'da gördüğüm görüşleri) tek bir cümleyle özetliyor: "Nasıl söyleyeceğimi bilmiyorum, ama yaptığımız işte tüm alanımız iyi değil. Bize güvenirsek, herkes ölecek." Yazılım mühendisleri aslında buna inanmıyor. Ama kulağa doğru geliyor. Bunun anlamı ne?
Bunun anlamı şudur ki: Başarısızlığın sonuçları ciddi olmadığında, yazılım yaratmaktan mutluluk duyarız. Genel yazılım yeterince iyiyse, normal şekilde çalışabilir. Ancak çoğu yazılımın performansı, bizi hatalara alıştıracak kadar kötüdür. Bu tesadüfi değildir. Yazılım mühendisliği dünyasındaki birçok ortak davranış, insanların başarısızlıklara toleranslı olduğu ve yeni özelliklerin yeterince çekici olduğu bir ortamda doğar. Ve başarısızlığın bedeli ucuzdur. İki saat içinde tamamen çevrimdışı olan piyasa değerine göre listelenen ilk 10 şirket tarafından sağlanan herhangi bir çevrimiçi hizmete katılın ve insanlar bunu bir hafta içinde unutacak. İnsanlar gerçeklerden kaçmak için "atılımlar yapmak için ileri sar" ve "çevrimiçi ve yinelemek" gibi bahaneler kullanıyor.
Ödüller çok cömert. Birçok İnternet şirketinde, kullanıcı başına küçük bir gelirin milyonlarca (veya milyarlarca!) Kullanıcı ile çarpılması çok büyük bir sayıdır. Tüketici odaklı uygulamaları veya web siteleri olan şirketler için bu kârlıdır. Dağıtım maliyeti yüksektir, ancak sonuçta sınırlıdır ve dağıtım neredeyse ücretsizdir. Tüketici yazılım mühendisliği endüstrisinin ödünleşmeleri tartması gerekiyor: dağıtım hızını, hata oranını düşük tutmaya yetecek kadar düşürüyoruz, ancak belirli bir seviyeye indirmiyoruz.
Ben buna "yazılım geliştirme" diyorum Web Sitesi Ekonomik Modeli " : Dağıtımın faydaları yüksek ve yeniden denemenin maliyeti düşük olduğunda, yönetim, yüksek kısa vadeli özellik hızını optimize etmek için teşvikler belirleyecektir. Bu, aşağıda tartışacağım modern proje yönetimi uygulamalarına ve bunların uygulanmasına yansır.
Ama daha önce de söylediğim gibi, "Başarısızlığın sonuçları asgari düzeyde olduğunda, yazılım yaratmaktan mutlu oluruz." Iowa'da olduğu gibi başarısızlık pahalı olduğunda, korkunç sonuçları olabilir. Yaygın yazılım mühendisliği uygulamaları İnternet ekonomik modelinden türetilmiştir.Bu modelin varsayımları ihlal edildiğinde, yazılım mühendisleri işimizde hayal kırıklığına uğrayacaktır.
Bir ağ şirketinde yazılım mühendisliği nasıl çalışır?
Tüketici odaklı bir yazılım şirketi olan QwertyCo'nun yıllık 100 milyon dolarlık geliri olduğunu varsayalım. Diğer şirketlerle karşılaştırarak QwertyCo'nun boyutunu tahmin edebiliriz. Web sitesi WP Engine'i barındıran blog sistemi, 2018'de 100 milyon ABD Doları tutarında bir ARR'ye (Geri Dönüş Hesaplama Oranı) sahiptir. BlueApron'un 2018'deki geliri 667 milyon dolardı. Bu nedenle QwertyCo orta ölçekli bir şirkettir. Düzinelerce yüzlerce mühendisi var ve özeldir.
Öncelikle QwertyCo'nun proje yönetimi ekonomisine bakalım. Yöneticiler, bir gecede bir işlev yaratmanın imkansız olduğunu bilirler. Yazılım kalitesi, verilen zaman ve uygulama hızı arasında bir denge kurmaları gerekir.
Yazılım kalitesi onlar için ne kadar önemli? çok önemli değil. QwertyCo'nun web sitesi yılda 24 saat kapalıysa, toplam 273.972 ABD doları kaybetmeyi bekler (çalışma süresi ile gelir arasında doğrusal bir ilişki olduğu varsayılarak). İlginç bir şekilde, site genellikle 15 dakika kapalı, ancak kimse umursamıyor gibi görünüyor. Bir özellik siteyi felç ederse, özelliği geri alır ve daha sonra tekrar dener. Yeniden denemenin maliyeti çok düşük.
QwertyConun yeni özellikleri ne kadar değerli? Kişisel gözlemime göre, bir mühendis siteyi bir ay optimize ederek geliri -2% -1% oranında değiştirebilir. Her mühendis, QwertyCo'dan her ay 1 milyon USD ek gelir elde etme fırsatına sahiptir. A / B testi gibi teknikler hataları azaltabilir: birkaç hafta içinde, negatif veya nötr değişiklikleri tespit edebilir ve bu özellikleri kaldırabilirsiniz. Kötü özellikler çok paraya mal olmaz çünkü sınırlı bir süre dayanırlar ve zafer sonsuza kadardır. QwertyCo için küçük bir kazanma yüzdesi bile çekicidir.
Dezavantajları ve dezavantajları göz önüne alındığında, QwertyCo bir özelliği ne zaman başlatmalı? Ekonomi, özelliklerin riskleri yüksek olsa bile, ara sıra fayda sağladıkları sürece çevrimiçi olmaları gerektiğine inanıyor. Dolayısıyla her proje bir optimizasyon oyunu haline gelecektir: "Bu özellik günde ne kadar gelir getirebilir?", "Bu projeyi uygulamak ne kadar sürer? Ya X'i çıkarırsak? Ya X ve Y'yi çıkarırsak? Bu bölümü daha az zaman alıcı hale getirmenin bir yolu var mı? "
Şimdi bir yazılım projesini bir yazılım mühendisinin gözünden inceleyelim.
Yazılım mühendislerinin ana ürünü zamandır. Güvenli yazılım mühendisliği çok zaman alır. Projenin karmaşıklık eşiği düştüğünde, birçok aşamaya bölünecektir. Tasarımcının veya ürün yöneticisinin yazılım projesinin kapsamını belirlemesi ve gerektiğinde bunu teknik bir tasarıma veya plana dönüştürmesi ve gerektiğinde alt görevlere ayırması gerekir. Ardından kodu yazın, test edin, kodu gözden geçirin, istatistikleri kaydedin ve kontrol paneliyle entegre edin, gerektiğinde uyarılar yayınlayın ve gerektiğinde manuel testler yapın. Ek olarak, kodlama genellikle yeniden düzenleme adı verilen ön maliyetlere mal olur: yeni işlevlerin uygulanmasını kolaylaştırmak için mevcut sistemleri değiştirmek. "Küçük" işlevi uygulamak için gereken süre, kodlamanın yalnızca% 10-30'u olabilir.
Mühendisin zamanı nerede harcanıyor? Sistem arızası çoğu zaman alır. Site arıza süresi küresel bir durumdur. En deneyimli mühendis bu sırada duracak ve sitenin tekrar çalışmasına izin verecektir. Ancak bunun için harcanan zaman değer katmadı. Projeleri şu anda programın gerisinde ve onlara yanıt zayıf. Arıza süresi nasıl azaltılır? Yazılı test, izleme, uyarı ve manuel testlerin tümü bu felaket olaylarının riskini azaltabilir.
Mühendisin zamanı hala nerede geçiyor? Küçük hataları düzeltmek için meşgul. Bazı hatalar ciddidir ancak yaygın değildir. Kullanıcılar nadir işlemleri gerçekleştirirse, veriler kaybolabilir. Mühendisler bu hata raporunu aldıklarında, her şeyi durdurmalı ve hatayı düzeltmelidir. Bu da mevcut projeyi etkiler ve zamanla önemli kayıplara neden olabilir.
Bu nedenle deneyimli yazılım mühendisleri kod kalitesine önem vermeye başladı. Kodun doğru olduğunu doğrulamak istiyorlar. Mühendislik organizasyonlarının görünüşte geliştirmeyi yavaşlatan önlemleri benimsemesinin nedeni budur: kod incelemeleri, sürekli entegrasyon, gözlemlenebilirlik ve izleme. Hata ne kadar geç keşfedilirse, maliyet de o kadar yüksek olur, bu nedenle mühendisler hataların erken tespiti için çok para yatırırlar. Ayrıca uygulamayı basitleştirmek için yeniden düzenlemeye odaklanırlar. Basit uygulamaların hata yapma olasılığı düşüktür.
Bu nedenle, yönetim ve mühendislik genellikle kalite konusunda anlaşmazlığa düşer. Yönetim yüksek bir hata oranı istiyor (ancak yeterince düşük) ve mühendisler düşük bir hata oranı istiyor.
Proje yönetimine nasıl dahil edilir? Ürünler ve mühendislik, projeyi tüm projeyi kapsayan küçük görevlere ayırır. Proje uzunluğu, görev sayısının ve mühendis sayısının bir fonksiyonudur. Genellikle proje uzun zaman alır ve silme işlevi ile ayarlanır. Ardından mühendis görevi yerine getirir. Genellikle herkes görevi "sprint" te tamamlayacaktır. Sprint süresi iki hafta ise, her görevin iki haftalık bir zamanlayıcısı vardır. Ancak görevler genellikle beklenenden daha uzun sürer. Mühendisler görevleri zamanında tamamlamak için zor öncelikli kararlar alırlar: "Temel testleri yazarsanız ve planda yeniden düzenleme yapmazsanız, bu işi sprint aşamasının sonunda tamamlayabilirim." Sprint süreci sürekli olarak zamanında zaman maliyeti getirir. Bu, mühendislerin kaliteden ödün verebileceği veya sprint planlama toplantısında başarısız olabilecekleri anlamına gelir.
Bazı insanlar sprint sırasında çok sert olduğumu ve haklı olduklarını söyleyecekler. Bu gerçekten de zaman maliyeti teşviklerinin sonucudur. Sprint süreci, zaman baskısını birden çok kez uygulamanın uygun bir yoludur: bir kez tüm projenin kapsamını belirlerken ve her görevde bir kez. Ürün ekibi, ürünün katma değerine göre değerlendirilirse, yönetimden herhangi bir ek destek almadan uygulama süresini doğal olarak mühendisle görüşeceklerdir. Mühendisler de hızlı bir şekilde uygulama konusunda motive olurlar, ancak kısa vadeli değil uzun vadeli bir perspektiften optimize etmeye çalışabilirler. Bu nedenle, şirketler genellikle kısa vadeli hızı artırmak için motive olurlar.
Bu nedenle, uygun bir teşvik yapısı oluşturarak, yöneticiler en başından istediklerini elde edebilirler: işlevi ve beklenen tarihi ayarlayabilirler ve ürün ve mühendislik teknolojisi, işlevi gerçekleştirmek için doğal olarak gerekli koşulları müzakere eder. "Umarım 2 ay içinde hesapsız ödeme yaparsınız." Ürün ve mühendislik departmanı, iki haftalık tüm görevleri yazacak ve karmaşıklıkları ortadan kaldıracak ve "hesapsız ödeme" adlı projeyi başlatana kadar bunları basitleştirecektir. Bu, daha düşük bir kırılma riski oluşturur ve olgunlaşmadan önce birkaç yinelemeden geçebilir. Ancak kesinti geçicidir ve işlev kalıcıdır.
Web sitesi ekonomik modelinin varsayımları ihlal edilirse ne olur?
Daha önce de söylediğim gibi, "Başarısızlığın sonuçları önemli olmadığında, yazılım yapmaktan mutluluk duyarız." "Yaşa ve yinele" ve "Hızlı git ve atılımlar yap" sloganları bu varsayıma işaret ediyor. Ancak, bunu yapmanın maliyetinin pahalı veya imkansız olduğunu hepimiz hayal edebiliriz. Aşırı durumlarda, bir binanın yıkılması binlerce insanı öldürebilir ve milyarlarca dolarlık hasara neden olabilir. 2020'deki Iowa Demokrasi Grubu'nun durumu oldukça küçük. Çekirdek grup başarısız olursa, günün sonunda herkes evine gidecek. Ancak Demokrat Parti'nin çok fazla zaman, para ve anlayış harcamadan ikinci bir toplantı yapma şansı yok.
Not: Bu bölümde, "çoğaltma yok" ve "pahalı çoğaltma" için bir kısaltma olarak "yüksek risk" i kullanacağım.
Web sitesi ekonomik modelini yüksek riskli durumlara uygulamaya ne dersiniz? Rastgele örnek: Iowa Eyalet Grubu toplantısının sonuçlarını bildirmek için bir uygulama yazıyorsunuz. Birkaç adımda yazar mısın? Uygulamayı test ediyor ve doğruluyor musunuz?
İlki mühendislik: Android App ve iPhone App'i aynı anda yazmalısınız. Raporlama temel bir gerekliliktir, bu nedenle bir sunucu gereklidir. Karmaşık temel kurallar hem istemcide hem de sunucuda kodlanmalıdır. Sistemin sonuçları son kullanıcıya rapor etmesi gerekir; bu, yazmanız gereken başka bir arayüzdür. Demokrat Parti, Uygulamaya yazılması gereken doğrulama ve raporlama gereksinimlerine sahip olabilir. Ek olarak, parti grup toplantısı sırasında sunucunun çalışmaması kötü olur, bu yüzden sistemde bir tür gözlemlenebilirlik yazmanız gerekir.
Ardından, Uygulamayı nasıl doğrularsınız? Seçeneklerden biri kullanıcı testidir. Potansiyel kullanıcılara, Uygulamanın varsayılan resmini gösterecek ve onlara "Bu arayüzün amacının ne için olduğunu düşünüyorsunuz?", "Bir karakteri tamamlamak istiyorsanız, neye tıklarsınız?" Gibi sorular soracaksınız. Tasarım her zaman yineleme gerektirir, bu nedenle modelinizin yüksek kaliteli bir Uygulama haline gelebilmesi için birden çok kullanıcı testi turu gerekebilir. Büyük şirketler, büyük işlevleri uygulamadan önce genellikle birden çok test turu yürütürler. Bazen bir özellik, kod yazmadan önce geri bildirime göre iptal edilir. Kullanıcı testi ucuzdur. 15 dakika içinde bir soruyu cevaplayacak 5 kişi bulup 5 dolarlık hediye kartı almak ne kadar zor? Dikkat edilmesi gereken tek şey, Iowa çekirdek ekibinin isteklerini temsil edebilecek test kullanıcılarıdır.
Ardından, uçtan uca deneyimi doğrulamanız gerekir: uygulama yüklenmeli ve ayarlanmalıdır. Demokrat Parti, sonuçlara nasıl ulaşılacağını anlamalıdır. Uygulama koşullara girdiğinde, bir yedekleme planı gereklidir. İyi bir testin bir "uygulama grubu" oluşturması gerekebilir ve Iowa Demokrat çalışanlarının uygulamayı indirmesi ve sonuçları belirli bir tarihte rapor etmesi gerekir. Bu, sistemik sorunları tespit edebilir veya beklentileri belirleyebilir. Bu, işlevler uygulanırken aşamalar halinde de yapılabilir.
İnternetin her yerinde "sorun gidericiler" olduğunu ve bunların çekirdek ekibe müdahale etmediğinden emin olmanız gerektiğini belirtmek gerekir. Alınan sonuçların Iowa çekirdek ekibinden olduğunu doğrulayabilir misiniz? Ayrıca internet yalan söyleyenlerle dolu, bu insanlar yalan söyleyecek ve zarar verecek. Hizmet reddi saldırılarına direnebilir mi? Değilse, bir yedekleme planı var mı? Yedekleme planının uygulandığını duyurmaktan ve bunu yedek ekibe iletmekten kim sorumludur? Bir kişi çekirdek grubun hesaplarına girerse ne olur? Şirkette güvenlik uzmanı yoksa, temel tartışmaları veya seçimleri yürüten uygulamaların kapsamlı bir üçüncü taraf güvenlik incelemesinin yapılması gerekir.
Daha sonra, yazılımda hata raporları veya hata özeti sonuçları olmadığından nasıl emin olunur? Aynı nedenle, Demokrat Parti size şüpheyle yaklaşmalıdır: Şirketinizde "sorun çıkaranlar" olsa bile, Demokrat Parti sonuca güvenebilir mi? Sonuçlar kağıt kopyalar aracılığıyla denetlenebilir olmalıdır.
Tamam, soruları tek tek listelemek için duraklayın. Ayrıca bu özelliği doğrulamak için çok fazla zamana ve kaynağa ihtiyacınız var.
Iowa Caucus Conference Uygulamasının yapımcısı gereklidir Projeyi 2 ay içinde tamamlamak için ödül 60.000 $ 'dır. Dört mühendisleri var. 60.000 ABD Doları, tüm işletme masraflarından bahsetmeye gerek yok, dört mühendis için iki aylık maaş ve sosyal hakları ödeyemez. Para ve zaman eşit değildir. Ayrıca dışarıdan neredeyse hiç yardım almıyorlar.
Görevi belirtilen süre içinde tamamlamak için, görevleri silme ve azaltma genel uygulamasını izlediğinizi varsayalım. Zaman kazanmak için mümkün olan her şeyi yapacaksınız. Başvuru incelemesi genellikle bir günden az sürer, ancak en kötü durumda bir hafta sürebilir veya başarısız olabilir. Bu nedenle, şu noktayı atlıyoruz: Çekirdek parti parti toplantısının personelinin uygulamayı Beta test bağlantısı aracılığıyla indirmesi gerekecek. Güvenlik incelemesi ücretsiz olsa bile, tüm önerileri uygulamak yine de çok uzun sürecektir. Güvenlik incelemesi yapmadınız. Sunucuyu tasarlarken Uygulama modelini ve logosunu yapması için tasarımcıya 1.000 $ ödersiniz. Bir tur kullanıcı testi planlayacaksınız (bu adımı daha sonra programın baskısı altında atlayabilirsiniz). Çevrimiçi olun, tekrarlayın! Her neyse, bir sonraki parti toplantısından önce düzeltebilirsin.
Ek olarak, kod yazmak her zaman beklediğinizden daha uzundur! Her zaman direnişle karşılaşırsın. Öncelikle kadro grubunun kuralları belirsiz olacak. Analog dünyaya dijital çözümler uygularken, bu her zaman olur: gerçek dünya belirsizlikler ve çelişkilerle başa çıkabilir, ancak dijital dünya yapamaz. Kadro grubu bu konular için zamanı geciktirecek kurallar çıkarabilir. Kadro grubu da kuralları son saniyede değiştirebilir. Bu, son tarihten önce uygulamayı değiştirmenize neden olacaktır. Dahası, birden fazla geliştirici ayrıca koordinasyon maliyetlerine neden olacaktır. Her kodlayıcı mobil ve sunucu geliştirmeden tamamen memnun mu? Herkes React Native'i yetkin bir şekilde kullanıyor mu? JS? Typescript? İstemci-sunucu iletişimi? Hangi çerçeve ve kitaplığı seçmeliyim? Her "hayır", koordinasyon ve öğrenme için geliştirme süresini uzatır. Kullandığınız test çerçevesinden herkes memnun mu? Başlangıçta test kodunu yazmış olsanız bile, daha sonra Uygulama değişiklikleri nedeniyle silindi.
zaman beklemez. 2 ay sonra yanan kaşlar bitiş çizgisini geçmek zorundasın.
Web sitesi ekonomik modelinde, bir yangında bitiş çizgisini geçmek iyidir. Sonuçta, yangın önemli değil, bitiş çizgisini geçtin! Sorunu birkaç hafta içinde çözebilir ve ardından bir sonraki projeye geçebilirsiniz.
Ancak Iowa'daki Kafkasya'da bu yangın çok önemlidir. Akşam, Demokrat Partinin çekirdek ekibi uygulamanın çağrısının kesilmesinden şikayet etti. Elde ettiğiniz sonuçlar imkansızdır veya yeniden rapor edilir. Kısa bir süre sonra, yazılım mühendisleri mutlu bir şekilde çizgi roman yaymaya başladılar ve Amerika Birleşik Devletleri'ndeki 2020 başkanlık seçimleri için Demokrat adayın bu uygulama için ödeme yapmaması gerektiğini ve kağıtların güvenilen tek oylama teknolojisi olduğunu söylediler.
Ne öğrendik?
Bu makale bana kişisel bir ders verdi: Bir proje planlarken, yeniden yapmanın maliyetini belirlemem gerekiyor. Geçmişte bunu sezgilerimle yapıyordum ama daha açık olmalı. Bu resmileştirme, hangi görevlerin feda edilemeyeceğini belirlemeyi kolaylaştırır. Bu geçmiş davranışımla uyumludur; eskiden mobil robotlar alanında çalışıyordum ve robot projelerinin uygulama döngüsü uzun ve arızalardan kaynaklanan kayıplar yüksek olabilir. Gözlenebilirliği artırmak ve kaçak sistemleri kontrol etmek ve sonlandırmak için kusursuz bir yöntem benimsemek için çok zaman harcadık. Tüketici web siteleri alanında da on yıl çalıştım ve başarısızlığın sonuçları daha düşük. Kısa vadeli borçları üstlenmeye ve özellikle yeniden maliyetlerin düşük olduğu ve veri kaybının olası olmadığı geçici arızalar durumunda ilerlemeye devam etmeye daha istekliyim. Ne de olsa bunu yapmaya hazırım. Sektörümüz de bu sorunları çözme becerisine sahiptir. "Premortems" bir örnektir. Bunlardan daha fazlasını yapmalıyım.
Olumlu tarafı, yazılım mühendisliği bölümünün dışındaki bazı kişiler, bazen yazılım projelerinin çok kötü ilerlediğini göreceklerdir. Hükümet süreci uygulama geliştirmedeki yatırımcılar şunu soracaklar: "Iowa parti toplantıları ile aynı durumun olmayacağını nasıl bileceğiz?" Mühendis olmayanlara mühendisleri nasıl işe alacaklarını öğretmeye çalışan bazı belgelere rastlayabilirler. Örneğin, ABD Savunma Bakanlığı, mühendis olmayanların sözleşmeleri müzakere ederken kırmızı bayrakları tespit etmeleri için araçlar sağlayan "Çevik BS Algılama" (PDF uyarısı) adlı bir kılavuza sahiptir. Girişimci forumları, mühendisleri işe alma konusunda tavsiye arayan (ve alan) teknik olmayan kurucularla doludur.
Yazılım mühendisliği endüstrisi hiçbir şey öğrenmedi. Iowa parti toplantısı bu sektöre bir fırsat verdi. "Pahalı başarısızlık maliyeti" varsayımı altında temel sürecimizi nasıl değiştireceğimizi inceleyebiliriz. Bu fırsatı yakalayamayacağız ve sonuç olarak büyüyemeyeceğiz. Tüketici odaklı yazılım mühendisliği endüstrisi, başarısızlık riskiyle baş edemez. Aslında, başarısız planları memnuniyetle karşılıyoruz. Yabancılar, belirli alanlarda kod kalitesini iyileştirmekle ilgileniyorlarsa, bu alanları izlemelidirler. İlk olmayacak: Sağlık Sigortası Taşınabilirlik ve Sorumluluk Yasası (HIPAA) ve Sarbanes-Oxley, web sitesi ekonomik model şirketlerinin mühendislik teknolojisini etkileyen düzenlemelerin örnekleridir. Gözetim yeterli olmaktan uzak olabilir, ancak bu gereklidir.
Ama evet. Demek istediğimiz bu: " Bunu nasıl yapacağımı bilmiyorum ama tüm alanımız yaptığımız işte iyi değil Bize güvenirseniz herkes ölecek. " Sektörümüz, başarısızlığın maliyetinin küçük olduğu ve hızlı aksiyonun teşvik edildiği bir ortamda büyüyor. Ancak, yeniden yapmanın maliyeti yüksek olduğunda veya yineleme imkansız olduğunda, bu süreçler kümesi çalışmayacaktır.
Orijinal bağlantı:
https://www.bitlog.com/2020/02/12/why-are-we-so-bad-at-software-engineering/
Bu makale CSDN tarafından derlenmiştir, lütfen yeniden basım kaynağını belirtin.
