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

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ę?

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.

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.

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.

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.

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?

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.

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.

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.

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

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.

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.

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).

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”.

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.

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ść.

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.

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.

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.

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 .

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.

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.

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).

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.

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 .

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.

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.

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.

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).

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.

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.

• Błąd projektowy, który prawie zniszczył wieżowiec w Nowym Jorku (slate.com)
• Citigroup Center (wikipedia.com)