Andrzej Jarzabek wrote:

>>> I w sytuacji, kiedy nad kodem pracuje wielu programistów,
>>> (i powiedzmy mamy możliwość zatrudnienia programistów znających
>>> odpowiednie techniki), to narzucenie użycia technik obiektowych, w
>>> języku wspiejającym obiektowość, znacznie skuteczniej osiąga ten cel niż
>>> robienie tego proceduralnie/strukturalnie.
>>
>> To jest zawsze coś za coś. Można znacząco zwiększyć zespół, lub znacząco
>> wydłużyć czas powstawania projektu (tym samym znacząco zwiększając jego
>> koszt, lub sprawiając że potencjalny zamawiający w ogóle nie będzie
>> zainteresowany), trzymać się jakiejś ustalonej formy i mniej martwić
>> ewentualnymi zmianami pracowników. Jest to tym łatwiejsze im mniej
>> powstanie, dzięki narzuceniu ograniczeń.
>> Inna opcja to zaryzykować, zrobić coś szybciej, a w razie czego trochę
>> więcej czasu poświęcić na przejmowanie przez jednego pracownika, tego co
>> zrobił inny. Trudność jest tu tym większa w porównaniu z bardziej
>> sformalizowanym sposobem prowadzenia projektu, że do przejęcia jest dużo
>> więcej - bo to więcej w ogóle miało szansę powstać.
>
> A trzecia opcja to przyjąć zestaw dobrych praktyk, np. zawierających
> między innymi poprawne i sensowne stosowanie technik obiektowych,

Przy czym techniki, które były poprawne przy projekcie X - które zostały
spisane podczas jego tworzenia, mają dużą szansę być błędne przy projekcie
Y.
Gdyby drugi/trzeci/czwarty raz robić od nowa ten sam projekt, to pewnie
dałoby się spisać, które praktyki są dobre a które złe. Tyle że kolejny raz
ten sam projekt robi się tylko w niektórych dziedzinach, jak np.
kompilatory, gdzie od lat rozwija się na ich temat zarówno teoria jak i
praktyka.
W bardziej - że tak to określę - zwyczajnych projektach, przed ich
rozpoczęciem nie ma się tak dużej wiedzy, co się tam sprawdzi a co nie.

> No więc analogicznie do twoich wypowiedzi, z których można wywnioskować,
> że nie rozumiesz o co chodzi z programowaniem obiektowym, z powyższej
> wypowiedzi też można łatwo wywnioskować, że jeśli ktoś stosował coś
> takiego jak "metodologia agile",

Nie pamiętam, czy tak to określali, czy inaczej. Natomiast ogólny sens był
taki: udało się ---> zastosowali, nie udało się ---> zastosowali
nieprawidłowo.

> to albo kompletnie nie rozumie o co
> chodzi, albo stosował jakąś swoją własną metodę, w związku z czym trudno
> się dziwić, że jeden stosował swoją własną metodę projekt się udał, a
> ktoś inny też stosował swoją własną, i projekt się nie udał.

Przecież praktycznie każda metoda tworzenia oprogramowania jest dość ogólna.
Gdyby była w 100% precyzyjna, program mógłby być tworzony przez generator,
zamiast człowieka.