Jestem stosunkowo nowym programistą, świeżo po studiach. Podczas studiów i późniejszych poszukiwań pracy zdałem sobie sprawę, że brakuje wielu „nowoczesnych” metodologii tworzenia oprogramowania, których brakuje w moim wykształceniu: testowanie jednostkowe, rejestrowanie, normalizacja baz danych, zwinne opracowywanie (w porównaniu z ogólnymi koncepcjami zwinnymi), styl kodowania przewodniki, refaktoryzacja, recenzje kodu, brak standardowych metod dokumentacji (a nawet wymagań) itp.

Ogólnie nie widziałem, że to problem. Spodziewałem się, że moja pierwsza praca obejmie wszystkie te pomysły i nauczy mnie ich w pracy. Potem dostałem swoją pierwszą pracę (tworzenie stron internetowych z pełnym stosem) w dużej korporacji i zdałem sobie sprawę, że nie robimy żadnej z tych rzeczy. W rzeczywistości ja, najmniej doświadczony w zespole, jestem tym, który przewodzi próbom przyspieszenia mojego zespołu dzięki „nowoczesnym” technikom programowania - ponieważ martwię się, że nie zrobienie tego jest zawodowym samobójstwem na drodze.

Najpierw zacząłem od oprogramowania do rejestrowania (log4J), ale potem szybko przeszedłem do pisania własnego poradnika stylów, a potem porzuciłem go w poradniku stylu Google - i wtedy zdałem sobie sprawę, że nasze oprogramowanie internetowe Java używało ręcznie napisanych kontrolerów, więc zdecydowałem się na nasze przyjęcie wiosny - ale potem zdałem sobie sprawę, że nie mieliśmy żadnych testów jednostkowych, ale już uczyłem się wiosny ... i jak widać, staje się ona zbyt przytłaczająca, szczególnie w połączeniu z normalną pracą programistyczną. Co więcej, trudno mi stać się wystarczająco „ekspertem” w tych metodologiach, aby uczyć kogokolwiek innego bez poświęcania zbyt wiele czasu jednemu z nich, a tym bardziej wszystkim.

Ze wszystkich tych technik, które uważam za „oczekiwane” w dzisiejszym świecie tworzenia oprogramowania, jak zintegrować je z zespołem jako nowy gracz, nie przytłaczając ani siebie, ani zespołu?

Jak mogę wpłynąć na mój zespół, aby stał się bardziej zwinny? jest powiązany, ale ja nie Agile deweloper jak Pytający tutaj, a ja patrząc na znacznie szerszy niż zbiór metodologii Agile.

Wydaje mi się, że stawiasz wózek przed koniem.

Jaki jest główny problem, przed którym stoi Twój zespół i jakie technologie pomogłyby go naprawić?

Na przykład, jeśli jest wiele błędów, szczególnie błędów typu regresja, testowanie jednostkowe może być punktem wyjścia. Jeśli Twojemu zespołowi brakuje czasu, być może ramy mogą pomóc (średnio- i długoterminowe). Jeśli ludzie mają trudności z czytaniem sobie nawzajem kodu, stylizacja może być przydatna.

Pamiętaj, że celem firmy, w której pracujesz, jest zarabianie pieniędzy, a nie tworzenie kodu.

Jawa? Nowoczesny?! Nie udało ci się przy pierwszej przeszkodzie. Jeśli chcesz być naprawdę nowoczesny i unikać „profesjonalnego samobójstwa”, musisz pisać kod Rust. Oczywiście, w przyszłym tygodniu wszystko się zmieni i będziesz musiał nauczyć się czegoś nowego, aby nadążyć!

Albo, można przyjąć, że żadna ilość modne technologii lub metod lub ramami lub jakakolwiek inna du jour zmieni to faktu, że chcesz zbudować wysokiej jakości produktów, które działają. Nie ma znaczenia, czy nie użyjesz zwinnego, jeśli z powodzeniem produkujesz właściwe wyjście. Oczywiście, jeśli nie jesteś, możesz chcieć to zmienić, ale szanse na to, że żadna konkretna praktyka nie rozwiąże problemów. Pozostaną ludzkimi problemami, które można rozwiązać na wiele różnych sposobów.

Jeśli chodzi o profesjonalne samobójstwo, jeśli wiesz, co robisz i jesteś elastyczny, nie potrzebujesz żadnej z wymienionych przez ciebie rzeczy. Ludzie będą wymyślać nowe sposoby wykonywania starej pracy i zawsze będziesz nadrabiał zaległości. Lub możesz po prostu użyć dowolnych technik, z których korzysta Twoja obecna firma. Zmieniając firmę, po prostu uczysz się i używasz technik, których używają.

Zbyt wiele dzieci odkłada słuchawki na wszystkie nowe narzędzia, których mogłyby użyć, zapominając, że narzędzia te są bezwartościowe w rękach nowicjusza. Najpierw naucz się praktyki, gdy będziesz doświadczonym programistą, możesz zacząć „naprawiać” praktyki programistyczne za pomocą „fajnych nowych rzeczy”, ale do tego czasu masz nadzieję, że zdasz sobie sprawę, że nie są one tak ważne, jak myślisz obecnie, i do użycia tylko wtedy, gdy są naprawdę potrzebne.

Wiele firm utknęło w ten sposób; możesz być nawet zaskoczony, gdy zauważysz, że niektórzy z twoich kolegów programistów są samoukami i zostali programistami bez formalnego doświadczenia. Ci programiści są często lepsi w swojej pracy, ponieważ to oni będą zmuszeni do uczenia się nowych umiejętności i osiągania sukcesów, zamiast po prostu wykonywać tę pracę. Niestety może to również oznaczać, że chociaż są znakomici w programowaniu, mogą nie być świadomi korzyści płynących z tych praktyk. Faktem jest, że są to najlepsze praktyki, a nie powszechne praktyki. Najlepiej je wykorzystać, ale nie są one na wszystkich wymagań, aby odnieść sukces, są one po prostu narzędzia, które pomogą uczynić sukces łatwiejsze.

Masz absolutną rację, próba wdrożenia wszystkiego naraz będzie przytłaczająca. Prawdopodobnie spalisz się (a może i twój zespół) próbując to zrobić, co zdemotywuje przyszłe naciski na przyjęcie nowych metod / technologii. Najlepszą rzeczą w takiej sytuacji jest wybranie jednejrzecz (logowanie jest prawdopodobnie dobrym początkiem, ponieważ prawdopodobnie masz trudną drogę do znalezienia błędów bez logowania, a na pewno będą błędy) i porozmawiaj o tym z zespołem. Nie musisz tego samodzielnie wdrażać; znacznie lepiej porozmawiasz o zaletach i wadach zespołu (i swojego szefa, który absolutnie MUSI być na pokładzie czegoś takiego) i wymyślisz plan jego wdrożenia. Będzie to musiało być jak najbardziej bezbolesne (pamiętaj, mówisz ludziom, że oprócz tego, co już robią , muszą teraz napisać dodatkowy kod).

I pozwól, że powiem jeszcze raz, upewnij się, że twój szef się kupuje . To jest kluczowe; prawdopodobnie zauważysz, że szybkość poprawek / wydań spowalnia, gdy wdrażasz nowe rzeczy. Chodzi o to, że płacisz z góry, aby uratować linię; MUSZĄ to zrozumieć i być po twojej stronie. Jeśli nie weźmiesz ich na pokład, w najlepszym wypadku stoczysz przegraną bitwę, aw najgorszym przypadku mogą oni uznać cię za aktywnie sabotującego zespół (zapytaj mnie, skąd to wiem).

Gdy przyniesiesz te przedmioty do stołu, przedyskutuj je z zespołem, zaplanuj, jak je wdrożyć, i wykonaj kolejne, trzecie, ósme itd. Będzie łatwiejsze. Mało tego, zespół i twój szef mogą zyskać szacunek dla ciebie, ponieważ Twoje sugestie są wdrażane i uznawane za wartość dodaną. Wspaniały! Tylko upewnij się, że zachowujesz elastyczność: naciskasz tutaj na bezwładność, a zmiana nie jest łatwa. bądź przygotowany, by powoli robić małezmiany i upewnij się, że możesz śledzić postęp i uzyskaną wartość. Jeśli wdrożysz logowanie do nowego procesu i pomoże to zaoszczędzić godziny na znalezieniu błędu w ciągu trzech tygodni, zrób z tego wielką sprawę! Upewnij się, że wszyscy wiedzą, że firma właśnie zaoszczędziła XXX USD, robiąc to, co należy. Z drugiej strony, jeśli dostaniesz odpowiedź zwrotną lub masz napięty termin, nie próbuj wymuszać problemu. Pozwól nowej zmianie przesunąć się na chwilę i zawróć. Nigdy nie wygrasz, próbując zmusić zespół do zrobienia czegoś, czego nie chce robić, i możesz być pewien, że pierwszą rzeczą, którą zasugerują porzuceniu, jest nowa „dodatkowa” praca (np. Zapisywanie dziennika lub śledzenie poradnik stylów zamiast po prostu „uruchomić”).

Mam nadzieję, że nie przedstawiliście problemów współpracownikom, tak jak nam to zrobili w swoim poście. TO byłoby profesjonalne samobójstwo.

Pierwszą kwestią jest to, że próbujesz uczyć technologii i metod, z którymi nawet nie masz doświadczenia, grupie programistów, które być może są trochę przestarzałe, ale wykonują zadanie. Możliwości tego odpalenia są nieograniczone i zapewne przyniosą wiele radości współpracownikom. Interesujące i godne podziwu jest to, że chcesz poprawić siebie i swój dział, ale unikaj używania terminów takich jak „spearheading”. Z poważaniem, nie używaj tego słowa.

Jako dodatkowy problem powyższego sprawdź, czy wykonujesz jakąś pracę . Od wielu lat pracuję jako samotny, samouczący się programista i wiem, jak łatwo jest odłożyć na bok rzeczywistą pracę w celu eksploracji obiecujących ram, technologii i tym podobnych. Upewnij się, że Twoje wyniki mieszczą się w oczekiwanych parametrach (nie, nikomu nie zależy na tym, że poświęcisz 20 godzin na badanie wiosny, jeśli raport, o który poprosili cię, nie został wykonany).

Z powyższego, unikaj bycia nauczycielem (chyba że jest to związane z dziedziną / technologią, w której faktycznie masz wystarczająco dużo doświadczenia). Bardziej neutralna prezentacja wskazywałaby na zalety, powiedzmy, zautomatyzowanego testowania i pozwoliłaby kierownictwu wybrać, kogo chcą zbadać zalety i wady tych praktyk.

Teraz, aby zaprezentować te „najlepsze praktyki”, istnieją dwa sposoby wyjaśnienia ich zespołowi:

• Ponieważ mówię, że są to najlepsze praktyki i to wystarczy.
• Ponieważ są przydatne i pomagają rozwiązać problem.

Używając pierwszego argumentu, chyba że jesteś szefem lub bardzo wysokim członkiem zespołu, jest mało prawdopodobne, aby zwrócili na ciebie uwagę. I „Czytam książkę Knutha, która tak mówi” lub „faceci z SE twierdzą, że” też nie wywrą wrażenia („ci faceci tutaj nie pracują, więc tak naprawdę nie wiedzą, co jest dobre dla tego sklepu IT” „). Mają swoje metody, procedury, procedury i „mniej więcej” działają, więc po co podejmować wysiłek i ryzykować zmianę?

Drugie podejście do pracy musi uświadomić sobie, że istnieje problem . Więc:

• nie idź pchać dzień i noc dla automatycznych testów. Poczekaj, aż aktualizacja zepsuje niektóre funkcje, a zespół będzie musiał pracować w nadgodzinach, aby to naprawić, a następnie zaproponuje zbudowanie automatycznego systemu testowego.
• nie pytaj o recenzje kodu. Poczekaj, aż Joe będzie na dłuższym urlopie i trzeba będzie zmienić ten moduł, o którym wie tylko Joe, i wskaż swojemu szefowi, ile czasu zostało stracone, próbując zrozumieć kod Joe.

Oczywiście zmiany będą powolne i postępujące (bardziej w dużej korporacji). Jeśli za pięć lat wprowadzisz przegląd kodu i automatyczne testowanie, powinieneś pogratulować dobrze wykonanej pracy. Ale, chyba że nastąpi całkowite przepisanie z przyczyn zewnętrznych, zapomnij o jakiejkolwiek fantazji, że zamieniają one rdzeń IS na powiedzmy Spring ( Joel wyjaśnił to o wiele lepiej niż kiedykolwiek, nawet zanim się urodziłeś ¹ ); w tym czasie można było co najwyżej umieścić Spring na liście obsługiwanych platform do pisania niekrytycznych systemów.

Witaj w świecie IT dla przedsiębiorstw, chłopcze! :-p

¹ : Ok, może trochę przesadzam, ale nie za dużo.

Powinieneś zacząć od książki Efektywnie działający z kodem Legacy autorstwa Michaela Feathersa. Ze wstępu do książki: „Chodzi o przyjęcie splątanego, nieprzejrzystego, zwiniętego systemu i powoli, stopniowo, kawałek po kawałku, krok po kroku, przekształcając go w prosty, ładnie skonstruowany, dobrze zaprojektowany system”. Zaczyna głównie od automatycznego testowania, abyś mógł bezpiecznie refaktoryzować (będziesz wiedział, jeśli coś zepsujesz), a on zawiera wiele strategii wprowadzania trudnego kodu do automatycznego testowania. Jest to przydatne w przypadku każdego projektu, który jest jeszcze w fazie rozwoju. Po ustaleniu podstawowego porządku możesz zobaczyć, z jakich innych nowoczesnych technologii Twój projekt może skorzystać - ale nie zakładaj, że potrzebujesz ich wszystkich.

Jeśli chcesz nauczyć się nowego frameworka (lub czegoś takiego) z powodów zawodowych, a nie dlatego, że twój obecny projekt go naprawdę potrzebuje, powinieneś użyć go w jakimś osobistym projekcie (w swoim czasie).

Kontrola źródła.

Nie wspomniałeś o tym, mam nadzieję, że jest już na miejscu, ale jeśli nie, zacznij od tego.

Kontrola źródła ma największą zaletę, z wyjątkiem rzadkich okoliczności patologicznie potrzebujących czegoś innego.

I możesz zacząć sam, jeśli początkowo nikt nie kupuje.

Bezpośrednia odpowiedź

Inne odpowiedzi stanowią dobre „meta-punkty” na temat przyjmowania lepszych praktyk, ale tylko po to, aby dać ci bezpośrednio istotne wskazówki, oto przybliżone uporządkowanie najlepszych praktyk, które sugerowałbym Twojemu zespołowi (lub dowolnemu zespołowi) przyjęcie (po pierwsze):

1. Kontrola źródła
2. Śledzenie problemów (zarządzanie projektami i zadaniami)
3. Zautomatyzowane kompilacje ¹
4. Zautomatyzowane wdrożenia

^{1 _{Bardzo pokrewną praktyką jest automatyzacja, a przynajmniej dokumentowanie , konfigurowanie środowiska kompilacji i rozwoju każdej aplikacji lub projektu oprogramowania, który tworzysz lub utrzymujesz. Jest to o wiele mniej przydatne, ponieważ (miejmy nadzieję) robisz to rzadko lub rzadko.}}

Wszystko inne

Wspominasz o kilku innych dobrych praktykach - „testowaniu jednostkowym, logowaniu, normalizacji bazy danych,… refaktoryzacji,… dokumentacji” - ale są to wszystkie praktyki, które można i należy stosować stopniowo i stopniowo. Żadne z nich nie musi być adoptowane naraz i prawdopodobnie lepiej w ogóle je adoptujesz, adoptując je ostrożnie i uważnie.

Cztery wymienione powyżej praktyki sprawią, że przyjęcie i eksperymentowanie z nowymi praktykami będzie tak proste, jak to możliwe. Na przykład testy jednostkowe można włączyć do zautomatyzowanych kompilacji, a dokumentację można opublikować jako część zautomatyzowanych wdrożeń.

Niektóre z innych praktyk, o których wspominasz - „zwinne programowanie,… przewodniki po stylach kodowania,… przeglądy kodu,… znormalizowane metody dokumentacji” i frameworki (np. Spring) - są naprawdę opcjonalne lub mają wątpliwą wartość. Dotyczy to wielu (większości?) Możliwych praktyk, które odkryjesz lub napotkasz.

Zwinne programowanie nie jest oczywiście lepsze niż jakakolwiek inna stosowana metodologia. I wiele osób (w tym ja) miało z tym okropne doświadczenia. Ale wielu ludzi też to lubi (lub uwielbia). Spróbuj!

Przewodniki stylu kodowania mogą być pomocne, szczególnie w przypadku dużych projektów lub w dużych zespołach, ale egzekwowanie tych wytycznych jest również bardzo pracochłonne i może to nie być najlepsze wykorzystanie czasu tego, kto to robi.

Bardzo pomocne mogą być również recenzje kodu - czy poprosiłeś współpracowników o sprawdzenie kodu? Pamiętaj, że nie potrzebujesz formalnego procesu wdrażania dobrych praktyk!

Dokumentacja jest świetna - czy w ogóle ją masz? Jeśli tak, to dobrze dla ciebie! Czy napotykasz wiele dodatkowej pracy, której można by zapobiec dzięki (bardziej) „znormalizowanej” dokumentacji? Jeśli tak, to prawdopodobnie warto to zrobić. Powiedzmy jednak, że jeśli twoje oprogramowanie jest używane przez niewielką grupę osób, możesz nie potrzebować żadnej dokumentacji. (Lub możesz bezpośrednio dołączyć dokumentację do swojego oprogramowania. To zawsze moja preferencja.)

Ramy są ... (bardzo ostrym) obosiecznym mieczem. Ładnie zamknięte i dobrze utrzymane rozwiązanie dla nie-podstawowej funkcji oprogramowania jest świetne ... dopóki tak nie jest. Nie jestem pewien, czym dokładnie są „ręcznie napisane kontrolery frontowe”, ale nie ma oczywistego wyjaśnienia, dlaczego są gorsze od kodu wykorzystującego Spring. Czy zastanawiałeś się nad zawarciem wspólnej logiki we wszystkich tych kontrolerach we własnej strukturze wewnętrznej? Przyjęcie Spring i przepisanie całego istniejącego kodu może być ogromnym projektem refaktoryzacji (lub, co bardziej prawdopodobne, przepisaniem), i może nie być najlepszą zmianą, jaką możesz wprowadzić w kodzie . Oczywiście nie powinieneś pisać całego używanego oprogramowania - frameworki (i biblioteki) są świetne!Ale może nie musisz używać Spring (lub alternatywy) do pisania świetnych (lub dobrych) aplikacji internetowych.

Rozejrzyj się wokół zespołu, którego jesteś częścią. Czy widzisz jakieś dowody na to, że rozwój oparty na testach lub normalizacja baz danych poprawi jakość pisanego oprogramowania lub zwiększy produktywność ludzi?

Czy próbowałeś porozmawiać o tym z jednym z kierowników ds. Rozwoju lub kierownikiem ds. Rozwoju? Naprawdę nieformalny czat byłby dobrym początkiem. Co sprawia, że ​​myślisz, że ludzie powyżej ciebie nie mieli takich samych pomysłów, ale nie mogą / nie będą ich wdrażać, ponieważ firma na to nie pozwoli?

Uważam, że dobrym przykładem jest dawanie przykładu. Ludzie są znacznie mniej odporni, jeśli ktoś już wykonał pracę i może im pokazać, jak ją powielić. Wprowadź TDD do projektu, nad którym pracujesz. Poproś o prezentację dla reszty zespołu, a nawet kilku innych i pokaż im, co zrobiłeś. To, co @DrewJordan powiedział o uzyskaniu wpisu od szefa, jest ważniejsze, niż się zapewne zdajesz.

Znajdź wadę. Napraw błąd. Pokaż poprawkę.

Najpierw weźmy normalizację *. I rzeczywiście, sugerowałbym, abyś wziął to najpierw, ponieważ brak normalizacji może skutkować faktycznymi błędnymi danymi, które inaczej nie istniałyby, podczas gdy pozostałe to przypadki, w których najlepsza praktyka mogłaby pomóc, ale trudniej powiedzieć „Bug” Przyczyną było nieprzestrzeganie zasady X ”. Jeśli masz bazę danych, która nie jest znormalizowana, masz miejsce, w którym dane mogą być niespójne.

To dobry zakład, że będziesz w stanie znaleźć rzeczywisty przypadek niespójnych danych. Znalazłeś teraz dwie rzeczy:

1. Błąd w Twoich danych.

2. Błąd w schematach bazy danych.

Właściwie najpierw wiedziałeś o drugim błędzie, ale pierwszy jest łatwiejszy do wykazania, a także coś, co powoduje prawdziwy problem, a nie coś, co teoretycznie mogłoby.

Niestety jedną z prawdziwych przyczyn oporu wobec normalizacji zdenormalizowanej bazy danych jest to, że pytanie, co zrobić z takimi błędnymi danymi, nie zawsze jest łatwe, ale znajdziesz prawdziwy błąd.

(Pamiętaj jednak, że istnieją powody, dla których czasami celowo można zdenormalizować niektóre dane. Nie myl świadomego łamania reguły z nieznajomością reguły; jeśli znormalizujesz tabelę celowo zdormalizowaną pod kątem szybkości wyszukiwania, wygrałeś nie zdobywaj żadnych pochwał. Nawet tutaj denormalizacja bycia obarczonym jest czymś, co powinno być zrobione proceduralnie, więc jeśli zdormalizowana tabela nie jest tworzona automatycznie na podstawie zawartości znormalizowanych tabel, nadal jest wiele do zrobienia).

Jeśli chodzi o resztę, przedstaw je, gdy pomagają w perspektywie krótkoterminowej, aby później je wykorzystać w perspektywie długoterminowej. Np. Jeśli otrzymasz mały fragment kodu do napisania, napisz dla niego test jednostkowy. Co więcej, jeśli otrzymasz błąd do naprawienia, napisz test jednostkowy, który nie powiedzie się z powodu błędu, a następnie, gdy naprawisz błąd, wspomnij o tym, że przechodzi on po zamknięciu błędów (lub wyślij e-mail z informacją, że został naprawiony , lub cokolwiek).

* Nawiasem mówiąc, niezbyt nowoczesny. Powodem, dla którego nazywa się to normalizacją, a nie normalizacją lub czymś innym, jest to, że w tamtym czasie był to aktualny żart polegający na przyklejeniu do końca rzeczy, aby wyśmiewać nazwę polityki wietnamskiej Richarda Nixona .

Mam zamiar pójść na całość i powiedzieć: znajdź nową pracę po tym, jak spędzę trochę czasu w tym miejscu, aby trochę zbudować swoje CV. Celuj przez około rok. Chociaż wiele rzeczy to „modne słowa”, problemy takie jak całkowity brak testów jednostkowych są trudne do rozwiązania dla pojedynczego programisty, i są szanse, że jeśli programiści tam pracujący nie będą chcieli testować, nigdy nie dostaniesz zakupu, a może nawet zagrozić twojej pozycji w firmie, sprawiając, że ludzie myślą o tobie jak o twardej krwi. Musisz być w miejscu, w którym możesz uzyskać mentoring, a nie próbować popychać kulturę do podstawowych kompetencji.

Było wiele propozycji ulepszenia paradygmatu programowania . Najgorętsze modne słowa wydają się teraz zwinne i zorientowane obiektowo. Albo czy oni? Oba zniknęły znacznie w porównaniu z tym, czym były zaledwie pięć lat temu.

Możesz być całkiem pewny, że każda zastosowana metodologia stara się osiągnąć ten sam rezultat końcowy: pomóc inżynierom w ekonomicznym wytwarzaniu produktu końcowego, który jest wystarczająco dobry.

Jest jeden paradygmat, który został kontrowersyjnie wprowadzony w 1960 roku: Programowanie strukturalne : używać tylko „wysoki poziom” konstruuje jak while, for, repeat, if/ then/ else, switch/ caseoświadczenia zamiast silnie stosowanego gotooświadczenia, które zostały zaakceptowane przez domyślnie. Nadal trwają debaty na temat tego, czy gotoma jakiekolwiek uzasadnione zastosowanie.

Przyjmuję do wiadomości, że minimalizowanie użycia gotojest dobrą rzeczą, ale podobnie jak wszystkie dobre rzeczy, można posunąć się za daleko.

Wspominasz agilemetodologie jako coś pozytywnego. Przez około sześć miesięcy pracowałem w jednym zespole programistów, który celowo przestrzegał przepisanego schematu zwinnego. Odkryłem, że jest to tak samo jak światłe metodologie zarządzania projektami sprzed dziesięcioleci, tyle że wszystko zmienia nazwę. Być może poprzez ponowne pakowanie i odsprzedaż pomysłów na komunikację z kimś zarabia na życie, a firmy mogą czuć się dobrze, widząc nowe ubrania cesarza .

Najcenniejszą lekcją Agile, znaną dawno temu, jest to, że elastyczność w znalezieniu lepszej ścieżki do gotowego produktu jest dobrą rzeczą, a możliwość znalezienia tej ścieżki może pochodzić od każdego - nie tylko od wyższej kadry kierowniczej.

Z pisma przywódcy anty-goto Edsgera Dijkstry:

Sztuka programowania to sztuka organizowania złożoności, opanowywania mnóstwa i unikania chaotycznego chaosu tak skutecznie, jak to możliwe.

—Dijkstra, w: Dahl, Dijkstra i Hoare 1972, str. 6. (patrz strona 6 tutaj .)