Wiadomo, jak jest z bugami. Często są to wpadki i przeoczenia, ale istnieje też tzw. "buggy by design", czyli bug jest po prostu nieuchronną konsekwencją złego designu.
Zauważyłem, że podobnie jest z metodyką pracy. Ona może się potykać, ale czasami pomysł na model pracy jest już sam w sobie głęboko toksyczny.
Np. pracowałem w firmie, w której przy zakładaniu zadań trzeba było oszacować czas wykonania (dajmy na to, 60h). A żeby zacząć, musiałeś wystąpić o akceptację głównego programisty, który z zasady lubił marudzić i się o te estymaty targować.
Za to czas na obsługę zgłoszeń od klientów (ticketów) nie wymagał niczyjej akceptacji, i w praktyce można było z niego korzystać bez ograniczeń. Oczywiście niby bardzo mądrze, bo klient nasz pan i jego problemy są naszym priorytetem.
Połączenie jednego z drugim tworzyło mieszankę zabójczą, bo łatwo sobie wyobrazić, do czego ten system prowadził. Opłacało się wypuszczać wadliwy soft, oszczędzając na testach, a bugi leczyć na produkcji. Było mi niebywale głupio, ale z uczciwości serca sam wprost radziłem klientom, żeby nie dawali z siebie robić świnek morskich i unikali jak ognia wszelkich wersji kończących się na ".0". I aktualizacje robili dopiero po wyjściu kilku łatek.
Mieliście coś takiego, że firma w zasadzie sama, przez swą głupotę, popycha programistów do zachowywania się nieprofesjonalnie?