Cargo Cult Software Engineering

na morzach południowych panuje kult ludzi cargo. Podczas wojny widzieli samoloty z mnóstwem dobrych materiałów i chcą, aby to samo stało się teraz. Przygotowali więc takie rzeczy jak pasy startowe, rozpalili ogień po bokach pasów startowych, stworzyli drewnianą chatę dla człowieka, w której siedział, z dwoma drewnianymi kawałkami na głowie na słuchawki i bambusowymi prętami wystającymi jak anteny—on jest kontrolerem-i czekają, aż samoloty wylądują. Wszystko robią dobrze. Forma jest idealna. Wygląda dokładnie tak, jak wcześniej. Ale to nie działa. Samoloty nie lądują. Nazywam to nauką kultu ładunku, ponieważ podążają za wszystkimi pozornymi zasadami i formami badań naukowych, ale brakuje im czegoś istotnego, ponieważ samoloty nie lądują.
-Richard Feynman

uważam, że warto narysować kontrast między dwoma różnymi stylami rozwoju organizacyjnego: “zorientowanym na proces” i “zorientowanym na zaangażowanie”. Rozwój zorientowany na proces osiąga swoją skuteczność poprzez umiejętne planowanie, wykorzystanie starannie zdefiniowanych procesów, efektywne wykorzystanie dostępnego czasu i umiejętne zastosowanie najlepszych praktyk inżynierii oprogramowania. Ten styl rozwoju odnosi sukces, ponieważ organizacja, która go używa, stale się doskonali. Nawet jeśli jego wczesne próby są nieskuteczne, stała uwaga na proces oznacza, że każda kolejna próba będzie działać lepiej niż poprzednia próba.

rozwój zorientowany na zaangażowanie nosi kilka nazw, w tym “rozwój zorientowany na bohatera” i “indywidualne wzmocnienie.”Organizacje zorientowane na zaangażowanie charakteryzują się zatrudnianiem najlepszych możliwych osób, proszeniem ich o całkowite zaangażowanie w swoje projekty, zapewnianiem im niemal całkowitej autonomii, motywowaniem w ekstremalnym stopniu, a następnie obserwowaniem, że pracują 60, 80 lub 100 godzin tygodniowo do zakończenia projektu. Rozwój zorientowany na zaangażowanie wynika z jego ogromnej zdolności motywacyjnej-badanie po badaniu wykazało, że indywidualna motywacja jest zdecydowanie największym pojedynczym czynnikiem przyczyniającym się do wydajności. Programiści podejmują dobrowolne, osobiste zobowiązania do projektów, nad którymi pracują, i często dokładają niezwykłych starań, aby ich projekty odniosły sukces.

oszuści Organizacyjni

gdy są dobrze używane, każdy styl programowania może produkować wysokiej jakości oprogramowanie w sposób ekonomiczny i szybki. Ale oba style rozwoju mają patologiczne sobowtóry nie działają tak dobrze, a to może być trudne do odróżnienia od prawdziwych artykułów.

organizacja proces-oszust opiera swoje praktyki na niewolniczym poświęceniu się procesowi dla dobra procesu. Organizacje te patrzą na organizacje zorientowane na procesy, takie jak NASA Software Engineering Laboratory i IBM ‘ s były Federal Systems Division. Zauważają, że organizacje te generują wiele dokumentów i organizują częste spotkania. Wnioskują oni, że jeśli wygenerują równoważną liczbę dokumentów i zorganizują porównywalną liczbę spotkań, odniosą podobny sukces. Jeśli wygenerują więcej dokumentacji i zorganizują więcej spotkań, odniosą jeszcze większy sukces! Ale nie rozumieją, że dokumentacja i spotkania nie są odpowiedzialne za sukces; są to skutki uboczne kilku konkretnych skutecznych procesów. Nazywamy te organizacje biurokratycznymi, ponieważ stawiają formę procesów oprogramowania ponad istotą. Ich niewłaściwe wykorzystanie procesu jest demotywujące, co szkodzi produktywności. I nie są zbyt przyjemne w pracy.

organizacja commitment-imposter skupia się przede wszystkim na motywowaniu ludzi do pracy wielogodzinnej. Organizacje te patrzą na firmy odnoszące sukcesy, takie jak Microsoft; zauważają, że generują bardzo mało dokumentacji; oferują opcje na akcje swoim pracownikom; a potem zażądać od nich nadgodzin. Doszli do wniosku, że jeśli również zminimalizują dokumentację, zaoferują opcje na akcje i będą wymagały rozległych nadgodzin, odniosą sukces. Im mniej dokumentacji i więcej nadgodzin, tym lepiej! Jednak organizacje te nie dostrzegają faktu, że Microsoft i inne udane firmy zorientowane na zaangażowanie nie wymagają nadgodzin. Zatrudniają ludzi, którzy kochają tworzyć oprogramowanie. Łączą tych ludzi z innymi ludźmi, którzy kochają tworzyć oprogramowanie tak samo jak oni. Zapewniają bogate wsparcie organizacyjne i nagrody za tworzenie oprogramowania. A potem ich wypuszczają. Naturalnym rezultatem jest to, że programiści i menedżerowie dobrowolnie decydują się na długie godziny pracy. Organizacje oszustów mylą efekt (długie godziny) z przyczyną (Wysoka motywacja). Nazywamy te organizacje oszustami, ponieważ kładą nacisk na ciężką pracę, a nie na mądrą, i wydają się być chaotyczne i nieskuteczne. Dla nich też nie jest przyjemnie pracować.

Inżynieria oprogramowania Cargo Cult

na pierwszy rzut oka te dwa rodzaje organizacji oszustów wydają się być dokładnymi przeciwieństwami. Jeden jest niesamowicie biurokratyczny, a drugi niesamowicie chaotyczny. Ale jedno kluczowe podobieństwo jest w rzeczywistości ważniejsze niż ich powierzchowne różnice. Żadna z nich nie jest bardzo skuteczna, a powodem jest to, że żadna nie rozumie, co tak naprawdę sprawia, że jej projekty odnoszą sukces lub niepowodzenie. Przechodzą przez ruchy wyglądające jak skuteczne organizacje, które są stylistycznie podobne. Ale bez prawdziwego zrozumienia, dlaczego te praktyki działają, są one w zasadzie po prostu wtykając kawałki bambusa w uszy i mając nadzieję, że ich projekty wylądują bezpiecznie. Wiele z ich projektów kończy się niepowodzeniem, ponieważ są to tylko dwie różne odmiany inżynierii oprogramowania cargo cult, podobne w ich braku zrozumienia tego, co sprawia, że Projekty oprogramowania działają.

Inżynieria oprogramowania Cargo cult jest łatwa do zidentyfikowania. Inżynierowie oprogramowania Cargo Cult uzasadniają swoje praktyki słowami:” zawsze robiliśmy to w ten sposób w przeszłości “lub”nasze standardy firmowe wymagają od nas tego w ten sposób” —nawet jeśli te sposoby nie mają sensu. Odmawiają uznania kompromisów związanych z rozwojem zorientowanym na proces lub zorientowanym na zaangażowanie. Oba mają mocne i słabe strony. Gdy przedstawiamy bardziej skuteczne, nowe praktyki, inżynierowie oprogramowania Cargo Cult wolą pozostać w swoich drewnianych chatach ze znajomymi, wygodnymi i-niekoniecznie-skutecznymi nawykami pracy. “Robienie tego samego raz za razem i oczekiwanie różnych rezultatów jest oznaką szaleństwa”, mówi stare powiedzenie. Jest to również oznaka inżynierii oprogramowania cargo cult.

prawdziwa debata

w tym magazynie i w wielu innych publikacjach spędzamy czas na debacie, czy Proces jest dobry, czy indywidualne wzmocnienie (innymi słowy, rozwój zorientowany na zaangażowanie) może być lepsze. To fałszywa dychotomia. Proces jest dobry,podobnie jak indywidualne upodmiotowienie. Te dwa mogą istnieć obok siebie. Organizacje zorientowane na procesy mogą wymagać ekstremalnego zaangażowania w konkretne projekty. Organizacje zorientowane na zaangażowanie mogą umiejętnie wykorzystywać praktyki inżynierii oprogramowania.

różnica między tymi dwoma podejściami tak naprawdę sprowadza się do różnic stylu i osobowości. Pracowałem nad kilkoma projektami każdego stylu i lubiłem różne rzeczy w każdym stylu. Niektórzy programiści lubią metodycznie pracować na harmonogramie 8 do 5, co jest bardziej powszechne w firmach zorientowanych na procesy. Inni deweloperzy cieszą się skupieniem i ekscytacją, która wiąże się z zaangażowaniem 24×7 w projekt. Projekty zorientowane na zaangażowanie są średnio bardziej ekscytujące, ale projekt zorientowany na proces może być równie ekscytujący, gdy ma dobrze zdefiniowaną i inspirującą misję. Organizacje zorientowane na proces zdegenerują się w swoich patologicznych sobowtórów rzadziej niż organizacje zorientowane na zaangażowanie, ale każdy styl może działać dobrze, jeśli jest umiejętnie zaplanowany i wykonany.

fakt, że zarówno projekty zorientowane na proces, jak i projekty zorientowane na zaangażowanie mają patologicznych sobowtórów, zamazał debatę. Niektóre projekty prowadzone w każdym stylu odnoszą sukcesy, a niektóre nie. Pozwala to adwokatowi procesu wskazywać na sukces procesu i niepowodzenia zaangażowania i twierdzić, że proces jest kluczem do sukcesu. Pozwala to zwolennikowi zaangażowania zrobić to samo.

kwestia, która spadła na uboczu, gdy debatowaliśmy nad procesem a zobowiązaniem, jest tak rażąca, że, jak w przypadku listu Edgara Allena Poe, mogła być po prostu tak oczywista, że ją przeoczyliśmy. Nie powinniśmy debatować nad procesem a zaangażowaniem; powinniśmy debatować nad kompetencją a niekompetencją. Prawdziwa różnica nie polega na tym, który styl jest wybrany, ale na tym, jaką edukację, szkolenie i zrozumienie wnosi do projektu. Zamiast debatować nad procesem a zaangażowaniem, powinniśmy szukać sposobów na podniesienie średniego poziomu kompetencji deweloperów i menedżerów. To zwiększy nasze szanse na sukces niezależnie od tego, jaki styl rozwoju wybierzemy.