Czy inżynieria programowania to inżynieria?

W pobocznym komentarzu tego wątku https://4programmers.net/Forum/Nietuzinkowe_tematy/353385-narzedzia_wspomagajace_pisanie_kodu_a_plagiaty_i_licencje_wirusowe zaczęliśmy sobie dyskutować o czymś, co nie ma większego znaczenia, ale chyba warto przegadać temat.

W tradycyjnej inżynierii celem jest stworzenie czegoś materialnego. Architekt, czy projektant przygotowuje projekt, następie wykonawcy stawiają ściany, kładą instalacje, podłogi, tynki itd. Po tym etapie zmiana czegokolwiek w projekcie jest trudne i kosztowne, odzyskanie raz zużytych materiałów praktycznie nie możliwe.

W uproszczeniu mamy projekt za 5000 złotych, wytworzenie tego co on definiuje, kosztuje 500 000 zł. Możliwe, że z czasem rozwój technologii w budownictwie spowoduje, że koszty replikacji spadną (roboty, inne materiały), ale na razie jest tak jak napisałem.

Dla odmiany w programowaniu produktem jest instrukcja dla maszyny, w jaki sposób powinna działać. Powstaje ona od poziomu ogólnego do coraz bardziej szczegółowego:

1. Chcę system który potrafi dodawać liczby wprowadzone przez użytkownika.
2. Parametry i wynik mają być przyjmowane jako parametry żądania http.
3. Usługa ma działać w chmurze.
   4 Deploy usług ma się odbywać zgodnie z definicją umieszczoną w CD.
4. Ktoś wpisuje return a+b, co stanowi ostateczne uszczegółowienie tego co i jak system ma robić.
5. Wpisujemy git push i następuje wykonanie wcześniej zaplanowanych czynności, usługa staje się dostępna.

Kwestią drugoplanową jest, czy w trakcie któregoś z tych kroków powstaje diagram UML, dokument w Wordzie, czy jedziemy na żywca z kodem i czy robi to wszystko jedna osoba, czy 50 osobowy zespół. Większość czasu i kosztów tego projektu jest związane z pisaniem (dokumentacji, lub kodu), zaledwie drobna część z faktycznym deploymentem, aka "produkcją". To sugeruje, że metody stosowane w tradycyjnej inżynierii ni jak się mają do tworzenia oprogramowania, a praktycznie całość procesu tworzenia oprogramowania, to tak na prawdę coś, co można nazwać "projektowaniem" na coraz wyższych stopniach precyzji.
O ile w przypadku domu projekt to 2% jego wartości, to w przypadku systemu komputerowego projektem jest 99.99% Jeżeli usługa sieciowa nie przemawia, to pomyślcie o grze - "wyprodukowanie" egzemplarza gry to pobranie jej przez użytkownika. Błędy to skutki tego, że ktoś nie zaprojektował czegoś, lub zrobił to niedostatecznie starannie i nie zalicza nam jakiegoś lvl, pomimo zastrzelenia bossa. Zmiana definicji co i jak ta gra ma robić jest stosunkowo prosta (dobra, bywa różnie, ale wciąż, to nie przebudowa domu publicznego na kościół). Rozpropagowanie tej poprawki, to grosze.

Teza:
Blisko 100% tworzenia oprogramowania to tworzenie (uwaga, abstrakcja) projektu co i w jaki sposób, to oprogramowanie ma robić.

W tradycyjnej inżynierii celem jest stworzenie czegoś materialnego

Możesz przytoczyć źródło takiej definicji? Bo mnie się jednak wydaje że inżynieria polega na wykorzystaniu istniejącej wiedzy i narzędzi do rozwiązania konkretnego problemu. Wynikiem ma być rozwiązanie problemu, nie coś materialnego.

Zgodnie z twoją logiką jakaś inżynieria chemiczna też nie jest inżynierią, bo oni tam przecież opracowują tylko jakiś przebieg reakcji chemicznej i proces! Tak samo inżynieria materiałowa, przecież ci ludzie zajmują się opracowywaniem struktury nowych materiałów i procesów fizycznych które pozwalają je uzyskać.

Jeśli chodzi o inżynierie oprogramowania to mam wrażenie że mylisz kod z systemem informatycznym. To mniej więcej taki sam błąd jak mylenie programowania z inżynierią oprogramowania. System informatyczny składa sie z wielu elementów i kod jest tylko jednym z nich. Hardware jest także częścią systemu.

Tak, to inżynieria. Nawet wiki się "kłóci" z Twoją definicją inżynierii.
https://pl.wikipedia.org/wiki/In%C5%BCynieria

@Shalom:

Inżynieria – działalność polegająca na projektowaniu, konstrukcji, modyfikacji i utrzymaniu efektywnych kosztowo rozwiązań dla praktycznych problemów, z wykorzystaniem wiedzy naukowej oraz technicznej. Działalność ta wymaga rozwiązywania problemów różnej natury oraz skali. Bardziej ogólnie, inżynieria zajmuje się też rozwojem techniki i technologii.

W ściślejszym (systemowym) sensie, inżynieria to używanie właściwości materii, energii oraz obiektów abstrakcyjnych dla tworzenia konstrukcji, maszyn i produktów, przeznaczonych do wykonywania określonych funkcji lub rozwiązania określonego problemu.

Inżynier wykorzystuje wyobraźnię i doświadczenie, umiejętność oceny i rozumowanie, stosując świadomie własną wiedzę do projektowania, tworzenia, eksploatacji i usprawnienia użytecznych maszyn oraz procesów (np. inżynieria procesów produkcji, inżynieria środowiska, bioinżynieria).

Źródło dyskusyjne, ale nie chce mi się kłócić na temat drugorzędnej regułki https://pl.wikipedia.org/wiki/In%C5%BCynieria

Co do drugiej części, we współczesnym podejściu:
Masz chmurę, w której ktoś faktycznie musi się nabiedzić z fizycznym połączeniem serwerów, zasilaniem, chłodzeniem, przepustowością i izolacją sieci. ale, już pięterko niżej, czyli jako programista masz do dyspozycji możliwość:

• definiowania infrastruktury IaaC
• definiowania sieci
• definiowania usług zarządzalnych PaaS
• definiowania procedury delivery

Jeżeli to ma znaczenie, to możesz sobie te rzeczy wyklikać, ale możesz je również wrzucić do pliku z parametrami, albo nawet oprogramować jak ta infrastruktura ma się zachowywać w odpowiedzi na zmiany otoczenia. Jak się ładnie postarałeś, to bierzesz sobie taką definicję, odpalasz na koncie obok i kopia twojego systemu informatycznego pojawi się obok.

@piotrpo analogicznie możesz wziąć sobie zestaw reakcji chemicznych, przeprowadzić je w dowolnym laboratorium i uzyskać pewne substancje. Czy to oznacza ze inżynier chemiczny który te procesy opracował nie jest inżynierem? A inżynier który zaprojektował jakieś urządzenie i przygotował konfiguracje dla drukarki 3d? Też możesz wziąć ten jego projekt, wrzucić w dowolną drukarkę i dostaniesz "kopie" urządzenia. Czy ten ktoś w takim razie też nie jest inżynierem? o_O
A ktoś kto zrobił w VHDLu procesor? Można sobie to wziać i załadować na dowolne FPGA. Też nie jest inżynierem, bo nie wytrawił sobie tego w krzemie?

Spróbuję krócej z większą koncentracją na faktycznym problemie:
Pomiędzy tradycyjną inżynierią (budowa maszyn, budownictwo, technologia przetwarzania żywności) a inżynierią oprogramowania istnieje duża dysproporcja pomiędzy "projektowaniem" a "wytwarzaniem". Ten (moim zdaniem) fakt implikuje zmianę jakościową w obu podejściach. Tak jak nie da się zbudować elektrowni atomowej w metodyce zwinnej, bo każdy błąd na etapie projektu ciągnie za sobą gigantyczne koszty. Tworząc oprogramowanie, jak ci wyjdzie, że potrzebujesz zmienić np. SOAP na REST możesz zrobić to w sposób banalny, bo wciąż zmieniasz "projekt".
Uważam, że granica typu "UML to jeszcze projekt, a kod w C++ to już implementacja" jest błędnym podejściem.

Czyli to że soft można robić na pałę i popełniać błędy, bo je można relatywnie tanio poprawić sprawia że SE to nie inżynieria?

o to chodzi?

@piotrpo: Idąc Twoim tokiem rozumowania gdyby w SE nie istniała metodyka zwinna a tylko waterfall to można by ją nazywać inżynierią, ale ponieważ metodyka zwinna istnieje to o inżynierii nie może być mowy.

Pomiędzy tradycyjną inżynierią...

Świat idzie do przodu, definicje rozszerzają się na nowe pola które kiedyś nawet nie istniały. W przeciwnym razie w języku angielskim nie można by również mówić software developer, bo tradycyjnie to ktoś kto buduje budynki.

@piotrpo:

To jeden ze skutków podejścia "my tylko piszemy". Napisanie czegoś inaczej, to generalnie mniej roboty niż przesunięcie przyczółku mostu o 50m w prawo. —

ale to może po prostu specyfika tej branży, a mianowicie możliwości oraz tego, jak je wykorzystano?

Boomerzy kiedyś tam się postarały aby źle napisany software nie doprowadzał do pożaru w datacenter, aby błędy powodowały jak najmniejsze szkody i teraz koszty błędów są relatywnie niskie oraz aby było to elastyczne - już nie karty perforowane

Aby dojść do aktualnego stanu poświęcono pewnie miliony man hours

@WeiXiao: Ale ja właśnie o tej specyfice branży piszę. Replikacja produktu IT w postaci apki na telefon, to całkowicie zautomatyzowany proces kosztujący może centa. Replikacja domu to koszt kilkuset tysięcy złotych. W pierwszym przypadku koszt "zaprojektowania" jest drogi, w drugim odwrotnie - koszt replikacji.

Weźmy na tapet projektowanie CPU (w sumie już opisane, ale się rozpisałem to wrzucę tutaj). Jest tutaj dużo etapów niewymagających zmian w produkcji realnych kawałków krzemu. Po pierwsze na początku tworzy się projekty CPU w językach typu VHDL czy Verilog, które wcale nie muszą być jakoś bardzo odległe od zwykłych języków programowania. Ba, można nawet pisać kod źródłowy procesorów w OpenCLu czy nawet w C++ (chociaż to raczej nisza):

The Intel® HLS Compiler is a high-level synthesis (HLS) tool that takes in untimed C++ as input and generates production-quality register transfer level (RTL) code that is optimized for Intel® FPGAs. This tool accelerates verification time over RTL by raising the abstraction level for FPGA hardware design. Models developed in C++ are typically verified orders of magnitude faster than RTL.

Po drugie, po stworzeniu wstępnego projektu procesora, symuluje się go na FPGA, czyli czymś co można zaprogramować wiele razy, dokładnie tak jak zwykły komputer. Po każdej symulacji można poprawić wykryte błędy, coś zoptymalizować, dorzucić nową funkcjonalność i przeprogramować FPGA od nowa. Po trzecie, sporo błędów w gotowych CPU produkowanych jako układy ASIC łata się mikrokodem, czyli de facto skompilowanym programem zapisanym wprost w pamięci stałej w CPU.

Te błędy, których nie da się naprawić mikrokodem, naprawia się w kolejnym steppingu https://en.wikipedia.org/wiki/Stepping_level . Polecam poszukać frazy "intel cpu errata". Wynik to np: https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html Czasami błędy są na tyle poważne (chociażby wizerunkowo) i niemożliwe do załatania, że producent organizuje zwrot produktu, np: https://en.wikipedia.org/wiki/Pentium_FDIV_bug

Nikt nikomu podczas projektowania CPU nie zabrania zrobienia w nim pętelki czy rekurencji na jawnym stosie (oczywiście trzeba to rozdzielić na wiele taktów, ale generalnie da się). Mamy wtedy kod trochę jak w zwykłym programie. Jest to jednak pewnie często nieoptymalne. Z drugiej strony, pętelek i rekurencji unika się nie tylko w projektowaniu procesorów, ale także np. w programowaniu GPGPU.

Jednak wyrzuciłbym ten cudzysłów z zaprojektowania i faktycznie dodał tam i zaimplementowania oraz utrzymania

No dobra, a jak tak cały czas kręcimy się w okół tych kosztów

A czym jest fabryka procesorów? no bo wiesz, największe koszta to pewnie wybudowanie, wyposażenie, eksploatacja, know how i to są pewnie jakieś $20 miliardów, a koszt wytworzenia jednego CPU to jakiś bardzo mały %

piotrpo napisał(a):

@WeiXiao: Ale ja właśnie o tej specyfice branży piszę. Replikacja produktu IT w postaci apki na telefon, to całkowicie zautomatyzowany proces kosztujący może centa. Replikacja domu to koszt kilkuset tysięcy złotych. W pierwszym przypadku koszt "zaprojektowania" jest drogi, w drugim odwrotnie - koszt replikacji.

Co ma koszt do definicji czym jest inżynieria? Uczepiłeś się tego materializmu jak Einstein fizyki kwantowej i na siłę próbujesz nas tym zainteresować.

piotrpo napisał(a):

W tradycyjnej inżynierii celem jest stworzenie czegoś materialnego.

Często, aczkolwiek nie zawsze. Czasem wystarczy opracować procedurę albo proces optymalizacyjny.

Architekt, czy projektant przygotowuje projekt, następie wykonawcy stawiają ściany, kładą instalacje, podłogi, tynki itd. Po tym etapie zmiana czegokolwiek w projekcie jest trudne i kosztowne, odzyskanie raz zużytych materiałów praktycznie nie możliwe.

W programowaniu też za bardzo nie da się odzyskać raz zużytych materiałów. :P

O ile w przypadku domu projekt to 2% jego wartości, to w przypadku systemu komputerowego projektem jest 99.99%

Not even wrong.

Po pierwsze system komputerowy w znacznej mierze składa się ze sprzętu, więc skupianie się na kodzie jest bez sensu.
Jeśli zaś chodziło Ci o system informatyczny, to nadal, projekt jest jakąś niewielką jego częścią, a patrząc na sporą część z nich, to zdaje się, że projektu nigdy nie było. Główną częścią jest jednak implementacja.

Jeżeli usługa sieciowa nie przemawia, to pomyślcie o grze - "wyprodukowanie" egzemplarza gry to pobranie jej przez użytkownika.

Ty tak na serio? Bo brzmisz jak student, który narzeka na to, że musi zapłacić 5 stówek za projekt zaliczeniowy z programowania, a przecież "cała gra w sklepie kosztuje 100zł".
Pobieranie egzemplarza gry nie ma nic wspólnego z inżynierią oprogramowania.

Błędy to skutki tego, że ktoś nie zaprojektował czegoś, lub zrobił to niedostatecznie starannie i nie zalicza nam jakiegoś lvl, pomimo zastrzelenia bossa.

Czasem błędy wynikają z projektu, niemniej jednak wiele z nich wynika z błędnej implementacji, niewystarczającego testowania albo niepoprawnego wdrożenia.

Ogólnie sugeruję wziąć jakiś podręcznik o wytwarzaniu systemów informatycznych i zapoznać się po kolei z fazami jego tworzenia począwszy od analizy, poprzez projekt, implementację, wdrożenie, utrzymanie aż do wygaszenia.
Zresztą, podręcznik... praca inżynierska powinna wystarczyć.

Osobiście uważam, że IO daleko jest do inżynierii klasycznych poprzez brak ograniczeń fizycznych w wytwarzaniu oprogramowania, a co za tym idzie możliwe jest wytworzenie dowolnie kuriozalnej, niewydajnej i niespójnej konstrukcji, i dlatego często wstyd to zestawiać z normalnymi inżynieriami, w których jak zacznie się stawiać ciężkie elementy na mało wytrzymałych, albo zamocuje coś za słabo, to się na łeb spierdzieli albo go w ogóle utnie, więc klasyczni inżynierowie szybciej się uczą na błędach. ;)

Tak, inżynieria programowania to inżynieria, a używając Twojej analogii budownictwa, nie od każdej osoby która robi remont kawalerki są od razu wymagane pokłady inżynieryjnej wiedzy, dokładnie tak samo jest na przykład w projektach legacy. Budowanie małego garażu nie jest porównywalne z budowaniem mostu, a również w IT są projekty o skali małej i ogromnej.

Słowo "inżynier" pochodzi od "wynalazek", więc może mieć zastosowanie zarówno w inżynierii mostów, oprogramowania, genetyce jak i w inżynierii społecznej.

Słowa „inżynieria” i „inżynier” pochodzą od francuskich słów ingénieur oraz ingénierie. Określenia te pochodzą z kolei od starofrancuskiego terminu engigneor, które oznaczało konstruktora machin wojennych.

Fr. ingénieur 'człowiek twórczego umysłu, wynalazca, konstruktor' jest wyrazem ogólnoromańskim (z łacińskiego ingeniosus (wł. ingegnoso) oznaczającego osobę wyszkoloną), co pochodzi z łac. ingenium 'wynalazek').

Każdy z nas ma jakiś swój uproszczony obraz świata go otaczającego tylko nie każdy próbuje te uproszczenia wciskać innym.

somekind napisał(a):

piotrpo napisał(a):

W programowaniu też za bardzo nie da się odzyskać raz zużytych materiałów. :P

Wielokrotnie, jak spotykam inteligentnego przedstawiciela architektury budowlanej, staram się sprowokować fajny wątek.
I nasza największa różnica do budowy klasycznej, to gruz jest niewidzialny
Gdyby u inwestora tradycyjnego (zwalmy, że zmiany = zmieniające się wymagania) koło prawie wybudowanego budynku rosła kupa gruzu porównywalna wielkością, głowy by się posypały i to szybko, gwarantowane.
Ale u nas jest niewidzialny ...

somekind napisał(a):

Osobiście uważam, że IO daleko jest do inżynierii klasycznych poprzez brak ograniczeń fizycznych w wytwarzaniu oprogramowania, a co za tym idzie możliwe jest wytworzenie dowolnie kuriozalnej, niewydajnej i niespójnej konstrukcji, i dlatego często wstyd to zestawiać z normalnymi inżynieriami, w których jak zacznie się stawiać ciężkie elementy na mało wytrzymałych, albo zamocuje coś za słabo, to się na łeb spierdzieli albo go w ogóle utnie, więc klasyczni inżynierowie szybciej się uczą na błędach. ;)

Głębokie stwierdzenie, podoba mi się
Mają większą, intuicyjną barierę odejścia od dobrych praktyk i wzorców (tfu, tfu - nie rozumiem religijnie, co więcej, wzorce u nich są zdrowsze)
Balkon stojący na wątłym patyczku, tego nie da się ukryć, hamulec jest naturalny

AnyKtokolwiek napisał(a):

Wielokrotnie, jak spotykam inteligentnego przedstawiciela architektury budowlanej, staram się sprowokować fajny wątek.
I nasza największa różnica do budowy klasycznej, to gruz jest niewidzialny
Gdyby u inwestora tradycyjnego (zwalmy, że zmiany = zmieniające się wymagania) koło prawie wybudowanego budynku rosła kupa gruzu porównywalna wielkością, głowy by się posypały i to szybko, gwarantowane.
Ale u nas jest niewidzialny ...

Pytanie, czy to jest niewidzialny gruz, czy wypełniony wcześniejszymi koncepcjami kubeł na papiery (trzymając się podejścia budowlanego).

piotrpo napisał(a):

AnyKtokolwiek napisał(a):

I nasza największa różnica do budowy klasycznej, to gruz jest niewidzialny

Pytanie, czy to jest niewidzialny gruz, czy wypełniony wcześniejszymi koncepcjami kubeł na papiery (trzymając się podejścia budowlanego).

Za kubeł na papiery nikogo nie wyrzucili (tam, jako się rzekło, to TYLKO 2%).
Co więcej, dobrze, ze jest to na tym etapie, a nie na budowie - to jest PRAWIDŁOWE miejsce do zmian

piotrpo napisał(a):

Pytanie, czy to jest niewidzialny gruz, czy wypełniony wcześniejszymi koncepcjami kubeł na papiery (trzymając się podejścia budowlanego).

Nieważne, czy gruz jest widzialny, czy nie, ważne ile jego stworzenie poszło dni roboczych. No, ale w sumie czasu też nie widać, więc pewnie nie istnieje. ;)

AnyKtokolwiek napisał(a):

piotrpo napisał(a):

AnyKtokolwiek napisał(a):

I nasza największa różnica do budowy klasycznej, to gruz jest niewidzialny

Pytanie, czy to jest niewidzialny gruz, czy wypełniony wcześniejszymi koncepcjami kubeł na papiery (trzymając się podejścia budowlanego).

Za kubeł na papiery nikogo nie wyrzucili (tam, jako się rzekło, to TYLKO 2%).
Co więcej, dobrze, ze jest to na tym etapie, a nie na budowie - to jest PRAWIDŁOWE miejsce do zmian

Coś nowego mnie oświeciło.
Tu dotykamy szerszego problemu,.
Nie tylko my, ludzie IT mamy swoje grzechy - ale nasz klient ma mniejszą wyobraźnię co do zmian na etapie 2%, w czym WYCHOWUJE ich (klientów) "od wieków" niewidzialny gruz.
Przecież zmiany w oprogramowaniu nic nie kosztują.

Nie wiem, może na super-korpo i waterfallu przenosi się na klienta koszt jego szalonych zmian (albo z góry daje się margines cenowy 300%) , ale na rynku dolno-średnim bardzo rzadko tak się dzieje.
A jeśli, to raczej na poziomie ludzkim: no wiesz Kazik / Rysiek / Władek, zrobiliśmy wq..ę zmian, które chcieliście i poszły do kosza i jak Kazik / Rysiek / Władek ma klasę, to zapyta ile dopłacić.

@AnyKtokolwiek:
To kwestia intuicyjności. Jak klient chce móc się przemieszczać z punktu A do punktu B a po środku jest rzeka, to wie też, że chce most a nie koniecznie katapultę. U większości ludzi myślenie o czymś co ma, bądź ma mieć postać fizyczną jest dużo bardziej naturalne. Mamy to zakodowane przez ewolucję, że większe znaczy lepsze (kupcie 3 latkowi małą wywrotkę i dużą wywrotkę, to zobaczycie którą wybierze). Nie jesteśmy też przyzwyczajeni do tego, że coś co nie jest materialne kosztuje.

Inżynieria oprogramowania to jak najbardziej inżynieria, natomiast często zwrotu "inżynieria oprogramowania" używa się po prostu źle. Samo klepanie kodu na podstawie wymagań nie jest inżynierią, ale już projektowanie, wycena, monitorowanie/tuning itp. już tak. Dlatego według mnie inżynier oprogramowania powinien być czymś więcej niż zwykłym programistą.