Zanim zaczniesz kodować, zapytaj dlaczego

@kodyak tylko jeśli miernikiem wartości jest ilość naklepanego kodu, a nie rozwiązanie problemu.

@MostlyRenegade ależ to rozwiązuje problem a na coś nowego robi się cr i wystawia się kolejna fakture

@kodyak to nie zawsze tak działa. Klienta interesuje działający produkt. Jeśli produktu nie ma lub nie działa, zaczynają pretensje. I potem, zgodnie z hierarchią, wszystko to spada na szeregowego kodera: "dlaczego to nie działa", "miałeś to zrobić miesiąc temu", "na kiedy to będzie, bo już klient/zarząd się piekli", "zrób to na wczoraj, tylko popraw jeszcze to i to (czyt.: rozwal architekturę systemu, bo nie działa im jeden konkretny przypadek)", i moje ulubione: "<dodaj jeszcze na jutro taki pipsztyk, który będzie wymagał tygodnia roboty i przerobienia połowy interfejsu, nie dając w zamian absolutnie żadnej wartości dodanej, ale klient tak chce>".

A programista to zwierzę z natury leniwe, bo wie, że informatyzacja ma, z założenia, ułatwiać robotę i jej odejmować, a nie na odwrót.

@MostlyRenegade ależ klient dostaje taki produkt jaki chce jaki został wyspecyfikowany ale potem okazuje się że jednak nie taki chce a to już jest CR

Nie mówimy o błędach. Błąd to błąd się naprawia i tyle. Natomiast z tego co widzę ty opisujesz fatalne zarzadzanie a to już inna para kaloszy

@kodyak ale to dalej jest bezsensowne, bo musisz robić jeszcze raz coś, co już zrobiłeś. Niezależnie od przyczyn.

A jeśli ktoś jest szeregowym programistą, to raczej rzadko kiedy ma wpływ na zarządzanie, na ustalenia z klientem i na to, czy dostanie dodatkową kasę za wykonanie nikomu niepotrzebnej roboty. On dostaje polecenie "weź zrób".

@MostlyRenegade no i co z tego że robisz jeszce raz. Faktura to faktura pieniądze idą a to że klient jest glupi to już nie nasza wina. Programistom się wydaje że robią coś co musi się skonczyc i co dalej? Będzie robić to samo gdzie indziej i tak w kółko. Każda praca jest w takim razie bezsensu

@kodyak to z tego, że nie ma faktury. Dostajesz polecenie naprawienia cudzych błędów, jesteś poganiany terminami i nie masz za to żadnej dodatkowej gratyfikacji.

O, coś jak np. tu: https://www.hejto.pl/wpis/jest-taki-moment-w-robocie-kiedy-wszystkie-klamstwa-wychodza-na-jaw-i-ja-juz-sie

Jedyna opcja to rzucić papierami, ale bez gwarancji, że w nowym miejscu będzie lepiej.

@MostlyRenegade no widzisz i to już jest wkwestia zarządcza że ktoś daje sobie wejść na glowe bez spisania konkretnych wymagan.

Jeszcze raz. Błędy to nie jest spisanie czegoś nowego to poprawka tego co jest zapisane w specyfikacji i nie działa tak jak zapisane w specyfikacji a to że ktoś myślał że to oznacza co innego niż jest zapisane to kwestia zarządzania wymaganiami.

Ten podpięty przypadek to wręcz wzorowo pokazanie jak ktoś spierdolil zarządzanie projektem. Żeby uzależnić wszystko od jednej osoby i się tym nie interesować to już trzeba być debilem do kwadratu

@Dziki. tak, to są treści subiektywne, pisane zgodnie z moim subiektywnym doświadczeniem i moimi subiektywnymi opiniami. Podejrzewam, że 99% tez może być obalone bardzo szybko, nie tylko związanych z moimi treściami. To normalne, na tym polega wszechświat, że mamy różne doświadczenia i różne "podejścia" do tego. W IT jest tak samo, wiele kwestii zamyka się na "to zależy". Kluczem do dowodzenia tez są odpowiednie założenia, to pozwala na zawężenie, ale też zsubiektywizowanie problemu.

@TheCommitLine 

To normalne, na tym polega wszechświat, że mamy różne doświadczenia i różne "podejścia" do tego.

Bardzo ładna hiperbola. Niemniej, widzę, że niezbyt dotarło to co starałem się przekazać. Aczkolwiek dziękuję za odpowiedź