BT endüstrisi neden diğer endüstrilerde olduğu gibi hızlı ve büyük projeler sunamıyor?

National Geographic'in MegaStructures serisini izledikten sonra , büyük projelerin ne kadar hızlı tamamlandığına şaşırdım. Ön çalışmalar (tasarım, özellikler vb.) Kağıt üzerinde yapıldıktan sonra , büyük projelerin gerçekleştirilmesi sadece birkaç yıl veya bazen birkaç ay sürer .

Örneğin, Airbus A380 "19 Aralık 2000'de resmen başlatıldı" ve "2005 Mart ayı başlarında" , uçak zaten test edildi. Aynı şey büyük petrol tankerleri, gökdelenler vs. için de geçerli.

Bunu, yazılım endüstrisindeki gecikmelerle karşılaştırarak, çoğu BT projesinin neden bu kadar yavaş ya da daha kesin olduğunu merak ederek, neden yeterince hızlı ve hatasız olamayacaklarını, aynı ölçekte yeterli insanlara verildiğini anlayamıyorum?

Airbus A380 gibi projeler her ikisinde de mevcut:

• Öngörülemeyen başlıca riskler: Bu ilk yapılan uçak olmasa da, yine de teknolojinin sınırlarını zorluyor ve daha küçük uçaklar için iyi çalışan şeyler, fiziksel kısıtlamalar nedeniyle daha büyük olan için işe yaramayabilir; Aynı şekilde, henüz kullanılmayan yeni teknolojiler kullanılıyor, çünkü Boeing 747'nin yapıldığı 1969'da mevcut değildi.

• Genel olarak insan kaynakları ve yönetimle ilgili riskler: projenin ortasında bırakan insanlar, tatildeyken birine ulaşamama, normal insan hataları vb.

Bu risklerle insanlar çok kısa sürede bu büyük uçakları gibi projeleri başarmakta ve teslimat gecikmelerine rağmen, bu projeler hala oldukça başarılı ve yüksek kalitededir.

Yazılım geliştirmeye gelince, projeler bir yolcu uçağı kadar büyük ve karmaşık değildir (hem teknik olarak hem de yönetim açısından) ve gerçek dünyadan öngörülemeyen riskleri biraz daha azdır.

Yine de çoğu BT projesi yavaş ve geç kaldı ve projeye daha fazla geliştirici eklemek bir çözüm değil (on geliştirici ekibinden iki bine geçmek bazen projeye daha hızlı, bazen değil, bazen de zarar verecek Projeyi tamamlayıp tamamlamama riskini arttırın).

Halen teslim edilenler genellikle ardışık servis paketleri ve düzenli güncellemeler gerektiren birçok hata içerebilir (böcekleri orijinal ürüne yapıştırmak ve uçağın çarpmasını önlemek için haftada iki kez her Airbus A380'de "güncellemeler kurmayı hayal edin").

Bu farklılıklar nasıl açıklanabilir? Özel olarak, yazılım geliştirme endüstrisinin büyük ölçekli, neredeyse kusursuz ürünleri çok hızlı bir şekilde teslim etmek için binlerce kişiyi tek bir projede yönetebilmek için çok genç olması nedeniyle mi?

Ed Yourdon'un Ölümü March , bu meta tipi soruların bir kısmına değiniyor.

Genel olarak, yazılım endüstrisi büyük projelerle karşılaşan pek çok şeye sahip değil.

• Standardizasyon ve iş öğesi dökümü.

  • Bu kesinlikle daha iyi bir hale geldi, ancak tasarım yapıları hala büyük bir sistemi parçalamak için orada değil. Bazı açılardan, yazılım belirli bir proje için neyin gerekli olduğu konusunda hemfikir olamaz, bu sayede işleri parçalara ayırabilir .
  • Havacılık, bina inşaatı, otomobil vb. Hepsi tamamen paralel gelişime izin vermek için oldukça sıkı arayüzlere sahip çok bileşen odaklı mimarilere sahiptir. Yazılım hala ilgili alanlarda çok fazla kanamaya izin veriyor.

• Başarılı, benzer projelerden oluşan geniş bir yapı. A380 , Airbus'un inşa ettiği ilk büyük uçak değildi . Dışarıda pek çok büyük yazılım uygulaması var, ancak birçoğu veya başka yönleriyle çarpıcı biçimde acı çektiler ve “başarılı” olarak adlandırılmaya yaklaşamadılar.

• Çok sayıda benzer ve başarılı projede çalışan geniş bir tasarımcı ve inşaatçı grubu. Başarılı proje sorunuyla ilgili olarak, orada bulunan insan yeteneğine sahip olmamak, işleri tekrarlanabilirlik açısından çok zorlaştırır.

• "Asla" aynı şeyi iki kez inşa etmeyin. Birçok yönden, bir uçak diğer herhangi bir uçak gibi. Kanatları, motorları, koltukları vb. Var. Büyük yazılım projeleri nadiren kendilerini tekrar eder. Her işletim sistemi çekirdeği önemli ölçüde farklıdır. Dosya sistemlerindeki eşitsizliklere bakın. Ve bu konuda, kaç tane benzersiz benzersiz işletim sistemi var? Büyük olanlar bir noktada temel bir maddenin klonları haline gelir. AIX , Solaris , HP-UX , ... tekrar AT&T System V'ye haber veriyor . Windows, her bir yinelemede inanılmaz miktarda sürükledi. Linux değişkenleri genellikle hepsi Linus'un başlattığı aynı çekirdeğe geri döner. Bunu ortaya koyuyorum, çünkü varyantlar gerçekten eşsiz, patentli işletim sistemlerinden daha hızlı yayılma eğilimindedir.

• Gerçekten kötü proje tahmini. Tekrarlanabilirlik faktörü çok düşük olduğundan, ne kadar büyük olacağını ve bir şeyin ne kadar uzun süreceğini tahmin etmek zordur. Proje yöneticileri ve Yönetim'in ellerini koyamayacağı ve gerçekte ne yapıldığını göremediği göz önüne alındığında, zaman çizelgelerine ilişkin gerçekçi olmayan beklentiler ortaya çıkıyor.

• KG / KK, daha büyük projeler için olması veya olması gerektiği kadar vurgulanmamaktadır. Bu, bileşenler arasında daha gevşek arayüzlere sahip olmak ve bileşenlerin nasıl çalışması gerektiğine dair katı özelliklere sahip olmamaya dayanır. Bu gevşeklik, istenmeyen sonuçlara ve böceklerin içine sızmasına izin verir.

• Sürekli ölçülebilir nitelikler. Genel olarak, insanlar X dilinde veya programlamada çalıştıkları yıllardan bahseder. Zaman, kalibre veya beceri kalitesinin yerine geçiyor. Daha önce birçok kez bahsedildiği gibi, iyi programlama yeteneği ile röportaj yapmak ve bulmak zordur. Sorunun bir kısmı “iyi” tanımının çok öznel kalmasıdır.

Negatif olmak istemem ve sanırım yazılım endüstrisi bulunduğumuz yerden önemli adımlar attı. Bu gibi forumlar ve diğerleri, tasarım ilkelerinin konuşmasını ve tartışılmasını desteklemeye gerçekten yardımcı oldu. Yazılım mühendisleri için "temel" bilgiyi standartlaştırmaya çalışan kuruluşlar var. Kesinlikle iyileştirmeye yer var, ancak sektörün oldukça kısa bir süre içinde uzun bir yol kat ettiğini düşünüyorum.

Cevap şaşırtıcı basit: o 'diğer sektörlerde' do yüksek başarısızlık oranı vardır. Sadece yanlış şeyleri karşılaştırıyoruz. Yazma yazılımı genellikle 'inşa' olarak adlandırılır ve bu yüzden diğer endüstrilerdeki üretim veya inşaat aşamalarıyla karşılaştırırız. Ama eğer bakarsanız, hiç inşaat değil: tasarım . Yazılım tasarımları kodla yazılır ve yazılım derleme veya anında yorumlama yoluyla bilgisayarlar tarafından yapılır.

Diğer endüstrilerdeki birçok tasarım ya tahmin edilenden daha uzun sürüyor, daha pahalıya mal oluyor ya da hiç bitmiyor. Tanıdık geliyor mu?

Peki, yazılımı planlarken ne yapıyoruz? Hala tasarlıyoruz ama daha erken bir aşamada.

Yazılımda, üretim notu yoktur. Nihai bileşenin oluşturulması (nispeten) ucuzdur ve bu nihai ürünün kopyalanması hem mükemmel hem de etkili bir şekilde ücretsizdir - yapı eserlerini kopyalarsınız.

Bazı rakamlara işaret etmek:

1. Uygulama başladıktan sonra gereksinimlerin değişimi ; örneğin, ilk Airbus A380 fabrikada yaratılmaya başladığında, eğer biri 200 daha fazla koltuk isterse, bunların oraya konacağına inanamıyorum; ancak büyük bir yazılım projesinde programcılar geliştirmeye başladıktan sonra bile 5 kullanıcı daha eklenebilir.
2. Karmaşıklık - büyük yazılım projeleri son derece karmaşıktır; muhtemelen tasarlanan ve geliştirilen en karmaşık projeler;
3. Mimarlık ve tasarım aşamasında yeterli kaynak harcanmıyor ;
4. Alan olgunlaşmamışlığı - yazılım mühendisliği, diğer mühendislik kız kardeşleriyle karşılaştırıldığında nispeten genç bir disiplindir; Bunun iki sonucu vardır: a) Çok fazla buluşsal ve iyi uygulama yoktur; b) Çok fazla deneyimli uzman değil;
5. Matematiksel kanıt eksikliği - çoğu durumda matematiksel biçimsel yöntemler bir yazılımın gerektiği gibi çalıştığını kanıtlamak için kullanılmaz; bunun yerine test kullanılır. Bu, matematiğe daha çok güvenen diğer mühendislik alanlarında da geçerlidir; Bunun nedeni karmaşıklık kadar;
6. Rush - birçok menajerin ulaşılmaz süreleri var; bu nedenle son tarih nedeniyle kodun kalitesi ikinci sıradadır.

Kesinlikle soruya cevap vererek - diğerlerinin programcılardan (özellikle teslimat zamanında) çok yüksek beklentileri olduğuna ve büyük yazılımların ne kadar zor programlandığını tam olarak anlamadıklarına inanma eğilimindeyim.

Sorunun öncülü biraz kusurlu. Hem A380 hem de Boeing 787 yıllar sonunda teslim edildi.

A380 durumunda gecikme, CATIA tasarım yazılımının farklı ve biraz uyumsuz versiyonlarını kullanarak Fransız ve Alman Airbus birimlerinden kaynaklandı . Bu uyumsuzluk kendisini uçağa tam olarak uymayan kablo demetleri olarak gösterdi.

En yaygın kullanılan uçak tasarım yazılımı olan CATIA ile ilgili yanlış bir şey yoktu, ancak birileri yazılım yapılandırma topunu düşürdü.

Boeing 787 ayrıca yazılımla ilgili gecikmelerden de muzdarip, ancak problemlerinin çoğu ağırlık kontrolü ve standart altı parçaların tedarikçiler tarafından teslim edilmesi gibi daha geleneksel yeni uçak problemleriydi.

Hem A380 hem de B787, ilk uçakta yapısal sorunlar yaşandıktan sonra kanat tasarımlarını değiştirmek zorunda kaldı.

Tüm alanlarda insanlar için büyük karmaşık projeler zordur.

Burada gökdelen adam. Sorunuza cevap verebilir miyim bilmiyorum ama kesinlikle konudaki çeşitli öğelere ışık tutabilirim. Binalar gerçekten çok hızlı gerçekleşiyor. Büyük bir kısıtlama yerel (düzenlemeler). Ancak genel olarak, yüksek bir binanın başından sonuna kadar 3 ila 10 yıl sürer.

Yeni bir bina ile yeni bir yazılım projesini karşılaştırmanın çok doğru olmadığını düşünüyorum. Yeni bir bina, bir çekirdeğin veya işletim sisteminin yeni bir sürümüne daha yakındır. Bu bakımdan yazılım geliştirme çok daha hızlıdır. Müşteriden asla kaydolan yüksek riskli bir görev olacağından asla sıfırdan inşa etmeyiz. Binalarda tasarım ve geliştirme çalışmalarının çoğu, kanıtlanmış ve tamamlanmış projelerin türevidir.

Kişisel deneyimden, her on projeden sadece biri inşa edilebilir. Süreç tasarım odaklı olmaktan ziyade geliştirme odaklı, yani çelik fiyatı gibi bir şey tüm proje artarsa, tasarım sürecin en ucuz bileşeni olduğu için pencereden çıktı ya da tasarlandı.

Tasarım konseptin şematik olması, tasarım geliştirme için iki ila altı ay, bir mimar ekibi, planlama danışmanları, yapı mühendisleri, rüzgar mühendisleri, hizmet mühendisleri, miktar ve maliyet danışmanları, sörveyörlerin detaylarına ve inşaat belgelerine altı ay daha erişilebilirlik mühendisleri ve liste devam ediyor ...

Sanal olana karşı fiziksel argüman çok kesin değil. Ayrıca esas olarak sanal araçlarla çalışıyoruz ve ayrıca son ürünümüzden hem zaman hem de ölçek uzaktayız. Çoğu durumda mockup ölçeğinde binaların özelliklerini bile test edemiyoruz ve ne olabileceğini tahmin etmek için simülasyonu kullanıyoruz.

Karmaşıklık bakımından farklılıklar var, ama genel olarak belki de aynı. Sadece birbirimizle ilişkili birimlerimiz ve çoklu seviyeli soyutlamalar ve arabirimler seviyelerimiz yok, aynı zamanda insanlar iletişimi zorlaştıran sürecin küçük bölümlerinde çok uzmanlaşmıştır.

Tasarım ve geliştirme argümanına gelince, bence her iki süreç de tasarım temelli. Bunları birbirinden ayırmak akademik olarak güzel görünüyor ama işlerin nasıl yürüdüğünü bilmiyorsanız tasarım yapmak mümkün değil. Sadece başarısızlık riskini arttırıyorsunuz.

Genel olarak, OP'nin sorusuna göre (potansiyel olarak yanlış) olan tahminim, programlamanın mühendislikten çok bir sanat olduğunu gösteriyor. İnsanlar neden zevk alır ve hatta bedavaya alır, ifade ve zarafet bulurlar? Bilgisayar bilimi aynı zamanda (kalayda olduğu gibi) mühendislikten çok bir bilimdir. Neden sadece mevcut parçaları birleştirmek yerine algoritmaları ispatlamaya çalışıp işleri daha iyi hale getirmeye çalışıyorsun? Bunun bir anlamı olup olmadığından emin değil; Ben yazılımcı değilim.

Yazılım tasarımı ve geliştirmesiyle beni etkileyen bir husus, medyanın kendisiyle ilgili. Bilgisayarlar insan merkezli çalışmaları çok doğal yapıyor. Her şey çok açık ve çok az tolerans var. Bu yolla zihinsel olarak çalışmak zordur ve bazıları içeride karmaşıklığı boşa harcayarak onunla kurtulun. Başka hiçbir şey yapmazsa bunun bununla bir ilgisi olabilir mi?

O zaman bunların tasarımı ne kadar sürdü? Yıl? İki? On yıl? Tasarım bir şeyi inşa etmenin en karmaşık kısmıdır, yapımın kendisi kolaydır.

Bu makaleye dayanarak, yazılım geliştirmenin çoğunlukla tasarım belgesinin kaynak kodun kendisi olduğu tasarım süreci olduğu yavaşça anlaşılmaktadır. Ve tasarım süreci, üretim sürecinden tamamen farklıdır. Tecrübeli insanlar gerektirir ve planlaması mümkün değildir, çünkü küçük ihtiyaç değişiklikleri bile projenin genel mimarisinde büyük değişikliklere neden olabilir. Bu anlayış, son tasarım belgesi olarak kod kalitesini iyileştirmeye ve tıpkı rüzgar tünellerinde uçak modellerini test ettikleri gibi tasarım sürecinin bir parçası olarak test ve hata ayıklamaya odaklanan çevik metodolojilerin temelidir .

Yapının kendisi derleyiciler tarafından otomatik olarak yapılır. Ve bu sayede bütün ürünleri birkaç dakika içerisinde üretebiliyoruz.

Yazılım projelerinin büyük gecikmelerle ve şişirilmiş maliyetlerle bitmesinin nedeni, yöneticilerin hala böyle bir tasarım sürecini tahmin edebileceklerini, tahmin edebileceklerini ve planlayabileceklerini düşünmeleridir. Bu gerçekte geçerli olduğundan daha sık geri tepti. Yine de, insanları katı bir inşaat sürecine bağlayarak, sonuçta çoğunlukla artan maliyetlerin ve kaçırılan son teslim tarihlerinin tersi olmasına rağmen, bir şekilde kaliteyi artırabileceklerini düşünüyorlar.

Airbus A380'in tasarımının ortasında birisinin bir toplantıya katıldığını ve "Heh, üçlü uçak olarak inşa edebilir mi?" Dedi. Diğerleri de "Evet, evet. Üç kanatlı. Daha fazla kanat daha iyi." Gelecek yıllar, A380 tasarımını üçlüye dönüştürmek için harcanıyor. Başka bir toplantıda, biri, "Üçlü bir uçak mı? Bu eski. Bir çift kanatlı istiyoruz. Sadece kanatlardan birini çıkarın." Der.

Ya da bir köprü inşaatı projesinin ortasında birileri, “Heh, biz sadece bir nakliye firması ile anlaşma yaptık. Köprüden 40 fit daha yüksek olmaları gerekiyor, çünkü gemileri çok daha uzun. Onları düzelt.” ."

Bunlar, irili ufaklı yazılım projelerinin endişe verici oranda başarısızlıkla sonuçlanmasının sebeplerinden bazılarıdır.

BT'de çalışan makine mühendisliği geçmişine sahip biri olarak, BT'de düşük başarı oranının nedenlerini merak ettim.

Bu konudaki diğerleri gibi ben de sık sık BT'nin olgunlaşmamasına, detaylı standartların olmamasına (evet, ben ciddiyim, basit bir cıvatanın standart sayfasını kontrol ettiniz mi?) Ve standardize olmadığına bağladım. bileşenler ve modüller.

Bina inşası veya gemi inşası gibi diğer endüstriler de çok daha fazla "dövülmüş patikaya" sahiptir: -özelleştirilmiş biçimde- tekrar tekrar kullanılan belirli bir çözüm prototipinin bilgisi ve deneyimi. Farklı boyut ve amaçtaki binaların, gemilerin veya uçakların neden bu kadar benzer göründüğünü hiç merak ettiniz mi? (elbette kuralın istisnaları var ...)

Bunun nedeni, bu prototiplerin iyi araştırılmış, iyi anlaşılmış, genel olarak kullanılmış ve kanıtlanmış bir sicile sahip olmasıdır. Başka türlü yapılamadığı için değil. BT standardizasyonunda nadiren durum söz konusudur: (büyük) projeler aynı anda ve aynı insanlarla aynı anda araştırma ve teslimat yapan bileşenleri yeniden icat etme eğilimindedir !

Bunlar kaçınılmaz olarak geliştirilmesi ve servis edilmesi pahalı olan bir kereye mahsus ürünlere yol açmakta ve hataya açıktır ve belirsiz koşullarda öngörülemeyen şekillerde başarısız olmaktadır. Ve bu nedenle, elbette, bu ürünler çok daha eski, yazılmakta ve eşit derecede büyük maliyetlerle sadece biraz daha iyi ürünlerle değiştirilmektedir. BT ihtiyacı, orta çağ esnafını verimli fabrikalara dönüştüren endüstriyel devrime eşdeğerdir.

Bununla birlikte, BT'yi gerçekten benzersiz kılan faktörler var. Bahsedilen diğer sektörlerin aksine, BT gerçekten her yerdedir: modern yaşamımızın her alanında kullanılır . Bu, BT'nin bu kadar ilerlemesini sağladığı ve yaptığı sonuçları sunma yeteneğine sahip olduğu küçük bir mucize.

Korkarım ifadenize katılmıyorum.

Airbus ve Boeing, uçak yapan şirketlere iki örnektir. Uçak yapan kaç firma var? Çok az, kaç şirketin yazılım ürettiği ile karşılaştırırsanız.

Bir yazılım projesini vidalamak için bir uçak projesini vidalamak da aynı derecede kolaydır. Uçak giriş endüstrisinde, yazılım endüstrisinde olduğu gibi, yalnızca giriş engeli çok düşükse, birçok başarısız uçak projesini göreceksiniz.

Arabalara bakın; Çok dayanıklı ve son derece gelişmiş otomobiller üreten yüksek kaliteli üreticiler (Think Land Rover, Mercedes) var ve onları tamir etmek zorunda kalmadan bir yıl dayanamayacak otomobiller yapanlar var (Kia veya Cherry'yi düşünün). Bu, biraz daha düşük giriş engeli olan bir sektör için mükemmel bir örnek, daha zayıf oyuncular almaya başladınız.

Yazılım farklı değil. Öte yandan, çok sayıda buggy ürününüz var, Windows, Office, Linux, Chrome veya Google Arama, zamanında teslim edilen ve uçakla aynı kalitede olan çok yüksek kaliteli projeler.

Birçok insanın özlediği diğer nokta, bir araba, bir tanker veya bir yaşam gerçeği olarak gördüğümüz bir uçağın bakımına ne kadar bakım yapılması gerektiği. Her uçak kalkıştan önce teknik bir kontrolden geçmelidir. Aracınızı her birkaç kilometrede bir kontrol etmeniz ve yağ değişimi, lastik değişimi gibi düzenli işler yapmanız gerekir.

Yazılımın da buna ihtiyacı var. Yalnızca insanlar tanılama, önleme veya denetleme yazılımının durumunu ve kalitesini mekanik / fiziksel ürünlerle olduğu kadar uzun süre harcarsa, bunun gibi daha az açıklama beklerdim. Başlatmadan önce uygulamanızın günlüklerini okuyor musunuz? Peki .. eğer bir uçak olsaydı ;-)

Dijital yapı taşları 1 veya 0 olabilir.

Mekanik bir tasarım, tolerans seviyesine sahiptir. Mükemmel perçinlerden daha azını bir köprüye koyabilirim ve büyük olasılıkla düşmeyecektir, ancak bir kez bile bir 1'in tüm programda başarısız olabileceği bir 0 koyma örneği bile koda düşebilir.

Hesaplamanın mantıklı ve etkileşimli olması nedeniyle, herhangi bir küçük değişiklik bile olsa ciddi başarısızlığa neden olabilir.

Sık sık aynı şeyi merak etmişimdir. Kesinlikle (zaman zaman) ne yaptığımız hakkında hiçbir fikri olmayan bir grup amatör gibi hissediyoruz . Yöneticileri veya diğer dış etkenleri suçlayan açıklamalardan hoşlanmıyorum - biz geliştiricilerden yarattıklarımızdan sorumlu olmalıyız.

Hataların ucuz olduğu bir işte olduğumuzu düşünüyorum . Yama yazılımı bir gökdeleni yeniden inşa etmek veya satılan her cep telefonunu geri çağırmakla karşılaştırıldığında ucuzdur.

Bu, böceklerin günlük yaşamın bir parçası olduğu bir kültür yarattı . Bir omuz silkme ile kabul edilirler. Bazı hatalar muhtemelen kaçınılmaz olsa da, günlük çalışmamıza hâkim olmalı mı? QA'nın sorun olmaya değdiğini hissetmeyen yöneticileri tamamen anlıyorum, çünkü tam olarak böcek beklemiyorlar. Hatasız kod üretmek için her türlü çabayı göstermeyen programcıları anlamıyorum, çünkü hataları düzeltmek çok sıkıcı.

Temelde bunun bir kültür sorunu olduğuna inanıyorum ve değişeceğini umuyorum.

Mühendislik standartları ve uygulamaları BT'de (bağımsız bir endüstri olarak) havacılık sektöründen çok farklıdır . Bu belki de en kolay, BT uzmanlarının havacılık alanındaki standart belgelerle karşılaştığında nasıl tepki verdiklerini düşünerek anlaşılıyor . Örneğin, son zamanlarda İnternet'te dolaşan Joint Strike Fighter C ++ Standartları .

Birçoğu, eğlence veya hevesli istifalarını dile getirir (bu şekilde yapabilmeyi isterdim); ve çoğu, tüketici ürünlerini bu şekilde teslim etmenin pratik bir yolu olmadığını iddia ederek alay etmeye yanıt veriyor. Bu, tüketicilerin değil yönetimin beklentileri göz önüne alındığında bile doğru olabilir. Birkaç hafta boyunca sadece kodlayan ve kodlayan, hiçbir şeyi demonte etmeyen kodlayıcılar için büyük bir güvensizlik var. Tanrı, sadece iki haftalığına bir şeyler tasarlayan kodlayıcıya yardım eder . Uçaklarda öyle değil.

Yazılımda, insanlar gerçekten şu anda bir şey olmasını bekliyorlar. Tabii, mantık devam ediyor, gerçekten sağlam olması biraz zaman alacak; ama bir hafta içinde basit terimlerle anlatılan karmaşık bir şeye sahip olamaz mıyız ? Ayrıca, dürüst ve karmaşık terimlerle açıklanan karmaşık şeylerin hayal gücünü nadiren heyecanlandırdığını; ve bu nedenle birçok mühendis, basit şeylerin yaratıcı bir şekilde bir araya getirilmesi hayali bir dünyada suçluluk duyuyor (zor işlerin yapıldığı bir dünyanın aksine).

Benden bir şeyler:

1- Standartlar ve parçalar: Uçak üreticisi , geliştirici değil. Tamamen emin değilim, ama tahminimce bir çok parça dış kaynaklı. Kendi elektronik / enstrümanlarını yapmıyorlar, bir şirketten koltuk alıyorlar, motorlar muhtemelen başka bir yerde geliştiriliyor, vs.

Yazılım projeleri ise, hemen hemen her zaman sadece bazı küçük çerçeveler / yardımcılar ile sıfırdan başlar.

2- Pazara girme zamanı: Uçaklar için zaman kritik bir konu değil. Bahse girerim Airbus'un tasarımı bitmeden yıllar önce tamamlanmış ve o dönemde gerçekleşebilecek her türlü büyük atılımı ihmal etmeyi seçmişlerdir. (Araba üreticileri için aynı, örneğin, şu anda geliştirdikleri en son teknoloji 5-10 yıl içinde sokaklara vuracak.)

Yazılım için çok çevik olmanız gerekiyor, şimdi büyük bir projeye başlarsam ve herhangi bir değişiklik yapmadan geliştirmek için üç yıl sürersem, şansım oldukça yüksek, artık mevcut olmayan teknolojiye güveniyorum ya da ürünüm tamamen modası geçmiş. Bu da çok fazla sorun sunuyor.

3- Serbest bırakma döngüsü ve sürümleri. - Bir uçak "serbest bırakıldığında" tamamen bitmesi gerekir. Gecelik sürümlerde veya benzeri sürümlerde kararlı beta sürümleri yoktur. Ek olarak, bir kez yapıldığında, sadece küçük bir şekilde değiştirilebilir. Mevcut bir boeing'e 100 koltuk ek bir seviye ekleyemezsiniz, bu mümkün değildir.

Öte yandan, yazılım genellikle yalnızca “işe yarayan” ancak artması gereken ürünleri tamamlamayan artımlı değişikliklere sahiptir. Ayrıca, BT’de "ek olarak, 50 ton daha ekleyen uçağımıza başka bir bagaj bölmesi ekleyelim" demek sıra dışı değil.

Bence cevap oldukça basit:

1) Fiziksel inşaat ve uygulama, insanlar olduğu sürece buralarda olmuştur - fiziksel projelerin uygulanması için yöntem ve tekniklerimizi geliştirmek için binlerce yıldır. Tamamen yeni ve farklı bir beceri seti gerektiren yazılım 'inşaatı' 50 yıldan daha eski değil - henüz yeterince zamanımız olmadı.

2) Sanal yapı daha zordur - aklınızda herhangi bir fiziksel gerçekliğe sahip olmayan şeyleri 'görmek' zorundasınız. Ürününüzün neye benzemesi gerektiğini ve onu oluşturmak için atması gereken adımları bilmeden önce birçok bilgiyi analiz etmenizi ve özetlemenizi gerektirir. Bir köprü veya bina inşa ederken öyle değil.

3) Bir yazılım arızasının veya hatanın kaynağını bulmak, fiziksel mühendislik yaparken olduğundan çok daha zordur. Eğer bir kiriş sıkışırsa, burkunun nerede olduğunu görüyorsunuz ve onu tutan ve arızalanan destekleri görüyorsunuz, vb. Fiziksel yapıların olduğu gibi fizik ve matematik yasaları.

Jack Ganssle'ın gömülü muse'undan bir makalenin yazılı bir kopyasını kullanarak cevap vermeye çalışacağım. Bu her yerde firmware olduğunu söylese de, zihinsel olarak onu yazılımla değiştirin.

Neyle karşılaştırılmış?

Firmware, evrendeki en pahalı şeydir. Eski Lockheed Martin CEO'su Norman Augustine, "Augustine Yasaları" adlı harika kitabında, savunma topluluğunun karşılaştığı bir sorun hakkında açıklayıcı bir hikaye anlatıyor. Yüksek performanslı bir savaş uçağı, birbiriyle çelişen ihtiyaçların hassas bir dengesidir: yakıt menzili - performans. Hıza karşı ağırlık. 70'lerin sonunda savaşçıların eskisi kadar ağır olduğu görülüyor. Her zaman daha büyük karlar peşinde koşan müteahhitler, çok fazla maliyet katabilecekleri, ancak hiçbir şey ağırlamadıkları için boşuna bakıyorlardı.

Cevap: bellenim. Sonsuz maliyet, sıfır kütle. Aviyonik artık savaşçının maliyetinin yarısından fazlasını oluşturuyor. En son Amerikan dövüşçüsü F-22'yi göz önüne aldığınızda, bir milyar insanın havalesinin üçte birine mal olduğunu düşündüğünüzde bu büyük bir değişiklik. Augustine, bu hikayeyi anlattığı zaman, neredeyse neşeyle boğuşuyor.

Fakat yazılım neden bu kadar pahalı? Tom DeMarco bir kez bu soruyu şu üç kelimeyle cevapladı: neye göre? Göreceli olarak sıkıcı iş vakalarını tartışmaya devam etti, ancak bu cevap aklımda yıllarca yankılandı. Neyle karşılaştırılmış? Yazılım ile rutin olarak benzeri görülmemiş karmaşıklıkta ürün davranışları yaratıyoruz. Elbette, kod pahalıdır. Fakat asla medeniyet tarihinde hiç kimse bu kadar karmaşık bir şey inşa etmedi.

Vikipedi'den utanmadan kaldırılan ve doğruluk açısından kontrol edilmeyen şu kabarcık türünü göz önünde bulundurun:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

110 tane boşluksuz karakter, belki de bir veya iki saat içinde attı. Yazılımımız olmadığını ve başka bir strateji kullanarak bir sıralama yapmak zorunda olduğunu varsayalım. Neye mal olacak?

Bir makine mühendisi, mesleğinin bilgisayarlardan çok önce sıralayıcılar yaptığını söyleyebilir. IBM'in 1949 dönemi modeli 82 kart sınıflandırıcı (düşünün http://www.columbia.edu/acis/history/sorter.html bir 4 MHz üzerinde bile yönetmek olabilir bizim kod parçacığı yerine daha az dakikada 650 kartları, işlem hacmi ile) Z80. Tabii ki, model 82 bir seferde bir kartın sadece bir sütununu sıraladı; bir güverte tamamen sıralamak için onlarca pas alabilir.

Bu canavarı tasarlayıp inşa etmek ne kadar sürdü? Yıllar, şüphesiz. Ve işlevselliği, çok daha hızlı olan ve devasa veri kümeleriyle başa çıkabilen kodumuza göre değişir. Fakat bu 1949'du. Elektronik bileşenlerden bir kabarcık türünün FPGA ve VHDL olmadan ya da bir CPU olmadan yapılması ne kadar sürer?

Bir saat içinde, yonga seviyesinin üstünde bir blok blok diyagramı yönetmiştim (bloklar "adder", "16 bit mandal" ve benzeri gibi isimlere sahiptir). Ancak sıralama mantığı açıkça oldukça dağınık olduğundan, bir noktada uygun denklemleri yazmanın çok zor olmadığını varsayarak bir PLD'ye atıldım. Ve, evet, belki de programlanamaz mantık kuralını ihlal eden, ancak herhangi bir makul süre içerisinde kapıları kullanarak tüm bu mantığı tasarlayıp hata ayıklamak, galon gazı gibi bir ihtimal değildir.

16 bit kelime ve adres varsayarak, devrenin bir düzine 16 bit mandal, adders ve benzerine ihtiyacı olacaktır. Artı hafızası. Sıralanmamış verilerin RAM'e nasıl ulaştığı veya sonuçların nasıl aktarıldığı hakkında hiçbir fikrim yok. Bunlar belirtilmemiş tasarım gereksinimleridir. Yalnızca yazılım çözümü, yalnızca işlev prototipini yazarak bu gereksinimleri doğal olarak çözer.

Kaba blok diyagramın şemasına çevrilmesi bir gün sürebilir. Daha sonra bir PCB tasarlama ve üretme, parça sipariş etme ve yükleme (ve beklenmedik ancak kaçınılmaz yaşam sonu sorunları ile başa çıkmak için tasarımını değiştirme) ve daha sonra elbette devre çalışmasını sağlayın. Kurul, parçalar ve uygun test ekipmanları için haftalarca çaba ve paradan bahsediyor olabiliriz.

Bütün bunlar 7 küçük kod satırını değiştirmek için. Çok az gerçek gömülü program 10.000'den az; çoğu bir milyonu aştı. Gerçek, süper boyutlu bir bilgisayar programının yerini almak için ne kadar donanım ve ne kadar mühendislik gerekir?

Elektronik tablo gibi gerçek bir program düşünün. Bir işlemcisiz bir işlem yapmak için ne kadar devre gerekir? Bir şehrin büyüklüğü olabilir.

Bellenim, evrendeki en pahalı şeydir, ancak yalnızca çözdüğü sorunların hayal edilemez karmaşıklığı nedeniyle. Ancak, alternatiflerden çok daha ucuz. Patronunuz sinir bozucu bir şekilde yazılımın neden bu kadar uzun sürdüğünü sorduğunda ne söyleyeceğinizi biliyorsunuz. Neyle karşılaştırılmış?

Bu yüzden orada! Yazılım / bellenim benzersiz bir karmaşıklığa sahiptir.

Yazılım mühendisliği ve yönetimi temel olarak diğer pek çok mühendislik alanından farklıdır. Çıktıların fiziksel değildir ve üretim süreci olan tasarım ve geliştirme süreci. Bir yazılımın başka bir kopyasını oluşturmak, esasen sıfır marjinal maliyete sahiptir; tüm masraflar ilk kopyanın geliştirilmesinde bulunur.

Bir yazılım disiplini olarak göreceli yazılım mühendisliği ve yönetimi gençliği nedeniyle, yazılım geliştirme ve mühendisliği bir bütün olarak engelleyen bazı gerçekler (yanlış referanslar ) var ( bu referansa bakınız ).

Tüm geliştiriciler eşit olarak yaratılmaz. Bazıları iyidir, bazıları değildir.

Söylediklerimi öğrenmek için her zaman diğer kişilerin kodlarını okumayı deneyin. Çok fazla ekstra mantık ifadesi risk ekleyebilir. Bu riskler hasta davranışlara veya hatalara neden olabilir. Yeterli mantık ifadesi yok ve artık boş referanslarınız var. İyi programcı bunu anlar ve ne ve ne zaman yapacağını bilir. Ama kimse mükemmel değil. Her şey karmaşık. Başkalarının kötü düşünülmüş çalışmalarını ekleyin ve projelerin nasıl tükendiğini görmek kolaydır.

Katedrallerin yapımı 100 yıl kadar sürüyordu.

Bazı Airbus uçaklarının çalışması için 1 milyon satır kod gerekiyor.

Bir şeyi ne kadar çok geliştirirseniz, o kadar çok gelişme elde edersiniz, bu nedenle yazılım endüstrisine daha iyi hale gelmeleri için birkaç yüzyıllık deneme hatası verin. veya kusurları.

Büyük projeler genellikle büyük kuruluşlarda gerçekleşir. Daha önce hiç bir zaman büyük bir organizasyonda çalışmadıysanız, performansı ve üretkenliği öldürmenin garantisi olan bir şey var: bürokrasi.

Şaşırtıcı bir şekilde, birçok kişi bürokrasinin ne olduğunu bilmiyor (genellikle politika ile karıştırılıyor), hatta bir bürokrasi problemi olsa bile.

Kısa süre önce akıllı kart kimlik doğrulaması için bir proje tamamladık. Başlangıçta üç ayda tahmin edildi. 15 ay sürdü. Gecikmenin maliyeti, bütçesi, kapsamı veya teknik sebepleri yoktu. Kapsam aslında oldukça dardı - yalnızca ayrıcalıkları yüksek olan hesaplar (yönetici hesapları), yaklaşık 1.200 hesap.

Bir diğer önemli faktör, iş ortaklarınızdır. Bu satıcıları içerir. Ortaklarınızın projenize gecikme getirecek bir sorunu varsa, gecikme sorununu çözecek pek bir seçenek yoktur. Doğrudan sizin için çalışmazlar ve bir kişiyi neden olabilecek bir kişiden kovamayabilirsiniz. İş ortağı işten atılabilir veya maddi cezalara veya dezavantajlara maruz kalabilir, ancak bu, projenin gecikmesine neden olduğu gerçeğini değiştirmez. Boeing'de Boeing 787 Dreamliner ile bir mamut tedarik stratejisi uyguladıklarında gerçekleşen tam da buydu .

Senin için daha kısa bir sürümüm var:

Yapması kolay veya düzenli olan ne olursa olsun, biz yerine yapmak için bir program yazıyoruz.

Ve sonra bunun yerine meta-süreç ile savaşın.

Bu doğru değil, aslında, ama her gün blog motorları yazmak yerine binlerce blog kuruluyor. Her iş günü, bunlar için özel olarak tasarlanmış veritabanı uygulamaları yazmak yerine binlerce Excel makrosu yazılmaktadır.

Birçoğu burada bahsedilen - başka faktörler var - ama tartışmaya bu noktayı eklemek istedim.

Sorumluluk eksikliği ... Bir uçak çöktüğünde insanlar dava edilir. Yazılım endüstrisi herhangi bir yazılım kusurundaki sorumluluğunu reddeder, bu nedenle sağlam ve güvenli bir ürün oluşturmak için bir teşvik eksikliği yaratır.

Büyük projelerin çoğu, az sayıda tasarım kısıtı tanımlayabileceğiniz, alt projelerin yüksek derecede ayrılabilirliğine sahiptir; Tüm alt projeler tamamlandığında tüm proje çalışacaktır. Bir alt projede bir şeyler ters giderse, tüm çaba soruya atılmaz; alt projeyi tamamlamak için alternatif yollar aramanız yeterlidir (örneğin farklı bir motor kullanın).

Yazılım projelerinde bu, hem pratik olarak hem de insan doğası açısından mümkün, ancak zordur.

Kısmen, diğer endüstriler, bu tür bir ayrılmanın iyi bir şey olduğunu zor yoldan öğrendiler. Örneğin, Rolls Royce uçak motorlarını kullanacaksanız, yalnızca belirli bir tasarıma sahip kanatlarla çalışan özel Rolls Royce cıvatalarını ve bağlantı noktalarını kullanmanız gerekmez ve ardından Pratt ve Whitney'e geçmeye çalışırsanız, tüm kanadınızı sıfırdan yeniden tasarlamanız gerekir (bu da gövdenin tamamen yeniden tasarlanmasını gerektirir; bu da sırayla farklı bir uçuş eğlence sistemi satın almanızı gerektiren farklı koltuklar almanızı gerektirir). hangi...). Birkaç bağlantı olabilir - motorları sadece bakımsız değiştiremezsiniz - ama büyük projeler genellikle bu tür durumlar minimize edildiğinde daha iyi çalışır.

Ben kendi aralarında temiz arayüzlü küçük yazılım projelerinin bir küme olarak tasarlanmış büyük yazılım projeleri olacağını varsaymaktadır değil büyük proje aslında küçük projelerin küme tarafından çözülür sürece, özellikle sık sık başarısız olurlar. (Bu konuda bir hata yapmak mümkündür.)

Yapı yazılımı sistemleri, fiziksel yapıların oluşturulmasından çok farklıdır. Yani, uygulama çok farklı. Örneğin, büyük bir tanker inşa ederken, parçaları bir robot veya elle kaynak yapmak, tüm somunları ve cıvataları sıkmak, boyamak, süslemek, taşımak gibi oldukça basit (ancak kolay değil!) Görevler yaparsınız. ekipman ve mobilya vb. Bütün bunlar gerçekten çok basit şeyler yapmak.

Ancak, yazılım söz konusu olduğunda, çok daha karmaşık bir hal alır . Örneğin, ürünün güvenli bir şekilde oturum açmasını ve kullanıcı kimlik bilgilerini depolamasını tam olarak nasıl uyguluyorsunuz? Hangi kütüphaneleri ve araçları kullanabilirsiniz? Hangi kütüphanelere ve araçlara aşinasınız? Haşlama + tuzlama fonksiyonunu tam olarak nasıl yazıyorsunuz ve güvenli olmasını nasıl sağlıyorsunuz? Bunu birçok şekilde yapabilirsiniz; bu tür şeyler için gerçek pratik tasarım desenlerini ayarlamak imkansızdır . Evet, söz konusu tasarım desenleri do "en iyi uygulamalar" olarak daha küçük bir ölçekte mevcut olan, ancak her yazılım sistemi diğerlerinden çok farklı olduğunu ve aslında imkansız öylesine hızla alan gelişmeler ve değişiklikler yetişmek için.

Bir ev inşa ederken, ana destek duvarlarının yetersiz göründüğünü ve değiştirilmeye ihtiyaç duyduğunu farkettiğiniz bu sorunlarla karşılaşmazsınız; bu, şu ana kadarki ilerlemeyi yok etmenizi ve destek duvarlarını tekrar yaparak tabandan başlamayı gerektiriyor . Tasarım aşamasında bu tür meseleleri ele alıyorsunuz çünkü binanızın ne tür destek duvarlarına ihtiyaç duyduğunu tahmin etmek oldukça basit.

Yine de yazılım ile durum böyle değil. Tüm ürünü tek bir varlık olarak tasarlayamaz ve daha sonra uygulayamazsınız. Yazılım tasarım süreci genellikle yinelemelidir ve ürün uygulanırken ve test edilirken hedefler ve gereksinimler değişir. Bir bütün olarak yazılım geliştirme, işlerin genellikle en az beklendiğinde değiştiği yinelemeli bir süreçtir ve bu tür değişikliklerin çoğu zaman daha fazla iş, daha karmaşıklık ve ne yazık ki ve sonuç olarak daha fazla para, zaman ve zor iş gerektiren zorluklar doğurur.

Dolayısıyla, özünde, büyük projeler sunmanın ve proje zaman çizelgelerini ve yol haritalarını tahmin etmenin zor olmasının nedeni, yazılım geliştirme ve özellikle çalışan tasarımın çok karmaşık alanlardır. Karmaşıklık kök problemdir.

Büyük projenin tanımı çarpıktır.

Teknik olarak büyük bir proje zamanında teslim edilebilir ve kusursuz bir şekilde, yıllar içinde birçok kez inşa edilen bir şey olduğu kabul edilir.

• Bir Pac-Man klonu.
• Hesap makinesi
• Bir metin editörü

Düşündüğünüzden eminim ... "ama bunlar küçük projeler! Metin editörü basittir ." Sana katılmıyorum Bilgisayarlar aşırı derecede karmaşık. Kullanıcıları bir işletim sistemine kurmak ve kurmak sadece zaman zaman zor olabilir ve işletim sistemi bile yazmadınız ya da donanımı kurmadınız.

Bahsettiğiniz projeler uzay araştırmalarına benzer büyük projelerdir. Galaktik seyahatler yapmanın ne kadar sürdüğünü nereden biliyorsunuz? Hangi modele dayanıyoruz? Bilinen, bildiğiniz bilinmeyenler, bilinmeyenler ve son olarak da bilinmeyen bilinmeyenler var, yazılım geliştirmede çok fazla şey oldu.

Bence problem beklentidir. Sadece teknoloji olduğu için onu kullanmanın bir süre başarılı olacağı (ya da kullanması akıllıca olacak) anlamına gelmez. Diğer endüstriler yazılım endüstrisi gibi davranırlarsa, on yılın sonunda satılık kara delikli elektrikli süpürgelere sahip oluruz. Veya bazı "vizyon sahibi" bir ay tabanı oluşturmak için kaynaklara sahip olacak ve bir Starbucks'un ziyaretçiler için deneyimi gerçekten "tamamlayacağına" karar verecek. Sorunun yazılım endüstrisi olduğunu sanmıyorum, ancak beklentiler üzerine geldi.

Başka pek çok şey olsa olabilir sayılabilir, ben çok temel bir cümle işaret değer olduğunu düşünüyorum. Çoğu ürünün mevcut davranışa uyması amaçlanmıştır. Köklü bir atılım (örneğin, araba) olan bir ürün bile, genellikle mevcut davranışa uyması için yapılmıştır ve basitçe onu daha basit / kolay / daha ucuz / ne yaparsa yapın. Evet, çoğu zaman mevcut davranışlar üzerinde de bazı yan etkiler olur (örneğin, atlar için yemek yerine arabaya yakıt almak), ancak ikincisinin çoğu oldukça küçük bir yan etki olma eğilimindedir.

Buna karşılık, kullanıcıların davranışlarını değiştirmeyen hemen hemen her yazılım (örneğin, işlerini çok daha kolay yapmalarına izin verir) temel olarak 1. günden itibaren tam bir başarısızlık olarak garanti edilir. Daha da kötüsü, büyük yazılım projeleri sadece Kullanıcıların bireysel bir seviyedeki davranışlarını içerir, fakat büyük grupların davranışlarını, genellikle de kuruluşun tamamını kapsar.

Kısacası, yazılımı kendisi tasarlamak genellikle işin en kolay kısmıdır. Zor kısım, halkların işlerini onlar için yeniden tasarlamaktır. Başlamak zor; Sadece işe yaramayacak, aynı zamanda kabul edilecek şekilde de yapmak çok daha zor.

Airbus A380 dediğiniz gibi başarılı bir proje değildi. Bir CAD / CAM şirketinde çalışıyorum ve bana farklı firmalarda farklı yazılım versiyonları kullandıkları için (Airbus öncülüğünü de yaptık) birkaç yıl ertelendiğini söylemiştim. Yani, dünyanın farklı yerlerinde farklı bölümler tasarlanıyordu. Ve bütünleşirken tüm tasarımın birleştirilemediğini öğrendiler, bu yüzden onu tek bir versiyonda yeniden tasarlamaları gerekiyor. Bu yüzden baktığımda başarılı olduğunu sanmıyorum. 2-3 yıl önce gelseydi, Airbus için oyun değiştirici olurdu.

Ayrıca sağlam yazılımlarla ilgili olarak, herhangi bir uçağa, arabaya (ABS, EPS, iklim kontrolü vb.) Veya uzay mekiğine bakarsanız, bunları çalıştıran% 50'den fazla yazılıma sahip olduklarını ve çok sağlam olduklarına inanıyorum. Sadece yazılıma daha yakın olduğumuzdan ve daha birçok yazılım programından dolayı daha fazla hata görüyoruz.

Http://www.globalprojectstrategy.com/lessons/case.php?id=23 adresini ziyaret edin ve Airbus A380'in ne kadar başarılı olduğunu görün.

Yazılım mühendisliği, mühendislik arka planı ve inşaatta çalışan bir eş. İşlerimizin farklılıkları hakkında uzun tartışmalar (ve argümanlar) yaptık.

Yazılım mühendisliği yeni şeyler tasarlamakla ilgilidir . Neredeyse temel olan her şey bir yerde açık kaynak kodlu bir kütüphanede yapıldı. Bir yazılım mühendisinin işe alındığı hemen hemen her işte, var olmayan bir şeyi tasarlamak zorundadır.

İnşaat ve çoğu mühendislik şekli gibi bir şeyde, aksi halde yazılımdaki bir “kütüphanede” olacak şeyler zaten tamamen tasarlandı. Bir kule inşa etmek ister misiniz? Sadece birkaç değişiklikle planları kopyalayıp yapıştırın.

Aslında, mühendis olmamaya karar vermemin temel nedenlerinden biri, zamanınızı çoğunu, bir sosyal ağ gibi daha görünür bir şeyi programlamak için kullanabileceğiniz zaman, mevcut bir buluş için% 10'luk bir iyileştirme tasarlayarak geçirmenizdir. .

Mühendislikte pek fazla yeni tasarım yok; son derece yetenekli bir mühendis, mevcut bir tasarımı yeni bir şeye manipüle edebilecek veya üzerinde geliştirebilecek bir kişidir. Ancak hemen hemen her programcının tasarımları değiştirmesi, kırması veya yeni bir şey yaratması bekleniyor.

Geri standartlar dışında, tamamen değişti ne kadar bak montaj vb Java C ++, JavaScript, C #, PHP C'ye ve. 10 ya da 20 yıl öncesinden geri dönüştürülebilecek fazla kod yok. Bunu söylemek çok farklı ... otomotiv veya havacılık endüstrisi, on yıllardır tasarımlarını geliştirmeye devam edebileceğiniz zaman.

Proje yönetimi, yazılımda açıkça zordur . Zaman tahminleri, işi yapan insanlar tarafından en iyi şekilde yapılır , ancak tahmin yapmakla meşgul olduklarında kod yazmazlar . Bu, insanları herhangi bir proje yönetiminden kaçınmaya teşvik eder.

Çoğu zaman, birçok kod belirli kişilere dayanır ve bu insanlar geç kalırsa veya gerçekleştiremezlerse, kod devam etmez. Buna karşılık, bir araba yapmak istiyorsanız, lastik, şasi, akü, motor vb. Montajı için farklı insanları işe alabilirsiniz. Nesneye yönelik ve mevcut çerçeveler bunu mümkün kılar, ancak her şeyi sıfırdan tasarlarken pratik olmayabilir.

Hatalara yazılımda izin verilebilir . Test pahalı olabilir. Yazılımda, bir çökmeyi düzeltebileceğiniz zaman, tüm bu testleri atlamak çok caziptir. Çoğu mühendislik türünde, bir 'çarpışma' ölümcül olabilir.

Aşırı programlama (gerçekte yazılım megaprojects'inde kullanılan) gibi kapsamlı testler kullanan programlama yöntemleriniz var . Ancak, son tarihler (bilerek daha sıkı hale getirilebilir), tüm bu programlamayı atlamak ve böceklerle başlatmak cazip geliyor. Joel Spolsky "her zaman tüm hata tespit" tarzı uzun vadede daha fazla zaman harcamak zorunda kalmadan disiplinsiz bu atlayıp başarısız olur.

Küçük projeler daha iyi . Karım bir keresinde büyük bir şirkette iş bulmamı istedi. Büyük şirketlerin kötü şirketler olduğu ... ... onun için büyük bir şirketin çok kaynağı, tecrübesi, fonksiyonel proje yönetimi ve doğru prosedürleri olduğu iddiasıyla sonuçlandı. Bana göre, büyük bir şirket, zamanınızın çoğunun kod düzeltme, test etme ve dokümantasyon için harcandığı bir dinozor.

10 milyondan az insanın çalıştığı milyon dolarlık BT projelerini gördüm. Daha fazla insan projeyi yavaşlatır ve gereksiz bürokrasiyi eklerdi. WhatsApp milyarlarca dolar değerinde 'küçük' bir projenin örneği. Büyük projeler mümkün değildir, ancak yazılıma değecek milyarlarca dolar üretmek için binlerce insana ihtiyacınız yoktur.

Diğer sorularda gerçekten kapsanmayan sebeplerden biri, yazılım alanının yalnızca materyal tabanlı dünyada nadiren meydana gelen bir hızda yenilik yapmasıdır.

Bunun bir nedeni, yazılımın gelişmesinde pozitif bir geri besleme döngüsü olmasıdır; çünkü yazılım (yazılım programlama dilleri, yapım araçları, IDE'ler) yazılım oluşturmak için kullanılır. Bu, Ray Kurzweil'in ivme kazanma hızındaki ilerleme ile sonuçlanan ivme kazanma yasası için en açık örnek . Bir çerçeveyi, programlama dilini, iletişim protokolünü yönettiğinizde , bir sonrakine geçmenin zamanı gelmiştir .

Uçaklar yazılım gibi inşa edildiyse, malzemeyi diğer modellerle değiştiriyor, kapasitelerini ve hızlarını her 18 ayda bir değiştiriyor, her yeni model için motor teknolojisini yeni keşfedilmiş bir şeyle değiştiriyor, aynı zamanda yüzmeye ve dünya dışı bir deniz kabiliyetine bakıyor hayat.

Oh, ve ideal olarak ses komutlarını dinler ve iş geziniz bittiğinde tamamen sürükleyici bir sinema, paintball arena ve karanlık odalı gece kulübü olarak ikiye katlar. Aynı şey! (Sizi A'dan B'ye güvenilir bir şekilde getiren uçaklar yapan şirket, sinema salonu, paintball ve gece kulübü özelliğiyle çıktıktan bir yıl sonra ortaya çıktı.)

Benim için yazılım mühendisliğinin karşılaştığı asıl sorun kullanım alanları, kullanıcı ve çapraz platformlar.

Davaları kullanın

Bir uçağın kaç tane kullanım durumu var? Çoğu, sadece bir yerden diğerine uçmak. Belki radar, trafik kontrolü vb. Gibi daha pek çok şey vardır, ancak kullanım durumu açık ve çok fazla değildir. Yazılım mühendisliğinde belirsiz gereksinimleri ve ne istediklerini bilmeyen kullanıcılarla karşı karşıyayız. Farklı kullanıcı farklı konfigürasyon / akışa ihtiyaç duyar, uçak istediği şekilde özelleştirilebilir mi (televizyon ve buzdolabı istiyorum!)?

kullanıcı

Uçağı kim işletiyor? Bir pilot, bir yardımcı pilot, bazı görevliler (sayılırsa) ve kule operatörleri. Hepsi profesyoneldir ve görev tanımları açıktır. Yazılım, diğer bilgisayarlarla ( OpenID veya Google AdSense gibi ) bütünleştirilebilir olması gerekirken, kötü niyetli bilgisayar korsanları ve krakerlerinden bahsetmeksizin noobs ve aptallar tarafından kullanılır . Bir uçak hala füzelerden veya ninja soyguncularından hayatta kalırken aptallar tarafından çalıştırılabilirse, uçağın yazılımla aynı kalitede olduğunu söyleyebilirsiniz.

Çapraz platformlar

Bir uçak sadece dünyanın gökyüzünde uçar. Sisli veya rüzgarlı ya da sıcak, soğuk ve nemli iklimi nasıl kullandıklarından emin değilim, ancak bir uçak farklı çekim seviyesinde uçacak şekilde tasarlanmamıştır ( Mars'a uçabilirse hayret edeceğim ). Bazen bir uygulama, Internet Explorer, Google Chrome , tarayıcı için Firefox ve Safari (üzgünüm Opera ) veya Windows XP / 7/8 veya işletim sistemi için Linux gibi farklı platformlarda hayatta kalmalıdır . Mobil cihazlardan ve farklı çözünürlük ve yönlerden bahsetmiyorum.

Diğer endüstrilerin olaysız bir şekilde projeleri tamamladığını düşünüyorsanız, 1977'de inşa edilen Citigroup Center binası hakkındaki hikayeyi okumalısınız. Her 16 yılda bir fırtına olayı bekleniyor.

Başka bir deyişle, her yıl Citicorp Merkezi ayakta duruyordu, 16'sı bir arada çöküşe geçme şansı vardı.

Orijinal tasarımcılar sorunların farkında değildi, ama neyse ki binada okuyan bir öğrenci tarafından yakalandı.

her şey yolunda görünüyordu - LeMessurier'in söylediği gibi bir telefon aldı. LeMessurier'e göre, 1978'de bir lisans mimarisi öğrencisi, LeMessurier'in binası hakkında cesur bir iddia ile temasa geçti: Citicorp Center'ın rüzgarda havaya uçabileceği.

Tasarım kusurunun gizliliğini korumak için en az sayıda insanın yer aldığı gece kapsamında tam anlamıyla tamirat yapıldı.

Binayı çevreleyen 10 blok yarıçapı için acil durum tahliye planı hazırlandı.

Gece boyunca kaynak yapmışlar ve bina sakinleri işe döndüklerinde şafakta bırakmışlar.

Hikaye, yazar Joe Morgenstern'in bir partide söylendiğini duyana ve LeMessurier ile röportaj yapmasına kadar bir sır olarak kaldı. Morgenstern, 1995 yılında The New Yorker'da hikayeyi kırdı.

Hangi soruyu gündeme getiriyor; Projelerdeki diğer birçok ölümcül tasarım kusurunun, kamuoyu onayı olmadan gizlice onarıldığı veya göz ardı edildiği.

• NYC Gökdelenini Neredeyse Silinen Tasarım Kusuru (slate.com)
• Citigroup Merkezi (wikipedia.com)