Dlaczego branża IT nie może dostarczać dużych, bezbłędnych projektów tak szybko, jak w innych branżach?

509

Po obejrzeniu serii MegaStructures National Geographic byłem zaskoczony, jak szybko są realizowane duże projekty. Po wykonaniu wstępnych prac (projektu, specyfikacji itp.) Na papierze sama realizacja dużych projektów zajmuje zaledwie kilka lat, a czasem nawet kilka miesięcy .

Na przykład Airbus A380 „formalnie wystartował 19 grudnia 2000 r.” I „na początku marca 2005 r.” Samolot był już testowany. To samo dotyczy wielkich tankowców, wieżowców itp.

Porównując to do opóźnień w branży oprogramowania, nie mogę się zastanawiać, dlaczego większość projektów IT jest tak powolna, a ściślej, dlaczego nie mogą być tak szybkie i bezbłędne, na taką samą skalę, biorąc pod uwagę wystarczającą liczbę osób?


Projekty takie jak Airbus A380 prezentują zarówno:

  • Główne nieprzewidziane ryzyko: chociaż nie jest to pierwszy zbudowany samolot, wciąż przesuwa granice technologii, a rzeczy, które działały dobrze w przypadku mniejszych samolotów pasażerskich, mogą nie działać w przypadku większego samolotu ze względu na ograniczenia fizyczne; w ten sam sposób wykorzystywane są nowe technologie, które nie zostały jeszcze wykorzystane, ponieważ na przykład nie były one dostępne w 1969 roku, kiedy ukończono Boeinga 747.

  • Ryzyko związane z zasobami ludzkimi i zarządzaniem w ogóle: ludzie rezygnują w połowie projektu, niemożność dotarcia do osoby, ponieważ jest na wakacjach, zwykłe błędy ludzkie itp.

Przy takim ryzyku ludzie nadal realizują projekty takie jak duże samoloty pasażerskie w bardzo krótkim czasie i pomimo opóźnień w dostawie projekty te są nadal niezwykle udane i wysokiej jakości.

Jeśli chodzi o tworzenie oprogramowania, projekty nie są tak duże i skomplikowane jak samolot pasażerski (zarówno pod względem technicznym, jak i zarządzania), i mają nieco mniejsze nieprzewidziane ryzyko ze strony realnego świata.

Mimo to większość projektów informatycznych jest powolna i opóźniona , a dodanie większej liczby programistów do projektu nie jest rozwiązaniem (przejście od zespołu dziesięciu programistów do dwóch tysięcy czasami pozwoli dostarczyć projekt szybciej, czasem nie, a czasem tylko zaszkodzi projektu i zwiększ ryzyko nieukończenia go).

Te, które wciąż są dostarczane, mogą często zawierać wiele błędów, wymagających kolejnych dodatków Service Pack i regularnych aktualizacji (wyobraź sobie „instalowanie aktualizacji” na każdym Airbusie A380 dwa razy w tygodniu, aby załatać błędy w oryginalnym produkcie i zapobiec awarii samolotu).

Jak wyjaśnić takie różnice? Czy wynika to wyłącznie z faktu, że przemysł tworzący oprogramowanie jest zbyt młody, aby móc zarządzać tysiącami ludzi w ramach jednego projektu, aby bardzo szybko dostarczać niemal bezbłędne produkty na dużą skalę?

Arseni Mourzenko
źródło
127
Interesujące pytanie. Kusi mnie, aby powiedzieć, że jakość przeciętnego pracownika w branży oprogramowania jest mniej wykwalifikowana i wykwalifikowana niż, powiedzmy, inżynieria lądowa, w której każdy inżynier ukończył rygorystyczny i intensywny stopień naukowy i prawdopodobnie również uzyskał swoją kartę. Co więcej, przestrzeń złożoności dużego oprogramowania (np. OS, MS Office) jest prawdopodobnie znacznie większa nawet niż samolot. Z pewnością wiele innych miejsc do porażki! I ostatnia ważna kwestia: większość oprogramowania działa mniej więcej, nawet jeśli było źle napisane i zawierało wiele błędów… z pewnością koszt awarii jest zwykle znacznie niższy niż samolot!
Noldorin
155
Znajdź kogoś, kto faktycznie pracuje w którejkolwiek z tych branż (ale nie w PR) i zapytaj go o „duże bezbłędne projekty”. Mogę praktycznie zagwarantować, że zarobisz ból.
Michael Borgwardt
151
Realizacja projektu oprogramowania zajmuje sekundy lub minuty; dzieje się tak, gdy klikniesz „kompiluj” w swoim IDE. Z drugiej strony programowanie to projektowanie . Ile czasu zajęło zaprojektowanie A380?
Ant
53
Ten program telewizyjny jest hype. Oni tylko projekty telewizyjne zakończone sukcesem. Każdy kanał przyciągnie uwagę widzów.
pandu
117
„wyobraź sobie, że instalujesz aktualizacje” na każdym Airbusie A380 dwa razy w tygodniu… ”Wyobraź sobie, że wrogie roboty nieustannie sprawdzają samolot pod kątem słabości, podczas gdy nieprzeszkoleni piloci naciskają przyciski losowo. Założę się, że potrzebujesz regularnych łat.
Nathan Long

Odpowiedzi:

337

Marsz śmierci Eda Yourdona dotyczy szeregu pytań typu meta.

Ogólnie rzecz biorąc, w branży oprogramowania brakuje wielu następujących elementów, co przeszkadza w dużych projektach.

  • Standaryzacja i podział elementów pracy.

    • Z pewnością sytuacja uległa poprawie, ale konstrukcje konstrukcyjne wciąż nie są w stanie przełamać dużego systemu. W pewnym sensie oprogramowanie nie może nawet uzgodnić, co jest potrzebne dla danego projektu, a tym bardziej nie jest w stanie rozbić elementów na komponenty.
    • Przemysł lotniczy, budowlany, samochodowy itp. Mają architekturę opartą na komponentach i dość ciasnych interfejsach, umożliwiających w pełni równoległy rozwój. Oprogramowanie nadal pozwala na zbyt duży wyciek w odpowiednich obszarach.
  • Duża liczba udanych, podobnych projektów. A380 nie był pierwszym dużym samolotem zbudowanym przez Airbusa . Istnieje wiele dużych aplikacji, ale wiele z nich dramatycznie ucierpiało w tym czy innym aspekcie i nie zbliżyłoby się do nazwania go „sukcesem”.

  • Duża grupa projektantów i konstruktorów, którzy pracowali nad wieloma podobnymi i udanymi projektami. Związane z udanym zagadnieniem projektu, brak talentu ludzkiego, który tam był, jest bardzo trudny z punktu widzenia powtarzalności.

  • „Nigdy” dwa razy budując to samo. Pod wieloma względami samolot jest jak każdy inny samolot. Ma skrzydła, silniki, siedzenia itp. Duże projekty oprogramowania rzadko się powtarzają. Każde jądro systemu operacyjnego jest znacząco inne. Spójrz na różnice w systemach plików. A jeśli o to chodzi, ile jest naprawdę wyjątkowych systemów operacyjnych? Duże stają się w pewnym momencie klonami podstawowego elementu. AIX , Solaris , HP-UX , heroldem ... z powrotem do AT & T System V. . System Windows miał niesamowitą przewagę podczas każdej iteracji. Warianty Linuksa zasadniczo wracają do tego samego rdzenia, który uruchomił Linus. Mówię o tym, ponieważ warianty propagują się szybciej niż naprawdę unikalne, zastrzeżone systemy operacyjne.

  • Naprawdę złe oszacowanie projektu. Ponieważ współczynnik powtarzalności jest tak niski, trudno jest przewidzieć, jak duży będzie wynik i jak długo zajmie zbudowanie. Biorąc pod uwagę, że kierownicy projektów i kierownictwo nie mogą pojąć kodu i faktycznie zobaczyć, co się dzieje, powstają nierealistyczne oczekiwania dotyczące terminów.

  • QA / QC nie jest podkreślane tak mocno, jak mogłoby lub powinno być w przypadku większych projektów. Wraca to do luźniejszych interfejsów między komponentami i braku sztywnych specyfikacji dotyczących sposobu działania komponentów. Ta luźność pozwala na niezamierzone konsekwencje i na wtargnięcie błędów.

  • Konsekwentnie mierzalne kwalifikacje. Ogólnie rzecz biorąc, ludzie mówią o liczbie lat pracy w języku X lub w programowaniu. Czas jest wykorzystywany jako zamiennik kalibru lub jakości umiejętności. Jak już wspomniano wiele razy, przeprowadzanie wywiadów i znajdowanie dobrych talentów programistycznych jest trudne. Częściowym problemem jest to, że definicja „dobrego” pozostaje bardzo subiektywna.

Nie chcę być całkowicie negatywny i myślę, że branża oprogramowania poczyniła znaczące postępy od miejsca, w którym byliśmy. Takie fora, jak i inne, naprawdę pomogły promować rozmowę i dyskusję na temat zasad projektowania. Istnieją organizacje pracujące nad standaryzacją wiedzy „bazowej” dla inżynierów oprogramowania. Z pewnością istnieje pole do poprawy, ale myślę, że branża przeszła długą drogę w rozsądnie krótkim czasie.

53019
źródło
23
Trudno było wybrać odpowiedź do zaakceptowania spośród kilku bardzo dobrych odpowiedzi, ale ostatecznie wybrałem tę, mimo że nie ma ona najwyższych głosów. W rzeczywistości zarówno ta odpowiedź, jak i odpowiedź m3th0dman dokładnie wyjaśniają , dlaczego istnieje taka specyfika w branży IT, pomagając zrozumieć, co zrobić w przyszłości, aby wypełnić lukę. W porównaniu z odpowiedzią m3th0dman ten wydaje się znacznie bardziej szczegółowy.
Arseni Mourzenko
3
+1, ale mogę tylko dodać, że ponieważ oprogramowanie istnieje w sferze umysłu, ma ono prawie nieskończone możliwości, podczas gdy każda płaszczyzna, którą każdy zbudowany musi stawić czoła skończonym wymaganiom rzeczywistości.
Spencer Rathbun
5
Bardzo dobrze odpowiedział. Jako ciekawy przykład - wyobraź sobie, że duży samolot został zaprojektowany i wdrożony przez grupę osób bez historii procesu lub firmy - ludzie, którzy właśnie się spotkali i założyli firmę, aby zbudować samolot w skali 747 od zera. W ten sposób wykonuje się 90% projektów oprogramowania, które widziałem. Pozostałe 10% z doświadczonymi architektami i firmami z historią i procesem wydaje się znacznie bardziej skuteczne. Dla kontrprzykładu przyjrzyj się procesowi tworzenia oprogramowania, które powoduje śmierć ludzi w przypadku niepowodzenia.
Bill K,
7
Myślę, że przyjąłeś złą odpowiedź. Danny Woods miał rację, awarie w innych branżach są tak samo częste, a programowanie nie buduje, jest projektowaniem. Konstrukcja w świecie oprogramowania jest wykonywana przez kompilator i jest praktycznie darmowa. Twoje pierwotne pytanie było bardzo wymowne Po wykonaniu wstępnych prac (projekt, specyfikacje itp.) Na papierze, praca projektowa i specyfikacja struktury fizycznej jest DOKŁADNĄ specyfikacją sposobu budowania struktury. Jedyne, co pasuje do tego w świecie oprogramowania, to kod. Kod to projektowanie, kompilacja to konstrukcja.
Michael Brown
5
Ale samo pytanie jest błędne. Chociaż musimy skierować krytyczne oko na własne niedociągnięcia. Działa się tak, jakby branża oprogramowania jako jedyna realizująca nieudane projekty była absurdalna. Mówienie „po zakończeniu całego projektu” również mówi. Nawet jeśli nie zgadzasz się z tym, że programowanie jest zajęciem projektowym, jak często widzisz szczegółowy, odziany w żelazo projekt dla oprogramowania? Ludzie podają niewyraźne specyfikacje oprogramowania, ponieważ spodziewają się możliwości zmiany oprogramowania, jeśli specyfikacje byłyby niewłaściwe bez dbania o to, jak te zmiany mogą wpłynąć na całe rozwiązanie.
Michael Brown
452

Odpowiedź jest zaskakująco prosta: te „inne branże” nie mają wysoki wskaźnik awaryjności. Po prostu porównujemy złe rzeczy. Oprogramowanie do pisania jest często nazywane „kompilacją”, dlatego porównujemy je z fazami produkcji lub budowy w innych branżach. Ale jeśli na to spojrzysz, wcale nie jest to konstrukcja: to projekt . Projekty oprogramowania są zapisywane w kodzie, a budowanie odbywa się za pomocą komputerów, czy to poprzez kompilację oprogramowania, czy też bezpośrednią interpretację w locie.

Wiele projektów w innych branżach albo trwa znacznie dłużej niż pierwotnie oszacowano, kosztuje znacznie więcej lub po prostu nigdy nie kończy się. Brzmi znajomo?

Co robimy, gdy planujemy oprogramowanie? Nadal projektujemy, ale na wcześniejszym etapie.

W oprogramowaniu nie ma ważnej linii produkcyjnej. Budowanie końcowego komponentu jest (względnie) tanie, a replikacja tego produktu końcowego jest zarówno idealna, jak i efektywnie darmowa - kopiujesz artefakty kompilacji.

Danny Woods
źródło
47
Nawet w branży wspomniany PO, Aerospace, Boeing 787 Dreamliner i JSF F-35, miały znaczne opóźnienia. W ubiegłym tygodniu zawalił się parking w jednym z głównych centrów handlowych w Sydney. Sydney ma bardzo rygorystyczne normy budowlane, ale zdarzają się błędy.
teambob
23
Tysiąc razy to. Nawet link do harmonogramu pytania pokazuje, że projekt był faktycznie opracowywany od 1988 roku. Kod źródłowy to projekt: developerdotstar.com/mag/articles/reeves_design.html
pkh
2
Wiele dużych projektów, takich jak F-35, teleskop Hubble'a itp., Spóźniło się z powodu rozwoju oprogramowania. Hubble faktycznie siedział w pamięci przez lata, ponieważ oprogramowanie nie było gotowe.
MrLane
11
@MrLane: W prawdziwym świecie działa to tak. Zostanie ustalony harmonogram, kiedy sprzęt ma zostać wykonany, a oprogramowanie ma zostać wykonane. Projektanci sprzętu dostarczają ICD zespołowi oprogramowania, aby zespół SW mógł napisać swój kod bez sprzętu. Sprzęt bardzo szybko zmienia swój harmonogram i zmienia interfejsy, aby obejść problemy z sprzętem, często bez powiadamiania zespołu SW. Wreszcie, hw działa i jest dostarczane, znacznie późno. Oczywiście SW nie działa z powodu niezliczonych niespodziewanych „funkcji”. Ponieważ tańsze jest rozwiązywanie problemów sprzętowych w ...
Dunk
11
Oprogramowanie, zespół SW musi teraz wprowadzić zmiany w ICD i opracować obejścia dla wadliwego sprzętu. Więc poza tym, że sprzęt został dostarczony znacznie później, a teraz zespół SW naprawia również wadliwy sprzęt, kto ponosi winę za spóźnienie? Zespół oprogramowania jeszcze się nie skończył. To oprogramowanie się spóźnia. Wszyscy zawsze zapominają o poślizgach harmonogramów inżynierii elektrycznej, mechanicznej i systemowej, które zależały od tego, a następnie zmuszały do ​​przepisania i spełnienia dodatkowych wymagań. Widzą tylko, że zespół SW nadal koduje. Dlatego oprogramowanie się spóźnia.
Dunk
180

Aby wskazać niektóre liczby:

  1. Zmiana wymagań po rozpoczęciu wdrożenia ; na przykład, kiedy pierwszy Airbus A380 zaczął powstawać w fabryce, nie mogę uwierzyć, że gdyby ktoś chciał 200 dodatkowych miejsc, byłyby tam umieszczone; ale w dużym projekcie oprogramowania nawet po rozpoczęciu programowania przez programistów można dodać 5 kolejnych typów użytkowników.
  2. Złożoność - duże projekty oprogramowania są niezwykle złożone; prawdopodobnie najbardziej złożone projekty zaprojektowane i opracowane przez człowieka;
  3. Niewystarczające zasoby są wydawane w fazie architektury i projektowania ;
  4. Niedojrzałość w polu - inżynieria oprogramowania jest stosunkowo młodą dyscypliną w porównaniu z innymi siostrami inżynierii; ma to dwie konsekwencje: a) Niewiele heurystyk i dobrych praktyk; b) Niewielu bardzo doświadczonych specjalistów;
  5. Brak dowodu matematycznego - w większości przypadków nie stosuje się matematycznych metod formalnych w celu udowodnienia, że ​​oprogramowanie działa zgodnie z wymaganiami; zamiast tego stosuje się testowanie. Odnosi się to do innych dziedzin inżynierii, które w większym stopniu opierają się na matematyce; powodem tego jest złożoność;
  6. Pośpiech - wielu menedżerów ma nieosiągalne terminy; więc jakość kodu jest na drugim miejscu ze względu na termin.

Odpowiadając ściśle na pytanie - mam skłonność wierzyć, że inni mają bardzo wysokie oczekiwania (szczególnie w zakresie czasu dostawy) od programistów i nie rozumieją dokładnie, jak trudne jest programowanie dużego oprogramowania.

m3th0dman
źródło
55
Formalny dowód matematyczny w oprogramowaniu, poza tym, że często nie jest właściwie możliwe, aby zrobić dobrze, ostatecznie jest niczym więcej niż dwukrotnym napisaniem programu (raz w rzeczywistym języku programowania i raz w języku specyfikacji formalnej) i sprawdzeniem, czy oba wersje robią dokładnie to samo.
tdammers
5
tdammers, istnieją narzędzia, które mogą pomóc Ci napisać oba jednocześnie: Coq obsługuje „ekstrakcję programu” w celu wyodrębnienia programu w OCaml lub Scheme z certyfikowanego programu Coq.
jkff
66
„Zmiana wymagań po rozpoczęciu wdrażania”. Nazywam to „przenoszeniem problemu z toaletą”. Budujesz dom, wykończasz łazienkę, a właściciel chce toalety w innym miejscu. Dajesz im kosztorys. Oni wzdrygają się, mówiąc „dlaczego tak bardzo, chcę tylko toalety 8 stóp dalej?”. Następnie wyjaśnisz, że musisz zainstalować nową instalację wodno-kanalizacyjną, rozerwać ściany / podłogi itp., Aby móc przejść do toalety. Późne zmiany są zawsze drogie.
The Lazy DBA,
7
Powiedziałbym, że testowanie samolotu jest znacznie trudniejsze niż testowanie oprogramowania. W samolocie cała magia matematyczna, którą wyczarowałeś, staje się bezużyteczna, gdy zorientujesz się, że utworzony symulator oprogramowania lub turbiny wiatrowe tak naprawdę nie odzwierciedlają sposobu działania rzeczy, gdy tam jesteś. Formalny dowód w oprogramowaniu to tylko trudny problem, w porównaniu do formalnego dowodu w inżynierii, który jest niemożliwy.
Lie Ryan,
2
Numer 1 na twojej liście jest najważniejszym IMO, dodałbym do niego jeszcze dwie rzeczy: - Dużo dużych zmian można wprowadzić w krótkim czasie (na przykład „zmień protokół komunikacji!”), Które nie zepsują rzeczy w krótkim okresie, ale wiele z nich sprawia, że ​​projekt jest bardzo trudny do zarządzania w perspektywie długoterminowej. - Zmiany w środowisku, w którym działa oprogramowanie, mogą się drastycznie zmienić w krótkim czasie. Podczas gdy podstawowe założenia samolotu pozostaną takie same (musi lecieć w burzy, musi wylądować na solidnych pasach startowych ...), oprogramowanie może się całkowicie zepsuć, jeśli na przykład wyjdzie nowa wersja systemu operacyjnego.
sydd
140

Założenie pytania jest nieco błędne. Zarówno A380, jak i Boeing 787 zostały dostarczone z opóźnieniem.

W przypadku A380 znaczną część opóźnienia spowodowały francuskie i niemieckie jednostki Airbusa korzystające z różnych i nieco niezgodnych wersji oprogramowania projektowego CATIA . To niekompatybilnie objawiło się jako wiązki przewodów, które nie pasowały do ​​samolotu.

Nie było nic złego w CATIA, która jest najczęściej używanym oprogramowaniem do projektowania samolotów, ale ktoś gdzieś upuścił piłkę do konfiguracji oprogramowania.

Boeing 787 również cierpiał z powodu opóźnień związanych z oprogramowaniem, ale większość jego problemów to bardziej tradycyjne nowe problemy z samolotem, takie jak kontrola wagi i dostawa części niespełniających norm przez dostawców.

Zarówno A380, jak i B787 musiały zmodyfikować swoje konstrukcje skrzydeł, gdy początkowe samoloty miały problemy konstrukcyjne.

Duże, złożone projekty są trudne dla ludzi we wszystkich dziedzinach.

Jim In Texas
źródło
10
Zgoda. Wydaje mi się, że istnieje błędne podejście, że oprogramowanie jest „wytwarzane bardziej niechlujnie” niż rzeczy fizyczne, ponieważ złe oprogramowanie kończy się bardzo dobrze widocznymi poprawkami, a ponadto każdy musi radzić sobie z uszkodzonym oprogramowaniem. Jeśli samolot to bzdura i muszą nad nim popracować, nie odsyłasz go z powrotem, jest to po prostu coś, na co mechanicy narzekają między sobą w większości przypadków, chyba że jest to ogromna wada. I te też się zdarzają.
Ben Brocka
6
Myślę, że pytanie wciąż pozostaje aktualne, mimo że przykłady są błędne. Udowodniono statystycznie, że projekty oprogramowania mają znacznie większe koszty końcowe i znacznie dłużej niż przewidywano.
Euforia
18
Należy zauważyć, że projekt i wdrożenie komercyjnego systemu samolotów pasażerskich z natury obejmuje ukończenie ogromnego i bardzo skomplikowanego projektu informatycznego, który musi być w pełni i poprawnie funkcjonalny.
Pointy,
6
A biorąc pod uwagę, że A380 miał poważny wycofanie z rynku dopiero w 2010 r., Nawet wtedy nie nazwałbym go „bezbłędnym”.
Muhammad Alkarouri
3
Ponadto LOTY samolotów koncepcyjnych były finansowane i anulowane przez lata, szczególnie kontrakty wojskowe. Samoloty wcale nie są dobrym przykładem, ponieważ nie słyszymy o wielu (sklasyfikowanych) awariach dopiero wiele lat lub dziesięcioleci później.
SilverbackNet
112

Facet z wieżowca. Nie jestem pewien, czy mogę odpowiedzieć na twoje pytanie, ale z pewnością mogę rzucić nieco światła na różne elementy w wątku. Budynki rzeczywiście pojawiają się bardzo szybko. Głównym ograniczeniem są ustawienia regionalne (przepisy). Ale generalnie wysoki budynek zajmuje od 3 do 10 lat od początku do końca.

Myślę, że porównanie nowego budynku z nowym projektem oprogramowania nie jest zbyt dokładne. Nowy budynek jest bliżej nowej wersji jądra lub systemu operacyjnego. Pod tym względem tworzenie oprogramowania jest znacznie szybsze. Nigdy nie budujemy od zera, ponieważ będzie to zadanie wysokiego ryzyka, na które klient nigdy się nie zarejestruje. Większość projektowania i rozwoju w budynkach jest pochodną sprawdzonych i ukończonych projektów.

Z własnego doświadczenia buduje się tylko jeden na dziesięć projektów. Proces ten opiera się raczej na rozwoju niż na projektowaniu, więc w momencie, gdy cena stali idzie w górę, cały projekt wychodzi poza okno lub jest projektowany, ponieważ projekt jest tanim elementem procesu.

Projektowanie zajmuje miesiąc od koncepcji do schematu, dwa do sześciu miesięcy do opracowania projektu, kolejne sześć miesięcy do szczegółów i dokumentów konstrukcyjnych przez zespół architektów, konsultantów planowania, inżynierów budownictwa, inżynierów wiatrowych, inżynierów usług, konsultantów ilości i kosztów, inspektorów, inżynierów dostępności, a lista jest długa ...

Argument wirtualny kontra fizyczny nie jest zbyt dokładny. Pracujemy również głównie z narzędziami wirtualnymi, a ponadto jesteśmy oddaleni zarówno od czasu, jak i skali od naszego produktu końcowego. W większości przypadków nie możemy nawet przetestować aspektów budynków w skali makiety i używamy symulacji, aby spróbować przewidzieć, co może się zdarzyć.

Pod względem złożoności istnieją różnice, ale ogólnie może być mniej więcej taki sam. Mamy nie tylko powiązane ze sobą jednostki i wiele poziomów wielopoziomowych abstrakcji i interfejsów, ale także ludzie specjalizują się w małych częściach procesu, które bardzo utrudniają komunikację.

Jeśli chodzi o argument projektowania i rozwoju, myślę, że oba procesy są projektowane. Rozsądne jest rozdzielenie ich z naukowego punktu widzenia, ale nie można zaprojektować, jeśli nie wiesz, jak to działa. Po prostu zwiększasz ryzyko niepowodzenia.

Ogólnie rzecz biorąc, moje (potencjalnie błędne) oszacowanie zgodnie z pytaniem PO jest takie, że programowanie jest bardziej sztuką niż inżynierią. Dlaczego ludzie mieliby czerpać przyjemność, a nawet robić to za darmo, znaleźć w niej wyraz i elegancję? Informatyka jest również (jak na puszce) bardziej nauką niż inżynierią. Dlaczego miałbyś próbować udowodnić algorytmy zamiast po prostu łatać istniejące części razem i pracować, aby wszystko działało? Nie jestem pewien, czy to ma jakiś sens; Nie jestem facetem od oprogramowania.

Jeden aspekt, który uderza mnie w projektowaniu i rozwoju oprogramowania, dotyczy samego medium. Komputery sprawiają, że praca zorientowana na człowieka jest bardzo nienaturalna. Wszystko jest bardzo wyraźne i tolerancji jest niewiele. Trudno jest sobie z tym poradzić mentalnie, a niektórzy z nich uciekają, odrzucając w sobie złożoność. Jeśli nic innego może to mieć z tym coś wspólnego?

Konstruktor
źródło
2
+1 dzięki za wgląd. „zaprojektować, jeśli wiesz, jak to działa” -> „zaprojektować, jeśli nie wiesz, jak to działa”?
tokland
Hej, budowniczo, zasugerowałem kilka zmian w tym poście, myślę, że masz doskonałe punkty, po prostu próbowałem uporządkować gramatykę.
Steven
Zdecydowanie zgadzam się z twierdzeniem, że programowanie jest bardziej sztuką niż inżynierią. Często uważam kreatywność za główny aspekt projektowania oprogramowania.
Lanzafame
1
Nie zgadzam się z twierdzeniem, że duży projekt oprogramowania i wieża mają podobną złożoność - w oparciu o moje doświadczenie pracy zarówno jako inżynier budowlany, jak i inżynier oprogramowania, powiedziałbym, że złożoność oprogramowania jest znacznie wyższa. Prawdopodobnie jest z tego wiele powodów, ale sugeruję, że w inżynierii jest dużo miejsca na wahania; górna granica projektu budowlanego jest prawie zawsze podana kosztem, a to jest miękkie ograniczenie. Oprogramowanie musi być dokładne , ponieważ komputery nie radzą sobie dobrze z dwuznacznością. Płyta nie działa? Dodaj gówno ze stali, będzie miała rację.
Simon Robb,
Niektórzy ludzie projektują i budują budynki dla przyjemności. Nie mów mojemu pracodawcy, ale teraz, gdy o tym myślę, niektóre z moich programów są podobne do Sagrada Familia: idiosynkratyczne, zbyt wiele ozdób, które nigdy nie zostały ukończone; ale o ciekawym designie, zabawnym w budowie i użytkowaniu oraz wciąż stojącym.
Peter A. Schneider,
44

Jak długo zajęło ich zaprojektowanie? Rok? Dwa? Dziesięć lat? Projekt jest najbardziej złożoną częścią budowania czegoś, sama konstrukcja jest łatwa.

Na podstawie tego artykułu powoli rozumie się, że tworzenie oprogramowania to głównie proces projektowania, w którym dokument projektowy jest samym kodem źródłowym. A proces projektowania różni się całkowicie od procesu produkcji. Wymaga doświadczonych ludzi i jest niemożliwy do zaplanowania, ponieważ nawet niewielkie zmiany wymagań mogą spowodować ogromne zmiany w ogólnej architekturze projektu. To zrozumienie stanowi podstawę dla zwinnych metodologii, które koncentrują się na poprawie jakości kodu jako ostatecznego dokumentu projektowego oraz przyjmowaniu testów i debugowania jako części procesu projektowania, podobnie jak testują modele samolotów w tunelach aerodynamicznych.

Sama konstrukcja jest obsługiwana automatycznie przez kompilatory. Dzięki temu jesteśmy w stanie zbudować całe produkty w ciągu kilku minut.

Powodem, dla którego projekty oprogramowania są kończone z ogromnymi opóźnieniami i zawyżonymi kosztami, jest to, że menedżerowie nadal uważają, że są w stanie oszacować, przewidzieć i zaplanować taki proces projektowania. Odwraca to częściej niż jest w rzeczywistości ważne. Nadal uważają, że wiążąc ludzi ze sztywnym procesem budowlanym, mogą w jakiś sposób podnieść jakość, nawet jeśli efekt końcowy jest w większości przeciwny ze wzrostem kosztów i przekroczeniem terminów.

Euforii
źródło
2
„To zrozumienie stanowi podstawę dla zwinnych metodologii”. Dokładnie. Metoda wodospadu ma sens dla drapaczy chmur: chcesz, aby każdy szczegół w planie był tuż przed wylaniem fundamentu. Ale jeśli zburzenie i przebudowa drapaczy chmur byłyby bezpłatne i niemal natychmiastowe, jak w przypadku kompilacji kodu, prawdopodobnie użyłbyś procesu iteracyjnego.
Nathan Long,
22
@NathanLong: Zwłaszcza jeśli pojawiały się nowe formy betonu co trzy lata, a ktoś wymyślił, jak można obsługiwać wiele wind w jednym szybie, i nagle stal nie była już fajna i wszyscy postanowili zbudować swoje ramy z węgla błonnik. Takie rzeczy ciągle się pojawiają w branży oprogramowania.
TMN
2
„tworzenie oprogramowania to głównie proces projektowania, w którym dokument projektowy jest samym kodem źródłowym” właśnie otworzyłeś mi oczy. Dzięki.
Bro Kevin D.
@TMN Wyobraź sobie, że podczas budowania skyscrappera zmieniliby paletę kolorów wnętrza, ponieważ nie wygląda to dobrze. Dotyczy to każdego elementu budynku. Próba uruchomienia wielu wind na jednym wale to jedno, ale musiałbyś przetestować 20 wind od innego dostawcy, zanim nawet spróbujesz podłączyć je wszystkie do szybu ...
Loïc Faure-Lacroix,
@ LoïcFaure-Lacroix: Inżynierowie mogą przetestować 20 różnych wind, deweloperzy po prostu skorzystają z tej opisanej w poście na blogu, gdzie po raz pierwszy o tym usłyszeli. Gdy budynek się otworzył i pojawił się problem z windami, odkryli, że firma, która je zbudowała, już nie istnieje. Gdy próbowali uzyskać zamienniki od innego dostawcy, odkryli, że w swoich oryginalnych windach zastosowano niestandardowy wał ...
TMN
39

Wyobraź sobie, że w środku projektu Airbusa A380 ktoś zabrał głos na spotkaniu i powiedział: „Heh, czy mógłbyś go zbudować jako trójpłaszczyzna?”. Inni dołączyli, mówiąc: „Tak, tak. Trójpłaszczyzna. Więcej skrzydeł jest lepszych”. Następne lata upłyną na przekształceniu modelu A380 w trójpłaszczyznę. Na innym spotkaniu ktoś mówi: „Trójpłaszczyzna? To stary. Chcemy dwupłatowiec. Wystarczy usunąć jedno ze skrzydeł”.

Albo wyobraź sobie, że w trakcie budowy mostu ktoś mówi: „Heh, właśnie zawarliśmy umowę z firmą spedycyjną. Potrzebują mostu o kolejne 40 stóp wyżej, ponieważ ich statki są znacznie wyższe. Napraw to. Dzięki . ”

To tylko niektóre z powodów, dla których projekty oprogramowania, duże i małe, kończą się niepowodzeniem w alarmującym tempie.

Kennah
źródło
8
Tak właśnie się dzieje. Rodzaje zarządzania lub klienci zmieniają zdanie co 10 sekund, co tylko frustruje programistów. Rzuciłem ostatnią pracę z powodu takich bzdur
Erin Drummond,
3
To przychodzi mi na myśl: youtube.com/watch?v=BKorP55Aqvg&feature=kp
miraculixx
21

Jako osoba z wykształceniem inżynieryjnym pracująca w branży IT często zastanawiałam się nad przyczynami niskiej skuteczności w branży IT.

Jak inni w tym wątku, często przypisywałem niepowodzenia niedojrzałości IT, brak szczegółowych standardów (tak, mówię poważnie, czy kiedykolwiek sprawdziłeś standardowy arkusz zwykłej śruby?) I brak wystandaryzowanego komponenty i moduły.

Inne branże, takie jak budownictwo czy budowa statków, również mają znacznie więcej „utartych ścieżek”: wiedza i doświadczenie dotyczące konkretnego prototypu rozwiązania, które - w niestandardowej formie - jest ponownie wykorzystywane. Czy zastanawiałeś się kiedyś, dlaczego budynki, statki lub samoloty o różnej wielkości i przeznaczeniu wyglądają tak podobnie? (są wyjątki od reguły oczywiście ...)

Wynika to z faktu, że prototypy te są dobrze zbadane, dobrze zrozumiane, ogólnie używane i mają udokumentowane osiągnięcia. Nie dlatego, że nie można tego zrobić w inny sposób. W normalizacji IT rzadko ma miejsce: (duże) projekty mają tendencję do ponownego wynalezienia komponentów, prowadzenia badań i dostarczania w tym samym czasie i z tymi samymi ludźmi!

Nieuchronnie prowadzą one do powstania jednorazowych produktów, które są kosztowne w opracowaniu i serwisowaniu, są podatne na błędy i zawodzą w nieprzewidywalny sposób w niepewnych warunkach. Z tego powodu, oczywiście, produkty te są znacznie szybsze, przestarzałe, spisane i zastąpione przy równie wielkich kosztach tylko nieco lepszymi. To, czego potrzebuje IT, to odpowiednik rewolucji przemysłowej, która przekształciła rzemieślników w średnim wieku w wydajne fabryki.

Jednak istnieją czynniki, które sprawiają, że IT jest naprawdę wyjątkowa. W przeciwieństwie do innych wymienionych branż, IT jest naprawdę wszechobecne: jest stosowane w każdym aspekcie naszego współczesnego życia. Jest to więc mały cud, że IT osiągnęło tak duży postęp i jest w stanie zapewnić osiągnięte wyniki.

Peter Mortensen
źródło
5
+1. Dobry przykład standaryzacji (standardowy arkusz prostej śruby). W IT rzadkie są składniki znormalizowane. Weź formularze rejestracyjne: każda strona internetowa tworzy własne, a niewielu jest programistów, którzy wiedzą, jak ich formularz rejestracyjny zachowuje się z Unicode, z pustymi ciągami, z długimi ciągami itp.
Arseni Mourzenko
1
@MainMa: słaby przykład, czy tworzysz swoje przyciski, pola tekstowe, pola opcji, pola opcji z divs? Nie, ponownie używasz elementów formularza przeglądarki; a przeglądarki korzystały z elementów formularza systemu operacyjnego.
Lie Ryan,
4
Mówiłem raczej o wnętrznościach, a nie o kontrolach. Weź losową stronę internetową. Czy możesz użyć chińskich znaków jako hasła? Czy możesz używać 25-znakowych haseł? Co się stanie, jeśli umieścisz spację w haśle lub nazwie użytkownika? Wszystko to można znormalizować, ale tak nie jest, a każda osoba wymyśla koło dla każdego projektu, często źle, tj. Bez haszowania i / lub solenia lub haseł ograniczonych do szesnastu znaków (przykład: MSN) itp.
Arseni Mourzenko
4
Zmiana IT z „rzemieślników” na „fabryki” może być niemożliwa. Fabryki realizują proces, który już został utworzony. Pracownicy fabryki wykonują swój proces bez ludzkiej myśli lub bez niej. Z tego powodu wiele fabryk zastąpiło ludzi robotami. W oprogramowaniu nie wykonujesz procesu, ale go tworzysz. Tworzenie oprogramowania byłoby bardziej zbliżone do projektowania fabryki i jej procesów niż do prowadzenia fabryki. Chociaż tworzenie oprogramowania może korzystać ze standardów, zasadniczo nie może stać się fabryką.
mike30
@ArseniMourzenko złe porównanie jest porównywać „karty danych śrub” (tj. Narzędzia, wyposażenie) ze „standardami formularzy rejestracyjnych”. Formularze rejestracyjne przypominałyby bardziej „dach” lub „drzwi frontowe” (w rzeczywistości istnieje wiele sposobów ich tworzenia). To, co porównuje śruba, przypomina zachowanie potoku procesora. Nigdzie nie jest blisko tego, czego potrzebujemy: niezawodny system operacyjny (z rygorystycznie zdefiniowanymi cechami, a nie „dane mogą trafić na dysk w zależności od zastosowanych opcji montowania”) i inne narzędzia programistyczne (muszą być w stanie sprawdzić 90% kodu dla standardu właściwości)
patrz
15

Obawiam się, że nie zgadzam się z twoim oświadczeniem.

Airbus i Boeing to dwa przykłady firm budujących samoloty. Ile jest firm budujących samoloty? Bardzo mało, jeśli porównasz to z tym, ile firm tworzy oprogramowanie.

Równie łatwo jest przykręcić projekt samolotu, jak projekt oprogramowania. Gdyby tylko bariera wejścia była tak niska w branży budowy samolotów, jak w branży oprogramowania, z pewnością zobaczysz wiele nieudanych projektów samolotów.

Spójrz na samochody; Są wysokiej jakości producenci, którzy budują bardzo trwałe i wysoce zaawansowane samochody (pomyśl Land Rover, Mercedes) i są tacy, którzy budują samochody, które nie przetrwają roku bez konieczności ich naprawy (pomyśl Kia lub Cherry). Jest to idealny przykład branży z nieco niższą barierą wejścia, jeśli zaczynasz mieć słabszych graczy.

Oprogramowanie nie jest inne. Masz wiele wadliwych produktów, z drugiej strony, Windows, Office, Linux, Chrome lub Google Search to projekty bardzo wysokiej jakości, które zostały dostarczone na czas i miały podobny poziom jakości jak samoloty.

Innym punktem, za którym wielu ludzi tęskni, jest to, ile konserwacji zajmuje utrzymanie samochodu, cysterny lub samolotu, które po prostu bierzemy za życie. Każdy samolot musi zostać poddany kontroli technicznej przed każdym startem. Musisz sprawdzać samochód co kilka kilometrów i robić to regularnie, np. Wymieniać olej, wymieniać opony.

Oprogramowanie też tego potrzebuje. Gdyby tylko ludzie poświęcali tyle samo czasu na diagnostykę, zapobieganie lub audyt stanu i jakości oprogramowania, jak w przypadku produktów mechanicznych / fizycznych, oczekiwałbym znacznie mniej takich stwierdzeń. Czy czytasz dzienniki aplikacji przed każdym uruchomieniem? Cóż ... gdyby to był samolot, musiałbyś ;-)

Karim Agha
źródło
5
Windows często nie był dostarczany na czas (Longhorn, inaczej Windows Vista, pierwotnie miał być dostarczany w 2003 roku). Nie wiem o pakiecie Office, ale większość innych projektów oprogramowania, o których wyraźnie wspomniałeś, nie ma terminów lub harmonogram ich wydań jest tak częsty, że obejmują one wszystkie funkcje gotowe w wydaniu i odpychają wszystko inne, dopóki nie będzie gotowe .
Ken Bloom
2
To lepszy przykład wysokiej jakości oprogramowania: 420 000 linii i bezbłędnie: oprogramowanie, które napędzało prom kosmiczny . Pamiętaj, że uzyskanie tego rodzaju jakości wiązało się z ogromnymi kosztami.
dodgy_coder
@dodgy_coder, Budowa bezpiecznego samolotu też nie jest tania ;-)
Karim Agha
1
@PaulNathan przyzwoity jest bardzo subiektywny;)
James Khoury
3
@KarimA .: Budowa bezpiecznego samolotu nie jest tania, ale duża część tego, co czyni go bezpiecznym, to oprogramowanie ... Tak więc ważną częścią projektu samolotu jest tak naprawdę projektowanie oprogramowania!
podziw
10

Cyfrowe elementy składowe mogą mieć wartość 1 lub 0. Pomiędzy nimi nie ma żadnej.

Konstrukcja mechaniczna ma pewien poziom tollerancji. Mogę umieścić jeden nit mniej niż idealny w moście i najprawdopodobniej nie spadnie, jednak w kodzie nawet tylko jeden raz wstawienie 0, gdzie 1 powinno być, może zawieść cały program.

Ze względu na logiczny i interaktywny charakter przetwarzania danych, nawet bardzo małe zmiany mogą prowadzić do drastycznych awarii.

Ashpool
źródło
21
Kiedyś usłyszałem, jak ktoś powiedział: „Budowa byłaby jak programowanie, gdyby po włożeniu ostatniej klamki do domu tyłem, cały dom eksplodował”.
Morgan Herlocker
9

Często zastanawiałem się nad tym samym. Z pewnością wydaje się (czasami), że jesteśmy grupą amatorów, którzy nie mają pojęcia, co robimy. Nie lubię wyjaśnień, które obwiniają menedżerów lub inne czynniki zewnętrzne - my, programiści, powinniśmy być odpowiedzialni za to, co tworzymy.

Myślę, że jesteśmy w branży, w której błędy są tanie . Oprogramowanie do łatania jest tanie w porównaniu do przebudowy wieżowca lub przywołania każdego sprzedanego telefonu komórkowego.

Stworzyło to kulturę, w której błędy są częścią codziennego życia . Są przyjmowani ze wzruszeniem ramion. Chociaż niektóre błędy są prawdopodobnie nieuniknione, czy powinny zdominować naszą codzienną pracę ? W pełni rozumiem menedżerów, którzy nie uważają, że kontrola jakości jest warta kłopotów, właśnie dlatego, że i tak oczekują błędów. Nie rozumiem programistów, którzy nie dokładają wszelkich starań, aby stworzyć bezbłędny kod, ponieważ poprawianie błędów jest nudne jak diabli.

Zasadniczo uważam, że jest to problem kulturowy i mam nadzieję, że się zmieni.

82%
źródło
5
Czy rozumiesz programistów, którzy nie dokładają wszelkich starań, aby stworzyć bezbłędny kod, ponieważ zajęłoby to dwa razy więcej czasu, a zarząd wdycha swoje gardła, aby wdrożyć te nowe funkcje wczoraj?
Beta
4
Czy nie powinno to dotyczyć również innych branż? Nie przeczę, że czynniki zewnętrzne nie istnieją, ale uważam, że zmiana musi nastąpić od wewnątrz. Gdyby inżynierowie oprogramowania przyjęli swoją rolę ekspertów w swojej dziedzinie, ich rekomendacje i szacunki byłyby przestrzegane, a kierownictwo ich nie zgadywało. A może jestem naiwny?
waxwing
2
Często jestem zaskoczony, gdy od czasu do czasu odwiedzam klienta i obserwuję, jak korzystają z produktu, który programuję. Istnieją błędy i funkcjonalność, które bardzo utrudniają ich pracę, a jako programista widzę, jak łatwo można to uczynić znacznie lepszym dla użytkownika, ale użytkownik nigdy nie narzekał, ponieważ uważa, że ​​nie warto się tym przejmować zgłosić to.
awe
7

Standardy i praktyki inżynierskie są bardzo różne w branży IT (jako niezależnej branży) niż w branży lotniczej . Być może najłatwiej to zrozumieć, biorąc pod uwagę reakcję specjalistów IT na napotkanie standardowych dokumentów IT w lotnictwie . Na przykład normy Joint Strike Fighter C ++ , które ostatnio pojawiły się w Internecie.

Wielu wyraża oburzenie lub tęskną rezygnację (szkoda, że ​​nie możemy tego zrobić); i wielu z nich szydzi, twierdząc, że nie ma praktycznego sposobu na dostarczanie produktów konsumenckich w ten sposób. Może to być właściwe, biorąc pod uwagę oczekiwania nie konsumentów, ale kierownictwa. Istnieje duża nieufność dla programistów, którzy po prostu kodują i kodują przez kilka tygodni, a nie demonstrują niczego. Boże, pomóż koderowi, który projektuje tylko przez dwa tygodnie. Nie dotyczy to samolotów.

W oprogramowaniu ludzie naprawdę oczekują czegoś w tej chwili. Jasne, rozumowanie jest takie, że zajmie trochę czasu, aby było naprawdę solidne; ale czy nie możemy w ciągu tygodnia opisać prostych rzeczy w prosty sposób? Uczy się również, że złożone rzeczy opisane w uczciwy, złożony sposób rzadko pobudzają wyobraźnię; i dlatego wielu inżynierów kończy współudział w wyobrażonym świecie, w którym naprawdę proste rzeczy są łączone w twórczy sposób (w przeciwieństwie do świata trudnych rzeczy, które są robione naprawdę dobrze).

solidsnack
źródło
5

Niektóre rzeczy ode mnie:

1- Normy i części: to producenci samolotów , a nie deweloperzy. Nie jestem do końca pewien, ale przypuszczam, że wiele części jest zlecanych na zewnątrz. Nie budują własnych urządzeń elektronicznych / instrumentów, dostają miejsca w jakiejś firmie, silniki prawdopodobnie opracowano gdzie indziej itp.

Z drugiej strony projekty oprogramowania prawie zawsze zaczynają się od zera, mając tylko kilka niewielkich frameworków / pomocników.

2 - Czas wejść na rynek: czas nie jest krytycznym problemem dla samolotów. Założę się, że projekt Airbusa został sfinalizowany na wiele lat przed jego ukończeniem, a oni postanowili zlekceważyć wszelkie przełomowe wydarzenia, które mogą się wydarzyć w tym czasie. (To samo dotyczy na przykład producentów samochodów, najnowocześniejsza technologia, którą obecnie opracowują, pojawi się na ulicach za 5-10 lat).

Jeśli chodzi o oprogramowanie, musisz być bardzo zwinny, jeśli rozpocznę teraz wielki projekt i zajmę go trzy lata bez żadnych zmian, szanse są dość duże, że polegam na technologii, która nie jest już dostępna lub mój produkt jest całkowicie przestarzały. To z kolei stwarza wiele problemów.

3- Cykl wydawania i wersje. - Samolot musi zostać całkowicie ukończony, kiedy zostanie „zwolniony”. Nie ma stabilnych wersji beta, nocnych wersji itp. Ponadto, po zakończeniu, można go modyfikować tylko w niewielki sposób. Nie możesz dodać dodatkowego poziomu ze 100 miejscami do istniejącego boeinga, to po prostu niemożliwe.

Z drugiej strony oprogramowanie ma stopniowe zmiany, które często są po prostu „kompilacjami, które działają”, ale niekoniecznie produktami gotowymi. Ponadto w branży IT nie jest niczym niezwykłym powiedzenie „hej, dodajmy kolejny bagażnik do naszego samolotu, który mieści dodatkowe 50 ton”.

racoonie
źródło
5

Myślę, że odpowiedź jest dość prosta:

1) Budowa fizyczna i wdrażanie istnieją od tak dawna, jak ludzie - mieliśmy tysiące lat na rozwój naszych metod i technik wdrażania fizycznych projektów. „Konstrukcja” oprogramowania, która wymaga zupełnie nowego i odmiennego zestawu umiejętności, ma nie więcej niż 50 lat - jeszcze nie zdążyliśmy tego wszystkiego rozpracować.

2) Konstrukcja wirtualna jest trudniejsza - musisz „zobaczyć” w swoim umyśle rzeczy, które nie mają żadnej fizycznej rzeczywistości. Wymaga to przeanalizowania i wyodrębnienia wielu informacji, zanim jeszcze dowiesz się, jak powinien wyglądać Twój produkt i jakie kroki podejmie, aby go stworzyć. Nie dotyczy to budowania mostu lub budynku.

3) Często trudniej jest znaleźć źródło awarii lub błędu oprogramowania niż w przypadku inżynierii fizycznej. Jeśli dźwigar zapadnie się, zobaczysz, gdzie jest wyboczony i zobaczysz podpory, które go przytrzymują i zawodzą, itp. Znalezienie wady oprogramowania może wymagać zbadania dużej ilości kodu i interakcji procesów - trudne, czasochłonne i niezwiązane z prawa fizyki i matematyki, takie jak struktury fizyczne.

Wektor
źródło
4

Spróbuję odpowiedzieć, używając dosłownej kopii artykułu z osadzonej muzy Jacka Ganssle'a. Chociaż mówi się, że oprogramowanie układowe jest wszędzie, wystarczy mentalnie zastąpić je oprogramowaniem.

W porównaniu do czego?

Oprogramowanie układowe jest najdroższą rzeczą we wszechświecie. W swojej cudownej książce „Augustine's Laws” Norman Augustine, były dyrektor generalny Lockheed Martin, opowiada odkrywczą historię o problemie napotykanym przez społeczność obronną. Myśliwiec o wysokich osiągach stanowi delikatną równowagę między sprzecznymi potrzebami: zasięg paliwa a osiągi. Szybkość a waga. Wygląda na to, że pod koniec lat 70. wojownicy byli mniej więcej tak ciężcy, jak kiedykolwiek. Kontrahenci, zawsze dążący do większych zysków, na próżno szukali czegoś, co mogliby bardzo kosztować, ale które nic nie ważyło.

Odpowiedź: oprogramowanie układowe. Nieskończony koszt, zero masy. Awionika stanowi obecnie ponad połowę kosztów wojownika. To drobna zmiana, jeśli weźmie się pod uwagę najnowszego amerykańskiego wojownika, F-22, który kosztuje jedną trzecią miliarda sztuk pop. Augustine praktycznie śmieje się, gdy opowiada tę historię.

Ale dlaczego oprogramowanie jest tak drogie? Tom DeMarco odpowiedział kiedyś na to pytanie tymi trzema słowami: w porównaniu z czym? Następnie zaczął omawiać stosunkowo nudne sprawy biznesowe, ale odpowiedź ta od dawna budzi mi się w pamięci. W porównaniu do czego? Za pomocą oprogramowania rutynowo tworzymy zachowania produktów o niespotykanej dotąd złożoności. Jasne, kod jest drogi. Ale nigdy w historii cywilizacji nikt nie zbudował czegoś tak skomplikowanego.

Rozważmy następujący rodzaj bąbelków, bezwstydnie zdjęty z Wikipedii i niesprawdzony pod względem dokładności:

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]);

}

To zaledwie 110 znaków spacji, być może rzuconych w ciągu godziny lub dwóch. Załóżmy, że nie mieliśmy oprogramowania i musieliśmy wdrożyć coś przy użyciu innej strategii. Ile by to kosztowało?

Inżynier mechanik może się pochwalić, że jego zawód budował sortowniki na długo przed komputerami. Zastanów się nad sortownikiem kart 82 firmy IBM z 1949 roku ( http://www.columbia.edu/acis/history/sorter.html ) o przepustowości 650 kart na minutę, a nie mniej niż nasz fragment kodu mógłby poradzić sobie nawet na częstotliwości 4 MHz Z80 Model 82 oczywiście sortował tylko jedną kolumnę karty na raz; całkowite uporządkowanie talii może zająć dziesiątki podań.

Ile czasu zajęło zaprojektowanie i zbudowanie tej bestii? Lata bez wątpienia. Jego funkcjonalność blednie w porównaniu z naszym kodem, który jest o wiele szybszy i może obsłużyć gigantyczne zestawy danych. Ale to był 1949 rok. Ile czasu zajęłoby zbudowanie bańki z komponentów elektronicznych - bez układów FPGA i VHDL lub procesora?

W ciągu godziny udało mi się stworzyć szorstki schemat blokowy, jeden powyżej poziomu układu (bloki mają nazwy takie jak „adder”, „16 bit bitch” i tym podobne). Ale logika sekwencjonowania jest dość nieładna, więc właśnie wrzuciłem PLD, zakładając, że w pewnym momencie nie będzie zbyt trudno napisać odpowiednie równania. I tak, być może łamie to zasadę braku programowalnej logiki, ale zaprojektowanie i debugowanie całej logiki przy użyciu bramek w rozsądnym czasie jest tak mało prawdopodobne, jak gaz za grosze.

Zakładając 16-bitowe słowa i adresy, obwód będzie potrzebował około tuzina 16-bitowych zatrzasków, dodatków i tym podobnych. Plus pamięć. I nie mam pojęcia, w jaki sposób nieposortowane dane docierają do pamięci RAM lub jak eksportowane są wyniki. Są to nieokreślone wymagania projektowe. Rozwiązanie programowe w naturalny sposób rozwiązuje te wymagania po prostu przez napisanie prototypu funkcji.

Przetłumaczenie zgrubnego schematu blokowego na schemat może zająć dzień. Potem jest czas na zaprojektowanie i wyprodukowanie płytki drukowanej, zamówienie i załadowanie części (i zmianę projektu, aby poradzić sobie z nieoczekiwanymi, ale nieuniknionymi problemami związanymi z końcem życia), a następnie oczywiście sprawić, by obwód działał. Moglibyśmy mówić o tygodniach wysiłku i dużo pieniędzy na płytę, części i odpowiedni sprzęt testowy.

Wszystko po to, by zastąpić 7 małych linii kodu. Niewiele prawdziwych programów osadzonych ma mniej niż 10 000; wiele przekracza milion. Ile sprzętu i ile inżynierii wymagałoby zastąpienie prawdziwego programu komputerowego o dużych rozmiarach?

Rozważmy prawdziwy program, taki jak arkusz kalkulacyjny. Ile obwodów wymagałoby zrobienie jednego bez procesora? Może to być wielkość miasta.

Oprogramowanie układowe jest najdroższą rzeczą we wszechświecie, ale tylko z powodu niewyobrażalnej złożoności problemów, które rozwiązuje. Ale jest znacznie tańszy niż jakakolwiek alternatywa. Kiedy więc szef z irytacją pyta, dlaczego oprogramowanie trwa tak długo, wiesz, co powiedzieć. W porównaniu do czego?

Więc tam! Oprogramowanie / oprogramowanie układowe ma niezrównaną złożoność.

Vaibhav Garg
źródło
3

Inżynieria oprogramowania i zarządzanie różni się zasadniczo od wielu innych dziedzin inżynierii. Produkty nie są fizyczne, a proces produkcji to proces projektowania i rozwoju. Utworzenie kolejnej kopii oprogramowania ma zasadniczo zerowy koszt krańcowy; cały koszt powstaje przy opracowaniu pierwszej kopii.

Ze względu na względną młodość inżynierii oprogramowania i zarządzania jako dyscypliny, istnieją pewne dezinformacje i kłamstwa, które są nadal uważane za fakt ( patrz odnośnik ), co utrudnia rozwój oprogramowania i inżynierii jako całości.

joshin4colours
źródło
3
+1 od niedojrzałości rozwoju oprogramowania. Inżynieria lądowa miała kilka tysięcy lat na rozwój swoich praktyk. Aerospace ma ich sto i opiera się na innych dyscyplinach inżynieryjnych. Oprogramowanie jest wciąż młode. Jest to również zwykle źle zrozumiane. Ludzie mogą budować mosty nad strumieniami lub tworzyć papierowe samoloty jako dzieci - to samo nie jest prawdą w przypadku oprogramowania.
Andy Burns
3

Nie wszyscy programiści są tworzeni jednakowo. Niektóre są dobre, inne nie są.

Spróbuj czytać kod innych ludzi przez cały czas, aby poznać to, co mówię. Zbyt wiele dodatkowych instrukcji logicznych może zwiększać ryzyko. Ryzyko to może prowadzić do złego zachowania lub błędów. Za mało instrukcji logicznych, a teraz masz odniesienia zerowe. Dobry programista rozumie to i wie, kiedy i co robić. Ale nikt nie jest idealny. Rzeczy są złożone. Dodaj kiepsko przemyślaną pracę innych i łatwo zobaczyć, jak uciekają projekty.

Książę
źródło
3

Budowanie katedr zajmowało do 100 lat.

Niektóre samoloty Airbus potrzebują do działania 1 miliona linii kodu.

Im więcej czasu coś ulepszasz, tym więcej ulepszeń możesz uzyskać, więc daj branży oprogramowania kilkaset lat próbnych błędów, aby się poprawić, a my przekonamy się, ile trzeba, aby opracować solidny, duży projekt bez błędów lub wady.

NotGaeL
źródło
Katedra w Kolonii została uruchomiona w 1248 r., A ukończona w 1880 r. 632 lata.
gnasher729,
3

Duże projekty często występują w dużych organizacjach. Jeśli nigdy nie pracowałeś w dużej organizacji, jest jedna rzecz, która gwarantuje zabicie wydajności i produktywności: biurokracja.

Zaskakujące jest to, że wiele osób nie wie, czym jest biurokracja (często mylona z polityką), a nawet jeśli / kiedy mają problem z biurokracją.

Niedawno zakończyliśmy projekt wdrożenia uwierzytelniania kart inteligentnych. Pierwotnie był szacowany na trzy miesiące. Zajęło to 15 miesięcy. Nie było żadnych kosztów, budżetu, zakresu ani technicznych przyczyn opóźnienia. Zakres był w rzeczywistości dość wąski - tylko dla kont z podwyższonymi uprawnieniami (konta administratora) około 1200 kont ogółem.

Kolejnym znaczącym czynnikiem są twoi partnerzy biznesowi. Dotyczyłoby to dostawców. Jeśli Twoi partnerzy mają problem z opóźnieniem w projekcie, nie ma wielu opcji, które naprawią problem z opóźnieniem. Nie działają one bezpośrednio dla Ciebie i możesz nie być w stanie zwolnić tej jednej osoby u partnera, który może być przyczyną. Partner może zostać zwolniony lub może podlegać karom finansowym lub zniechęcającym, ale nie zmienia to faktu, że projekt został opóźniony. Tak właśnie stało się w przypadku Boeinga, kiedy podjęli oni strategię pozyskiwania mamutów za pomocą Boeinga 787 Dreamliner .

Greg Askew
źródło
3

Mam dla ciebie krótszą wersję:

Cokolwiek jest łatwe do zrobienia lub usprawnione, piszemy program, aby to zrobić zamiast nas.

A zamiast tego walcz z meta-procesem.

Nie jest to prawda sama w sobie, ale każdego dnia tworzone są tysiące blogów, zamiast pisać silniki blogów. Każdego dnia roboczego zapisywane są tysiące makr Excela, zamiast pisać specjalnie do nich zaprojektowane aplikacje bazodanowe.

Jest wiele innych czynników - niektóre z nich tutaj wymienione - ale chciałem dodać ten punkt do dyskusji.

Aadaam
źródło
Zgadzam się. Duże programy mogą być dostarczane bezbłędnie i zgodnie z harmonogramem, ponieważ zostały wykonane sto razy w ciągu 3 dekad. Na przykład edytor tekstu.
Droogans,
Nie tylko to, ale sposób, w jaki dostarczamy duże programy bezbłędnie, co zostało zrobione wcześniej, polega na pobraniu starego programu z jego strony internetowej i wykonaniu kopii. Ale z jakiegoś powodu nie jest to udany duży projekt oprogramowania.
bdsl
3

Brak odpowiedzialności ... Ludzie zostają pozwani, gdy samolot ulega awarii. Przemysł oprogramowania nie ponosi żadnej odpowiedzialności za jakąkolwiek wadę oprogramowania, co powoduje brak motywacji do stworzenia solidnego i bezpiecznego produktu.

GreyGeek
źródło
1
Mówiłem to od dłuższego czasu. Jeśli zostaniesz pozwany, gdy Twoja aplikacja ulegnie awarii, kod byłby o wiele bardziej niezawodny ... I jest wiele firm, które chciałbym pozwać - na przykład MS: ile godzin zostało straconych z powodu wszystkich ich aktualizacji i poprawek oraz błędy i poprawki, które psują inne rzeczy. Pozwać ich za stracone godziny, a jakość SZYBKO wzrośnie.
Wektor
Gdyby tak było, koszty wzrosłyby, a funkcje zmniejszyłyby się.
Jim G.
1
@JimG. Pytanie dotyczyło niezawodności, a nie funkcji i ceny. Oczywiście konieczność wyprodukowania bardziej niezawodnego produktu wprowadzi więcej ograniczeń w przestrzeni projektowej, a inne aspekty (cechy i koszty) mogą ucierpieć.
GreyGeek
4
A koszt Boeinga 737 to 50-80 milionów dolarów. Płacisz za każdym razem, gdy dostajesz jeden - czy płacisz za każdym razem, gdy otwierasz Office? Jeśli otrzymywałbym zapłatę za każdym razem, gdy ktoś używałby mojego oprogramowania cholernie prosto, poświęciłbym się niezawodności.
FlavorScape
1
@Jim G: Wolałbym mieć 1 stabilną wersję produktu niż 5 kiepskich.
Giorgio
2

Większość dużych projektów charakteryzuje się wysokim stopniem rozdzielności podprojektów, w których można zdefiniować niewielką liczbę ograniczeń projektowych; cały projekt będzie działał po zakończeniu każdego z tych podprojektów. Jeśli coś pójdzie nie tak w podprojekcie, cały wysiłek nie jest kwestionowany; po prostu szukasz alternatywnych sposobów realizacji podprojektu (np. użyj innego silnika).

Jest to możliwe, ale trudne, zarówno praktyczne, jak i ze względu na ludzką naturę, w projektach oprogramowania.

Po części inne branże nauczyły się na własnej skórze, że tego rodzaju rozdzielność jest dobra. Na przykład, jeśli zamierzasz używać silników samolotów Rolls Royce, nie musisz używać specjalnych śrub i punktów mocowania Rolls Royce, które działają tylko ze skrzydłami o określonym projekcie, a następnie, jeśli spróbujesz przełączyć się na Pratt i Whitney, musisz przeprojektować całe skrzydło od podstaw (co z kolei wymaga całkowitego przeprojektowania kadłuba, co z kolei wymaga zakupu różnych miejsc, co z kolei wymaga zakupu innego systemu rozrywki podczas lotu, który...). Może istnieć kilka powiązań - nie można po prostu wymieniać silników bez opieki - ale duże projekty zazwyczaj działają lepiej, gdy takie rzeczy są zminimalizowane.

Postuluję, że duże projekty oprogramowania zaprojektowane jako klaster małych projektów oprogramowania z czystymi interfejsami między sobą nie zawiodą szczególnie często, o ile duży projekt jest faktycznie rozwiązany przez klaster małych projektów. (W tym względzie można popełnić błąd).

Rex Kerr
źródło
2

Budowanie systemów oprogramowania bardzo różni się od budowania struktur fizycznych. Oznacza to, że wdrożenie jest bardzo różne. Budując na przykład ogromną cysternę, wykonujesz wiele stosunkowo prostych (choć niełatwych!) Zadań, takich jak spawanie części robotem lub ręcznie, dokręcanie wszystkich nakrętek i śrub, malowanie, wykonywanie dekoracji poprzez przenoszenie wszystkich sprzęt i meble itp. Wszystko to jest bardzo proste do zrobienia, naprawdę.

Jednak jeśli chodzi o oprogramowanie, staje się ono znacznie bardziej złożone . Na przykład, w jaki sposób dokładnie wdrażasz bezpieczny login i dane logowania przechowujące część produktu? Z jakich bibliotek i narzędzi można korzystać? Z jakich bibliotek i narzędzi znasz? Jak dokładnie zajmujesz się pisaniem funkcji mieszania + solenia i jak zapewniasz jej bezpieczeństwo? Możesz to zrobić na tak wiele sposobów, że niemożliwe jest ustawienie rzeczywistych praktycznych wzorów dla tego rodzaju rzeczy. Tak, wspomniane wzorce projektowe nie istnieje na mniejszą skalę jako „najlepszych praktyk”, ale każdy system oprogramowania jest bardzo różni się od innych, a postęp terenowych i zmiany w tak szybkim tempie, że jest to w zasadzie niemożliwe, aby nadążyć.

Podczas budowy domu tak naprawdę nie napotykasz takich problemów, gdy zdajesz sobie sprawę, że główne ściany nośne wydają się nieodpowiednie i trzeba je wymienić, wymagając od ciebie zniszczenia postępów i rozpoczęcia od bazy przez ponowne wykonanie ścian nośnych . Rozwiązujesz takie problemy na etapie projektowania , ponieważ stosunkowo łatwo jest przewidzieć, jakiego rodzaju ścian nośnych potrzebuje Twój budynek.

Tak jednak nie jest w przypadku oprogramowania. Nie można tak naprawdę zaprojektować całego produktu jako pojedynczego elementu, a następnie go wdrożyć. Proces projektowania oprogramowania jest zwykle iteracyjny, a cele i wymagania zmieniają się w miarę wdrażania i testowania produktu. Rozwój oprogramowania jako całości jest iteracyjnym procesem, w którym rzeczy zwykle zmieniają się, gdy są najmniej oczekiwane, i wiele razy takie zmiany narzucają wyzwania, które wymagają więcej pracy, większej złożoności i niestety i ostatecznie więcej pieniędzy, czasu i ciężkiej pracy, aby się dobrze.

Zasadniczo powodem, dla którego trudno jest realizować duże projekty i szacować harmonogramy i plany, jest to, że tworzenie oprogramowania, a zwłaszcza działające projektowanie, są bardzo złożonymi dziedzinami. Złożoność jest głównym problemem.

zxcdw
źródło
+1, a kontynuacja pomysłu nie docenia tej złożoności osób spoza branży, która prowadzi do nierealistycznych oczekiwań, irracjonalnej polityki i nieszablonowego projektowania. Sektor publiczny w Wielkiej Brytanii jest tego doskonałym przykładem. Powiedzmy, że w przypadku budynku użyteczności publicznej kierownictwo stara się uzyskać idealny projekt z ekspertyzą, szerokimi konsultacjami i wodoszczelnym planowaniem projektu przed cięciem murawy. Ale postaw te same osoby przed nowym systemem informatycznym, a zobaczysz zmiany w ostatniej chwili wymagań, schemat db, interfejs użytkownika ... „jak trudne może być? To tylko trochę pisania”
Julia Hayward
1

Definicja „dużego projektu” jest wypaczona.

Duży projekt, technicznie, może być dostarczony na czas i bezbłędnie, pod warunkiem, że jest to coś, co budowano wiele, wiele razy na przestrzeni lat.

  • Klon Pac-Mana.
  • Kalkulator
  • Edytor tekstu

Jestem pewien, że myślisz… „ale to są małe projekty! Edytor tekstu jest prosty ”. Nie zgodziłbym się z tobą. Komputery są oburzająco skomplikowane. Po prostu instalacja i konfiguracja użytkowników w systemie operacyjnym może być czasami trudna, a nawet nie napisałeś systemu operacyjnego ani nie zbudowałeś sprzętu.

Projekty, o których mówisz, to ogromne projekty, podobne do eksploracji kosmosu. Skąd wiesz, ile czasu zajmuje rozwój podróży międzygalaktycznych? Na jakim modelu bazujemy? Masz znane, nieznane, nieznane, i wreszcie nieznane, które często pojawiają się w rozwoju oprogramowania.

Myślę, że problem polega na oczekiwaniu. To, że technologia tam jest, nie oznacza, że ​​jej użycie będzie skuteczne (lub mądre w użyciu) przez jakiś czas. Gdyby inne branże zachowywały się tak jak przemysł oprogramowania, mielibyśmy do sprzedaży odkurzacze zasilane czarnymi dziurami do końca dekady. Albo jakiś „wizjoner” miałby zasoby, aby zbudować bazę księżycową i zdecydować, że Starbucks naprawdę „dopełni” doświadczenie dla odwiedzających. Nie sądzę, że problemem jest branża oprogramowania, ale pokładane w niej oczekiwania .

Drooganów
źródło
Odkurzacze zasilane czarną dziurą? Co z bezpieczeństwem funkcjonalnym?
Peter Mortensen
Brak bezpieczeństwa funkcjonalnego? To funkcja! Zalecamy stosowanie niezmiennych struktur podczas próby czyszczenia odkurzacza z czarną dziurą.
Droogans
1

Chociaż nie jest to jedyna rzecz, o której można wspomnieć, myślę, że warto zwrócić uwagę na jedną podstawową rzecz. Większość produktów ma pasować do istniejących zachowań. Nawet produkt, który jest radykalnym przełomem (na przykład samochód), jest generalnie dostosowany do istniejących zachowań i po prostu sprawia, że ​​jest nieco prostszy / łatwiejszy / tańszy / cokolwiek to zrobić. Tak, często istnieje również pewien efekt uboczny na istniejące zachowanie (na przykład, zdobywanie paliwa dla samochodu zamiast jedzenia dla koni), ale większość z tych drugich jest raczej niewielkim efektem ubocznym.

Z drugiej strony prawie każde oprogramowanie, które nie zmienia zachowania użytkowników (na przykład pozwala im znacznie łatwiej wykonywać swoją pracę) jest zasadniczo gwarantowane jako kompletna awaria od pierwszego dnia. Co gorsza, duże projekty oprogramowania nie tylko obejmują zachowanie użytkowników na poziomie indywidualnym, ale zachowanie dużych grup - często całej organizacji.

Krótko mówiąc, zaprojektowanie samego oprogramowania jest często najłatwiejszą częścią pracy. Najtrudniejszą częścią jest przeprojektowanie miejsc pracy dla ludzi. Trudno zacząć; robienie tego w sposób, który nie tylko zadziała, ale także zostanie zaakceptowany, jest jeszcze trudniejszy.

Jerry Coffin
źródło
1

Jak wspomniałeś, Airbus A380 nie był udanym projektem. Zdarza mi się pracować w firmie CAD / CAM i powiedziano mi, że to (mieliśmy również Airbusa) opóźniło się o kilka lat, ponieważ używali innej wersji oprogramowania w innej firmie. Oznacza to, że różne części były projektowane w różnych częściach świata. Podczas integracji dowiedzieli się, że cały projekt nie może być zintegrowany, dlatego muszą przeprojektować go w jednej wersji. Patrząc na to, nie sądzę, żeby się udało. Gdyby pojawił się 2-3 lata wcześniej, byłby przełomem dla Airbusa.

Również jeśli chodzi o solidne oprogramowanie, patrzysz na każdy samolot, samochód (ABS, EPS, klimatyzację itp.) Lub wahadłowiec, mają one ponad 50% oprogramowania, które je obsługuje i wierz mi, że są bardzo solidne. Po prostu jesteśmy bliżej oprogramowania i jest o wiele więcej programów, więc widzimy w nich więcej błędów.

Odwiedź: http://www.globalprojectstrategy.com/lessons/case.php?id=23 i przekonaj się, jak bardzo udany był Airbus A380.

Peter Mortensen
źródło
1

Inżynier oprogramowania z wykształceniem inżynieryjnym i żona pracująca w budownictwie. Odbyliśmy długie dyskusje (i argumenty) na temat różnic w naszej pracy.

Inżynieria oprogramowania polega na projektowaniu nowych rzeczy . Prawie wszystko, co podstawowe, zostało zrobione gdzieś w bibliotece typu open source. W prawie każdej pracy, w której zatrudniony jest inżynier oprogramowania, musi zaprojektować coś, co nie istnieje.

W czymś takim, jak konstrukcja i większość form inżynierii, rzeczy, które w innym przypadku znajdowałyby się w „bibliotece” oprogramowania, są już w pełni zaprojektowane. Chcesz zbudować wieżę? Wystarczy skopiować i wkleić plany z istniejącej struktury, z kilkoma modyfikacjami.

W rzeczywistości jednym z głównych powodów, dla których zdecydowałem się nie zostać inżynierem, jest to, że spędzasz większość czasu na projektowaniu 10% ulepszenia istniejącego wynalazku, gdy ten sam czas można by wykorzystać na zaprogramowanie czegoś bardziej widocznego, na przykład sieci społecznościowej .

Nie ma wielu nowych projektów w inżynierii; niezwykle wykwalifikowany inżynier to ktoś, kto może zmienić istniejący projekt w coś nowego lub go ulepszyć. Ale prawie każdy programista powinien modyfikować projekty, hakować je lub tworzyć coś nowego.

Spójrz wstecz, jak daleko całkowicie zmieniły się standardy, od asemblera do C ++ do Java, JavaScript, C #, PHP i tak dalej. Nie ma zbyt wiele kodu, który można przetworzyć 10 lub 20 lat temu. To zupełnie inaczej powiedzieć… przemysł motoryzacyjny lub lotniczy, kiedy można ulepszać projekty sprzed kilkudziesięciu lat.

Zarządzanie projektami jest niezwykle trudne w oprogramowaniu . Oszacowania czasu najlepiej wykonują ludzie wykonujący pracę , ale kiedy są zajęci dokonywaniem szacunków, nie piszą kodu . To kusi ludzi, aby w ogóle unikali zarządzania projektami.

Często wiele kodów zależy od konkretnych osób, a jeśli osoby te są spóźnione lub niezdolne do wykonania, kod nie posuwa się naprzód. Natomiast jeśli chcesz zbudować samochód, możesz po prostu zatrudnić różnych ludzi do montażu opon, podwozia, akumulatora, silnika i tak dalej. Dzięki obiektowym i istniejącym frameworkom jest to możliwe, ale może nie być praktyczne, gdy projektujesz wszystko od zera.

Błędy mogą być dozwolone w oprogramowaniu . Testowanie może być kosztowne. W oprogramowaniu bardzo kuszące jest pominięcie wszystkich testów, gdy można po prostu naprawić awarię. W większości form inżynierii „katastrofa” może być śmiertelna.

Masz metody programowania, które wykorzystują rozległe testy, takie jak programowanie ekstremalne (które faktycznie było używane w megaprojektach oprogramowania). Ale z uwagi na napięte terminy (które można celowo skrócić) kuszące jest pominięcie tego programowania i uruchomienie z błędami. Joel Spolsky styl „zawsze ustalające wszystkie błędy” pozwoli zaoszczędzić więcej czasu na dłuższą metę, ale niezdyscyplinowany pominie to i niepowodzeniem.

Małe projekty są lepsze . Moja żona kiedyś poprosiła mnie o znalezienie pracy w dużej firmie. Skończyło się to argumentem, że duże firmy są złymi firmami ... dla niej, duża firma miała wiele zasobów, doświadczenia, funkcjonalnego zarządzania projektami i odpowiednich procedur. Dla mnie duża firma to dinozaur, w którym większość czasu spędzasz na naprawianiu kodu, testowaniu go i dokumentacji.

Widziałem projekty IT za milion dolarów, w których pracowało mniej niż 10 osób. Więcej osób spowolniłoby projekt i dodałoby niepotrzebnej biurokracji. WhatsApp to przykład „małego” projektu wartego miliardy dolarów. Nie jest tak, że duże projekty nie są możliwe, ale po prostu nie potrzebujesz tysięcy ludzi, aby wyprodukować miliardy dolarów w oprogramowaniu.

Muz
źródło
0

Jednym z powodów, który tak naprawdę nie został omówiony w innych pytaniach, jest to, że dziedzina oprogramowania wprowadza innowacje z prędkością, która rzadko występuje w świecie opartym na materiałach.

Jednym z powodów jest to, że ewolucja oprogramowania jest pozytywnym cyklem sprzężenia zwrotnego, ponieważ oprogramowanie (języki programowania, narzędzia do budowania, IDE) jest używane do tworzenia oprogramowania. Jest to najbardziej oczywisty przykład prawa Raya Kurzweila do przyspieszania powrotów, co skutkuje postępem z wykładniczo rosnącą prędkością. Po opanowaniu jednego frameworka, języka programowania i protokołu komunikacji czas przejść do następnego.

Gdyby samoloty zbudowano jak oprogramowanie, zmienilibyśmy materiał z każdym innym modelem, podwajaliśmy ich pojemność i prędkość co 18 miesięcy, wymienialiśmy technologię silnika dla każdego nowego modelu na coś właśnie wynalezionego, dodając jednocześnie możliwość pływania i poszukiwania kosmitów życie.

Aha, najlepiej słucha poleceń głosowych i pełni funkcję w pełni wciągającego kina, areny paintballu i klubu nocnego z ciemnym pokojem po zakończeniu podróży służbowej. To samo! (Firma, która zbudowała samoloty, które właśnie rzetelnie poprowadziły cię z punktu A do punktu B, upadła rok po wydaniu filmu z kinem, paintballem i klubem nocnym).

Peter A. Schneider
źródło
Nie rozumiem twojego punktu widzenia. Po pierwsze, wiele języków jest dość starych. Java ma ponad dwadzieścia lat. Python ma prawie trzydzieści lat. Tak, są nowe języki, ale to nie tak, że wszyscy porzucamy język, aby przejść na nowy co dwa lata. Przyjęcie nowego frameworka, IDE lub języka może być czynnikiem spowalniającym dla zespołu, nie znajduję też tych, które używają znanych narzędzi szczególnie szybko. A przemysł lotniczy? Samoloty takie jak Boeing 787 mają wiele nowych rzeczy, które były trudne do wdrożenia.
Arseni Mourzenko
@ArseniMourzenko Cóż, Java była gorąca dla programowania klienta WWW po tym, jak wyszła, i do tworzenia GUI, kiedy pojawiła się swing, ale obie mody trwały tylko kilka lat. Heck, nie było WWW przed latami dziewięćdziesiątymi. Programowanie internetowe to miejsce, gdzie samoloty były w 1910 roku. Ale to tempo trwa.
Peter A. Schneider,
-1

Dla mnie głównym problemem stojącym przed inżynierią oprogramowania są przypadki użycia, użytkownicy i platformy.

Przypadków użycia

Ile przypadków użycia ma samolot? Większość z nich to po prostu latanie z jednego miejsca do drugiego. Może jest ich więcej, takich jak radar, kontrola ruchu itp., Ale przypadek użycia jest jasny i niewiele. W inżynierii oprogramowania mamy do czynienia z niejasnymi wymaganiami i użytkownikami, którzy nie wiedzą, czego chcą. Różny użytkownik potrzebuje innej konfiguracji / przepływu, czy samolot można dostosować do własnych potrzeb (chcę mieć telewizor i lodówkę!)?

Użytkownik

Kto obsługuje samolot? Pilot, drugi pilot, niektórzy stewardzi (jeśli policzono) i operatorzy wież. Wszyscy są zawodowcami i mają jasne opisy stanowisk. Oprogramowanie jest używane przez noobów i manekinów, nie mówiąc już o złych hakerów i crackerów, a jednocześnie musi być możliwe do zintegrowania z innymi modułami (takimi jak OpenID lub Google AdSense ). Jeśli samolot może być obsługiwany przez manekiny, podczas gdy nadal żyją z rakiet lub rabusiów ninja, możesz powiedzieć, że samolot ma taką samą jakość z oprogramowaniem.

Międzyplatformowe

Samolot leci tylko na niebie na ziemi. Nie jestem pewien, jak radzą sobie w mglistym, wietrznym lub gorącym, zimnym i wilgotnym klimacie, ale samolot nie jest zaprojektowany do latania na różnym poziomie grawitacji (będę zaskoczony, jeśli będzie mógł latać na Marsa ). Czasami aplikacja musi przetrwać na różnych platformach, takich jak Internet Explorer, Google Chrome , Firefox i Safari dla przeglądarki (przepraszam Opera ), Windows XP / 7/8 lub Linux na poziomie systemu operacyjnego. Nie wspominając o urządzeniach mobilnych i różnych rozdzielczościach i orientacjach.

Fendy
źródło
-1

Jeśli uważasz, że inne branże realizują projekty bez żadnych incydentów, powinieneś przeczytać historię o budynku Citigroup Center zbudowanym w 1977 roku. Nawet po prawie 7 latach planowania i budowy budynek został ukończony z poważną wadą projektową, która spowodowałaby zawalenie się zdarzenie burzowe spodziewane jest co 16 lat.

Innymi słowy, za każdym razem, gdy Citicorp Center stał, istniała szansa 1 na 16, że się zawali.

Pierwotni projektanci nie byli świadomi problemów, ale na szczęście został złapany przez studenta studiującego budynek.

wszystko wydawało się w porządku - dopóki, jak mówi LeMessurier, nie zadzwonił. Według LeMessuriera, w 1978 r. Student architektury pierwszego roku skontaktował się z nim odważnie twierdząc o budynku LeMessuriera: że Citicorp Center może się zdmuchnąć na wietrze.

Napraw dokonywano dosłownie pod osłoną nocy z udziałem jak najmniejszej liczby osób, aby zachować tajemnicę błędu projektowego.

Przygotowano plan ewakuacji dla promienia 10 bloków otaczającego budynek.

Spawali przez całą noc i wychodzili o świcie, gdy mieszkańcy budynku wracali do pracy.

Historia pozostała tajemnicą, dopóki pisarz Joe Morgenstern nie usłyszał jej opowieści na imprezie i nie przeprowadził wywiadu z LeMessurier. Morgenstern przerwał tę historię w The New Yorker w 1995 roku.

Co nasuwa pytanie; ile innych fatalnych wad projektowych zostało potajemnie naprawionych lub zignorowanych bez publicznego potwierdzenia.

cmcginty
źródło