🚀 go-pugleaf

Witam

Filip Sielimowicz wrote:

> Nie zgodzę się z takim sposobem argumentacji, gdzie pojawiają się
> np. pojęcia "zupełnie inne charakterystyki" ;). Analogii jeszcze tu nie
> skonstruowaliśmy, a już pada określenie 'totalnie chybiona" ;).

[...]

Bazrdzo dobre wyabstrachownie problemu.

Może dodam tylko, taki wniosek racjonalizatorski. W informatyce jak i w
architekturze dość dobrze są opracowane metody specyfikowanie, i
projektowania. Natomiast IMHO miażdząca różnica polega na: 

1. Time to market. W budownictwie nikt się tak nie śpieszy. To znaczy jak
się ktoś pospieszy, to się to kończy jak z budową jednego mostu w Wawie,
gdzie ktoś "przeoczył", że pod nim nie mogą przejeżdżać ciężarówki. To jest
tak jakby ktoś w programie zapomniał czegoś ważnego i potem poprawka kończy
się przepisaniem kodu w większości od zera. Ile jest takich błędów w
informatyce a ile w budownictwie? A wszystko z powodu pośpiechu.

2. Częstotliwość i rozmiar wprowadzanych zmian do specyfikacji. Znajomi
architekci czasami muszą coś zmienić w projekcie, bo klient coś zażądał
innego, ale nie widziałem, aby to było tak częste jak w informatyce.

3. Cena przebudowy systemu, która odstrasza klienta od wydziwiania po
zamknięciu projektu. 
Czyli projekt budynku jest zamknięty i że się tak wyrażę "Chłopaki wylały
dekę.". Klient, który powie, że on chce dodatkową windę, 2 pokoje i
oranżerię za zmianę zapłaci masę kasy -- więc generalnie po zaczęciu budowy
nic się nie zmienia. 
W programowaniu tak nie jest, często pojawiają się nowe żądania już po tym
jak ruszyła maszyna kodowania. Menedżerom wydaje się, że jak klient żąda
dodatkowego ficzeru, to przecież trzeba mu to dać, to to czasem powoduje
zmianę w projekcie na tyle dużą, że trzeba go robić w dużej mierze od zera
a tego już manago nie mają ochoty słuchać, tylko każą łatać kod na siłę.
Takie łatanie projektu architektonicznego nie ma szans nigdzie przejść, bo
balkonów się nie doszywa niciami szewskimi, tylko potrzeba wszystko tak
przeprojektować aby balkon można było dodać.

4. Marketingowe zamydlanie oczu, że w informatyce to wszystko staje się
takie łatwe jak tylko stosuję się "technologię XYZ". Tego nie ma w
budownictwie. A na to często nadziewają się menedżerowie.

5. Ostatnia sprawa częstotliwość (szybkość) zmian narzędziowych w
informatyce vs. w budownictwie. Do tego należy dodać że tak jak w
informatyce jest wiele języków każdy ma inne podejście i w większości
przypadków można dany problem rozwiązać na bardzo wiele sposobów począwszy
od doboru języka poprzez modułów/bibliotek/frameworków itd. Kombinacji dróg
prowadzących do celu jest bardzo dużo. W budownictwie fizyka dość szybko
redukuje liczbę ścieżek sukcesu. 

6. Wiek dziedziny jako dziedziny naukowej: informatyka -- śmiech na sali,
budownictwo -- szacowna persona. Tak więc nie ma się co dziwić, że w
budownictwie jest bardziej wszystko ustabilizowane. 

Ale już na granicy budownictwa i informatyki, czyli np. w automatyce
budynków pojawiają się kłopoty typowe dla informatyki.

No i przykłady budownictwa z RPL mogą dobrze wskazywać, że budowę też można
spartaczyć.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/