W jaki sposób biurokracja biurowa wpływa na jakość kodu [zamknięte]

Interesują mnie historie, w których biurokracja biurowa miała bezpośredni wpływ na ostateczny wynik jakości kodu .

Na przykład przyjaciel powiedział mi właśnie, że w jego poprzednim miejscu pracy system kontroli wersji był tak nieporęczny, że programiści nie mogli tworzyć nowych „modułów” (katalogów głównych w drzewie źródłowym) bez pytania o pozwolenie od bogów VCS. W rezultacie programiści nie chcieli przejść przez dodatkowy biurokratyczny krok i zamiast odpowiednio komponować swoje usługi, ostatecznie umieścili niepowiązaną funkcjonalność na istniejących modułach, nawet jeśli funkcjonalność była tylko zdalnie związana z bieżącą definicją modułu lub nazwą modułu było w przeszłości. (nie wspominając o zmianie nazwy modułu ...)

Interesują mnie podobne historie o biurach, działaniach operacyjnych lub innych formach biurokracji, które ostatecznie mogą nieumyślnie wpłynąć na jakość oprogramowania

Interesują mnie historie, w których biurokracja biurowa miała bezpośredni wpływ na ostateczny wynik jakości kodu.

Nie sądzę, aby biurokracja miała tak duży wpływ na jakość kodu, jak dynamika osobista i polityka biurowa. Biurokracja ma związek z procesem. Gdy istniejący proces zostanie wykonany nieprawidłowo (lub wykorzystany negatywnie ... patrz dalej poniżej), może potencjalnie negatywnie wpłynąć na możliwość dostarczenia lub zareagować na nagłe zmiany. Brak procesu będzie jednak miał pewien i znaczący wpływ na jakość kodu. Mówiąc dokładniej, proces, który nie rządzi jakością kodu (interpretowany również jako brak procesu jakości kodu) wpływa na jakość kodu.

Oznacza to, że nie sama biurokracja, ale specyficzne dziury związane z kontrolą jakości w biurokracji wpływają na jakość kodu, gdy jest wykorzystywana (przypadkowo lub nieuprzejmie).

Jednak dynamika osobista i polityka biurowa są znacznie bardziej odpowiedzialne za zły kod. Dynamika osobista polega przede wszystkim na braku etyki zawodowej. Naprawdę nie kupuję argumentu, że ludzie piszą zły kod, ponieważ nie wiedzą lepiej lub nie zostali odpowiednio przeszkoleni . Widziałem ludzi bez stopni związanych z CS, piszących porządny kod. Jest to stan umysłu i osobista kwestia bycia zorganizowanym i skrupulatnym.

Polityka biurowa odgrywa jeszcze bardziej przerażającą rolę. Szefowie, którzy popychają nie myśl, po prostu koduj mantrę (chociaż są chwile, kiedy musimy po prostu kodować, wysyłać i czyścić ciała później); programiści, którzy nalegają na dostarczenie tego, co według nich jest idealnym kodem, nawet jeśli wyciągnięcie czegoś z drzwi jest teraz najważniejsze; recenzenci kodu, którzy są ** dziurami; wojny kabinowe i tym podobne. Te rzeczy zaostrzają problematyczną dynamikę osobistą. Połączenie obu tych czynników przenika przez wszelkie pęknięcia w procesie (biurokracja) lub ich brak, powodując awarię w zapewnianiu jakości kodu.

Dziurę w biurokracji można rozwiązać, jeśli istnieje kultura przeglądów pośmiertnych i ciągłego doskonalenia. Jednak negatywna dynamika osobista i destrukcyjna polityka biurowa zapobiegają takim korektom w procesie, utrwalając w ten sposób istniejące problemy (w tym związane z jakością kodu).

Sama biurokracja rzadko jest sprawcą złej jakości kodu. Powiedziałbym, że negatywnie na dynamikę osobistą i politykę biurową negatywnie wpływa zarówno na jakość kodu, jak i na biurokrację.

Przestałem pracować nad niektórymi konkretnymi modułami w Projekcie, ponieważ recenzentem kodu był Smart A $$

W ramach ostatniego projektu wysokiej jakości ludzie mieli wiele wymagań dotyczących formalnych testów jednostkowych (identyfikowalność, zasady kodowania, formalne przeglądy, ...). Kodery nie piszą już testów jednostkowych, tylko debugują swój kod. Jest to to samo zadanie, którego nazwa została właśnie zmieniona, prowadzi do tych samych wyników technicznych, ale bez problemów administracyjnych.