Użytkownik <m...@t...pl> napisał w wiadomości grup
dyskusyjnych:5...@n...onet.pl
...
> Każdy projekt i w każdym języku się spaprze gdy wymogi w przyszłości
> nas zaskoczą. Dlatego lepiej jest zrobić gorszy projekt, mniej dopasowany,
> ale bardziej odporny na zaskoczenia. Ostatnio dochodzę do wniosku, że

???

Aby rozróżniać lepsze-gorsze potrzeba wprowadzić relację porządku, czyli
możliwość porównywania a < b .

Takich relacji można podać wiele różnych. Na przykład: wielkość programu,
szybkość jego działania... ale także zyski ze sprzedaży, przenośność,
łatwość obsługi itp.

Zawsze realizujesz - niezależnie od tego czy tego chcesz czy nie -
subiektywnie najlepszy projekt. Choć być może i tak, że kryterium będzie:
"zrobić najgorzej działający program, który doprowadzi firmę do upadku". Po
prostu ludzie działają subiektywnie racjonalnie.

> idealny projekt to taki, w którym mam dużo i obojętnie jak spapranych
> części. Gdy przyszłość mnie zaskakuje, to cała część idzie do kosza i
> jest pisana na nowo. Nikomu po czasie o tal nie będzie chciało się wgryzać
> w
> stary kod.

Jeżeli robisz cokolwiek odpowiedzialnego, to "wgryzanie się" może być
konieczne. Bo program jest komuś potrzebny, a potrzeby mają to do siebie, że
ewoluują. I łatwiej jest np. gdy zmienił się format danych nieco przerobić
2% kodu źródłowego - niż pisać wszystko od nowa.

Cały cyrk polega właśnie na umiejętności sprzedawania tego samego Burka -
czyli używania tego co się raz zrobiło - po wielokroć. Jeżeli potrafisz w
kolejnym projekcie użyć 90% ze starego... to po prostu piszesz 10x szybciej
i robisz 10x mniej błędów.