Cargo Cult Software Engineering

în mările de Sud există un cult de marfă de oameni. În timpul războiului au văzut avioane cu o mulțime de materiale bune și vor să se întâmple același lucru acum. Așa că au aranjat să facă lucruri ca niște piste, să pună focuri de—a lungul părților laterale ale pistelor, să facă o colibă de lemn în care să stea un om, cu două bucăți de lemn pe cap pentru căști și bare de bambus care ies ca niște antene—el este controlorul-și așteaptă să aterizeze avioanele. Fac totul bine. Forma este perfectă. Arată exact cum arăta înainte. Dar nu merge. Nu aterizează avioane. Așa că eu numesc aceste lucruri știința cultului cargo, pentru că urmează toate preceptele aparente și formele investigației științifice, dar le lipsește ceva esențial, pentru că avioanele nu aterizează.
— Richard Feynman

mi se pare util să desenez un contrast între două stiluri diferite de dezvoltare organizațională: dezvoltarea “orientată spre proces” și “orientată spre angajament”. Dezvoltarea orientată spre proces își atinge eficacitatea prin planificarea abilă, utilizarea proceselor definite cu atenție, utilizarea eficientă a timpului disponibil și aplicarea cu îndemânare a celor mai bune practici de inginerie software. Acest stil de dezvoltare reușește, deoarece organizația care îl folosește se îmbunătățește constant. Chiar dacă încercările sale timpurii sunt ineficiente, o atenție constantă la proces înseamnă că fiecare încercare succesivă va funcționa mai bine decât încercarea anterioară.

dezvoltarea orientată spre angajament poartă mai multe nume, inclusiv “dezvoltare orientată spre erou” și “Împuternicire individuală.”Organizațiile orientate spre angajament se caracterizează prin angajarea celor mai buni oameni posibili, cerându-le angajament total față de proiectele lor, împuternicindu-i cu autonomie aproape completă, motivându-i într-o măsură extremă și apoi văzând că lucrează 60, 80 sau 100 de ore pe săptămână până la finalizarea proiectului. Dezvoltarea orientată spre angajament își derivă potența din capacitatea sa motivațională extraordinară-studiu după studiu a constatat că motivația individuală este de departe cel mai mare contribuitor unic la productivitate. Dezvoltatorii își iau angajamente voluntare și personale față de proiectele la care lucrează și adesea depun eforturi extraordinare pentru ca proiectele lor să reușească.

impostori organizaționali

atunci când sunt utilizați în mod conștient, fie stilul de dezvoltare poate produce software de înaltă calitate economic și rapid. Dar ambele stiluri de dezvoltare au lookalikes patologice care nu funcționează aproape la fel de bine, și care poate fi dificil să se distingă de articole autentice.

organizația proces-impostor își bazează practicile pe o devoțiune servilă față de proces de dragul procesului. Aceste organizații se uită la organizații orientate spre proces, cum ar fi laboratorul de inginerie Software al NASA și fosta divizie a sistemelor Federale IBM. Ei observă că aceste organizații generează o mulțime de documente și organizează întâlniri frecvente. Aceștia concluzionează că, dacă generează un număr echivalent de documente și organizează un număr comparabil de întâlniri, vor avea un succes similar. Dacă generează mai multă documentație și organizează mai multe întâlniri, vor avea și mai mult succes! Dar ei nu înțeleg că documentația și întâlnirile nu sunt responsabile pentru succesul; acestea sunt efectele secundare ale câtorva procese eficiente specifice. Numim aceste organizații birocratice, deoarece pun forma proceselor software deasupra substanței. Utilizarea lor abuzivă a procesului este demotivantă, ceea ce dăunează productivității. Și nu sunt foarte plăcute pentru a lucra.

organizația impostorului angajamentului se concentrează în primul rând pe motivarea oamenilor să lucreze ore lungi. Aceste organizații uita-te la companii de succes, cum ar fi Microsoft; observați că acestea generează foarte puțină documentație; oferă opțiuni de stoc pentru angajații lor; și apoi le cere să lucreze munți de ore suplimentare. Ei concluzionează că, dacă, de asemenea, minimizează documentația, oferă opțiuni pe acțiuni și necesită ore suplimentare extinse, vor avea succes. Cu cât documentația este mai mică și cu atât mai multe ore suplimentare, cu atât mai bine! Dar aceste organizații ratează faptul că Microsoft și alte companii orientate spre angajament de succes nu necesită ore suplimentare. Ei angajează oameni care iubesc să creeze software. Ei Echipa aceste persoane cu alte persoane care iubesc pentru a crea software-ul la fel de mult ca și ei. Acestea oferă sprijin organizațional generos și recompense pentru crearea de software. Și apoi le dau drumul. Rezultatul natural este că dezvoltatorii de software și managerii aleg să lucreze ore lungi în mod voluntar. Organizațiile impostoare confundă efectul (ore lungi) cu cauza (motivație ridicată). Noi numim organizațiile impostoare ateliere pentru că pun accentul pe munca grea, mai degrabă decât pe munca inteligentă, și tind să fie haotice și ineficiente. Ei nu sunt foarte plăcut să lucreze pentru, fie.

Cargo Cult Software Engineering

la prima vedere, aceste două tipuri de organizații impostor par a fi opuse exacte. Unul este incredibil de birocratic, iar celălalt este incredibil de haotic. Dar o similitudine cheie este de fapt mai importantă decât diferențele lor superficiale. Niciunul nu este foarte eficient, iar motivul este că niciunul nu înțelege ceea ce face ca proiectele sale să reușească sau să eșueze. Ei trec prin mișcările de a arăta ca organizații eficiente care sunt similare din punct de vedere stilistic. Dar fără nici o înțelegere reală de ce practicile de lucru, ele sunt, în esență, doar lipirea bucăți de bambus în urechile lor și în speranța proiectele lor va ateriza în condiții de siguranță. Multe dintre proiectele lor ajung să se prăbușească, deoarece acestea sunt doar două varietăți diferite de inginerie software de cult de marfă, similare în lipsa lor de înțelegere a ceea ce face ca proiectele software să funcționeze.

Cargo cult Software engineering este ușor de identificat. Inginerii de software Cargo cult își justifică practicile spunând:” Am făcut—o întotdeauna în acest fel în trecut “sau”standardele companiei noastre ne impun să o facem în acest fel” – chiar și atunci când aceste moduri nu au sens. Ei refuză să recunoască compromisurile implicate în dezvoltarea orientată spre proces sau orientată spre angajament. Ambele au puncte forte și puncte slabe. Atunci când li se prezintă practici mai eficiente, noi, inginerii de software cargo cult preferă să rămână în colibele lor de lemn cu obiceiuri de lucru familiare, confortabile și nu neapărat eficiente. “A face același lucru din nou și din nou și a aștepta rezultate diferite este un semn de nebunie”, spune vechea zicală. Este, de asemenea, un semn de inginerie software cargo cult.

dezbaterea reală

în această revistă și în multe alte publicații, ne petrecem timpul dezbatând dacă procesul este bun sau împuternicirea individuală (cu alte cuvinte, dezvoltarea orientată spre angajament) ar putea fi mai bună. Aceasta este o dihotomie falsă. Procesul este bun, la fel și împuternicirea individuală. Cele două pot exista una lângă alta. Organizațiile orientate spre proces pot solicita un angajament extrem pentru proiecte specifice. Organizațiile orientate spre angajament pot folosi cu pricepere practicile de inginerie software.

diferența dintre aceste două abordări se reduce într-adevăr la diferențele de stil și personalitate. Am lucrat la mai multe proiecte de fiecare stil, și-au plăcut lucruri diferite despre fiecare stil. Unii dezvoltatori se bucură să lucreze metodic pe un program de 8 până la 5, ceea ce este mai frecvent în companiile orientate spre proces. Alți dezvoltatori se bucură de concentrarea și entuziasmul care vine cu a face un angajament 24 7 la un proiect. Proiectele orientate spre angajament sunt mai interesante în medie, dar un proiect orientat spre proces poate fi la fel de interesant atunci când are o misiune bine definită și inspirată. Organizațiile orientate spre proces par să degenereze în aspectul lor patalogic mai rar decât organizațiile orientate spre angajament, dar oricare dintre stiluri poate funcționa bine dacă este planificat și executat cu pricepere.

faptul că atât proiectele orientate spre proces, cât și cele orientate spre angajament au asemănări patologice a tulburat dezbaterea. Unele proiecte realizate în fiecare stil reușesc, iar altele nu reușesc. Acest lucru permite unui avocat al procesului să indice succesul procesului și eșecurile angajamentului și să pretindă că procesul este cheia succesului. Permite avocatului angajamentului să facă același lucru.

problema care a căzut pe marginea drumului în timp ce dezbatem procesul vs.angajament este atât de flagrantă încât, la fel ca Scrisoarea furată a lui Edgar Allen Poe, poate că pur și simplu a fost atât de evidentă încât am trecut-o cu vederea. Nu ar trebui să dezbatem procesul vs.angajamentul; ar trebui să dezbatem competența vs. incompetența. Diferența reală nu este ce stil este ales, dar ce Educație, Formare și înțelegere este adus să suporte pe proiect. În loc să dezbatem procesul vs. angajament, ar trebui să căutăm modalități de a ridica nivelul mediu de competență a dezvoltatorului și managerului. Acest lucru ne va îmbunătăți șansele de succes, indiferent de stilul de dezvoltare pe care îl alegem.