5 odważnych posunięć w tworzeniu oprogramowania, które wszyscy uważali za szalone — dopóki nie zadziałały

Tworzenie oprogramowania jest pełne dobrze znanych metodyk—Agile, model kaskadowy, Scrum—a wszystkie są solidnymi wyborami, które pomagają zespołom dostarczać rozwiązania na czas i z mniejszą liczbą niespodzianek.

Ale czasami tak bardzo przyzwyczajamy się do podążania utartymi ścieżkami, że zapominamy, iż prawdziwe przełomy często pojawiają się wtedy, gdy ktoś próbuje czegoś, co na papierze wygląda absurdalnie. To ryzykowne, jasne, ale właśnie tam zazwyczaj kryją się największe sukcesy.

„AI świetnie radzi sobie z wykonywaniem 70% pracy szybciej” — mówi Alex Zajac, SDE & AI w Amazonie i twórca biuletynu Hungry Minds. „Ale te ostatnie 30% jest najtrudniejsze — wdrożenie rozwiązania na produkcję, upewnienie się, że nie generuje halucynacji, oraz skonfigurowanie zabezpieczeń ewaluacyjnych.”

Innymi słowy, odważne tworzenie oprogramowania nie polega wyłącznie na korzystaniu z nowych narzędzi — chodzi o wykonanie trudnej, nieefektownej pracy, dzięki której naprawdę działają.

Większość firm trzyma się utartego schematu, ponieważ jest on postrzegany jako „bezpieczny”. Nikt nie zostanie obwiniony za odejście od standardów, jeśli pomysł nie sprawdzi się w ramach typowego procesu. Jednak według badania McKinsey z 2023 roku firmy, które zachęcają do podejmowania skalkulowanego ryzyka, mają 1,7 raza większe prawdopodobieństwo przewyższenia konkurentów z branży pod względem wskaźników innowacyjności.

Nawet gdy wiemy, że odważne myślenie może się opłacić, zaskakująco rzadko spotyka się środowiska, które naprawdę nagradzają eksperymentowanie. Zbyt mało organizacji wyraźnie zachęca do podejmowania ryzyka w projektach programistycznych.

Wcześni użytkownicy, a czasem wręcz pionierzy, często mogą ustalać zasady, zanim wszyscy inni w ogóle zdadzą sobie sprawę z ich istnienia.

Pomimo całego strachu i wahania istnieją zespoły, które odważnie zaryzykowały i osiągnęły coś genialnego. Oto pięć strategii, które początkowo wydawały się nietypowe — a może nawet zbyt chaotyczne — aby mogły odnieść sukces.

Strategia nr 1: Inżynieria chaosu (Netflix)

„Chaos Monkey” firmy Netflix celowo zakłóca działanie systemów na produkcji, aby testować ich odporność. Brzmi szalenie, prawda? Jednak to podejście pomogło firmie Netflix utrzymać dostępność na poziomie 99,99% podczas skalowania z 7 milionów do ponad 230 milionów subskrybentów.

„Zdaliśmy sobie sprawę, że liczenie na stabilność nie było strategią” — powiedział Kolton Andrus, były inżynier firmy Netflix. „Regularnie wywołując awarie, nasze zespoły przestały obawiać się przestojów i zaczęły domyślnie budować bardziej odporne systemy.”

Kluczowy wniosek był sprzeczny z intuicją: tworzenie kontrolowanych awarii faktycznie zapobiegało katastrofalnym awariom. Testy wstrzykiwania awarii firmy Netflix ujawniły słabe punkty, które pozostałyby ukryte aż do wystąpienia poważnego przestoju.

Praktyczny wniosek: Zacznij od „Dnia gry”, podczas którego zasymulujesz awarie w środowisku nieprodukcyjnym. Wybierz jedną krytyczną usługę i wprowadź proste awarie, takie jak wyłączanie instancji lub zrywanie połączeń sieciowych. Udokumentuj, co przestaje działać, i napraw te podatności, zanim spowodują rzeczywiste problemy.

Strategia nr 2: Ciągłe wdrażanie (Flickr)

W 2009 roku, gdy większość firm wdrażała zmiany raz w miesiącu, prezentacja Flickra „10 wdrożeń dziennie” wprawiła wszystkich w osłupienie. Zespoły obawiały się, że mniejsze i częstsze wydania doprowadzą do chaosu, ale Flickr odkrył coś przeciwnego: częstsze wydania faktycznie znacząco zmniejszały ryzyko.

Matematyka jest prosta, ale potężna: jeśli wdrażasz jednocześnie 5–10 zmian, odizolowanie problemów jest łatwe. Jeśli po miesiącu wdrażasz 500 zmian, powodzenia w znalezieniu igły w tym stogu siana.

Firmy stosujące CD odnotowują o 70% mniej awarii na produkcji i 24 razy szybsze przywracanie działania, gdy rzeczywiście pojawią się problemy — wynika z raportu State of DevOps z 2023 roku. Od tego czasu praktyka ta stała się standardem w firmach technologicznych każdej wielkości.

Praktyczny wniosek: Wprowadź podejście oparte na „oknie wdrożeniowym”, w ramach którego zespoły stopniowo zwiększają częstotliwość wdrożeń. Zacznij od przejścia z wdrożeń comiesięcznych na cotygodniowe, następnie zwiększ częstotliwość do dwóch razy w tygodniu, aż zbudujesz automatyzację i zaufanie potrzebne do wdrażania zmian kilka razy dziennie. Skoncentruj się na stworzeniu solidnego zestawu testów uruchamianego automatycznie przed każdym wdrożeniem.

Strategia nr 3: Model w pełni zdalny (GitLab)

Przed pandemią w pełni zdalna struktura GitLaba wydawała się radykalna. Umożliwiła jednak firmie zatrudnianie najlepszych talentów z całego świata i od pierwszego dnia wymusiła doskonałe praktyki dokumentacyjne.

Publiczny podręcznik GitLaba (liczący obecnie ponad 15 000 stron) stał się ich tajną bronią, eliminując problem „Nie wiedziałem o tym”, który nęka wiele rozproszonych zespołów. To podejście oparte przede wszystkim na dokumentacji oznaczało, że nowi pracownicy mogli szybciej przejść proces wdrożenia, a podejmowanie decyzji stało się bardziej przejrzyste.

„Kiedy nie możesz poprosić kogoś o informacje, zmuszony jesteś wszystko jasno udokumentować”, wyjaśnia Darren Murph, szef zespołu pracy zdalnej w GitLabie. „Tworzy to odporność organizacyjną, którą firmy skoncentrowane na pracy biurowej rzadko osiągają”.

Praktyczny wniosek: Nawet jeśli nie pracujesz w pełni zdalnie, zastosuj praktykę dokumentacji „zdalną przede wszystkim”. Utwórz scentralizowaną bazę wiedzy obejmującą wszystkie ważne decyzje, procesy i wiedzę plemienną. Ustal zasadę, że jeśli coś nie jest udokumentowane, to nie istnieje. Przeglądaj tę dokumentację co kwartał, aby była aktualna.

Strategia nr 4: Rozwój oparty na głównej gałęzi (Etsy)

Etsy zrezygnowało ze złożonych strategii rozgałęziania na rzecz modelu, w którym wszyscy często zatwierdzają zmiany w głównej bazie kodu. To podejście podważyło powszechne przekonanie, że programiści potrzebują odizolowanych gałęzi funkcjonalności, aby skutecznie pracować.

„Odkryliśmy, że długo utrzymywane gałęzie tworzyły fałszywe poczucie bezpieczeństwa”, mówi Daniel Schauenberg, były inżynier Etsy. „W rzeczywistości tylko opóźniały problemy związane z integracją i powodowały większe konflikty, gdy w końcu dochodziło do scalania gałęzi”.

Rozwój oparty na głównej gałęzi pomógł Etsy rozwinąć się z 50 do ponad 2000 programistów, przy jednoczesnym wdrażaniu zmian ponad 50 razy dziennie. To podejście zmusiło zespół do stworzenia lepszych automatycznych testów, ponieważ główna gałąź musiała pozostać czysta, a także wyeliminowało zbyt często spotykane „piekło scalania”, z którym zespoły mierzą się przy korzystaniu z gałęzi funkcjonalności.

Alex zauważył podobny wzorzec, mówiąc o AI i bazach kodu wymagających dużej ilości kontekstu. „Rzeczy, które są naprawdę mocno powiązane z waszymi zastrzeżonymi systemami… będą wymagały wielu ludzi”, powiedział.

W szybko zmieniającym się środowisku zespoły pracujące bezpośrednio w głównej gałęzi muszą dogłębnie rozumieć projekt systemu i kompromisy, ponieważ jest mniej miejsca, by ukryć się za długo utrzymywanymi gałęziami. Nie chodzi tylko o szybsze zatwierdzanie kodu — chodzi o to, by inżynierowie mieli bliższy kontakt z rzeczywistą złożonością.

Praktyczny wniosek: Wprowadź przełączniki funkcji, aby ukrywać pracę będącą w toku, jednocześnie codziennie zatwierdzając zmiany w głównej gałęzi. Zacznij od małego, zaufanego zespołu, aby zbudować pewność co do tego podejścia. Ustal cel zespołowy polegający na zatwierdzaniu zmian w głównej gałęzi co najmniej raz dziennie i z czasem mierz spadek liczby problemów z integracją.

Strategia nr 5: Otwarte źródła domyślnie (Hashicorp)

Hashicorp zbudował firmę wartą miliard dolarów, udostępniając jako otwarte oprogramowanie swoje podstawowe narzędzia infrastrukturalne, takie jak Terraform, Vault i Consul. Wbrew tradycyjnym modelom biznesowym oprogramowania strategia ta umożliwiła szybkie wdrażanie oraz pozyskiwanie wkładu od tysięcy programistów z całego świata.

„Kiedy zaczynaliśmy, ludzie uważali, że zwariowaliśmy, rozdając nasz najlepszy kod”, zauważa Mitchell Hashimoto, współzałożyciel. „Odkryliśmy jednak, że powszechne wykorzystanie tworzy większą wartość, niż tracisz na potencjalnych przychodach z licencji”.

W przypadku indywidualnych programistów wybór odpowiednich narzędzi wspomaganych przez AI może opierać się na podobnej logice. Alex powiedział, że niedawno zdecydował się kupić Cursor Pro, ponieważ „po prostu mnie rozumie albo rozumie styl, w którym pracuję”. Tak jak HashiCorp postawił na zaufanie i dopasowanie do społeczności dzięki otwartemu oprogramowaniu, tak inżynierowie coraz częściej wybierają narzędzia, które intuicyjnie rozumieją ich sposób pracy — nawet jeśli oznacza to wybór mniej popularnej opcji.

Ich narzędzie Terraform zdobyło ponad 100 000 gwiazdek na GitHubie i stało się standardem branżowym — coś takiego w przypadku tradycyjnego podejścia z zamkniętym kodem źródłowym zajęłoby dziesięciolecia. Firma zarabia na funkcjach dla przedsiębiorstw, wsparciu i usługach hostowanych, jednocześnie utrzymując dobrą opinię wśród ogromnej społeczności programistów.

Praktyczny wniosek: Zidentyfikuj komponenty swojego oprogramowania, które mogłyby skorzystać z zaangażowania społeczności. Zacznij od udostępnienia jako oprogramowania open source pomocnej biblioteki lub narzędzia, które nie stanowi Twojej kluczowej własności intelektualnej. Opracuj proces wnoszenia wkładu, który ułatwi osobom z zewnątrz ulepszanie Twojego kodu, i zainwestuj w dobrą dokumentację, aby ułatwić wdrożenie.

Wspólny mianownik

To, co łączy te strategie, to nie tylko odwaga — to skalkulowane ryzyko połączone z krótkimi pętlami informacji zwrotnej. Każdy zespół stworzył mechanizmy umożliwiające szybkie wyciąganie wniosków z błędów i korygowanie kursu.

Alex wspomniał, jak AI zmienia to, co oznacza bycie programistą. „Nie zostaniemy zastąpieni,” mówi, „ale zmienia się zakres odpowiedzialności.”

Niektórzy twierdzą, że programiści coraz bardziej przypominają inżynierów produktu; inni przewidują rozdzielenie na osoby o szerokich kompetencjach i specjalistów. Tak czy inaczej, odważne strategie tworzenia oprogramowania nie odnoszą dziś sukcesu wyłącznie dzięki innowacyjnym narzędziom — odnoszą go wtedy, gdy zespoły są gotowe dostosowywać swoje przepływy pracy, role i sposób myślenia.

Gdy na nowo przemyślisz swoje strategie tworzenia oprogramowania, znalezienie odpowiednich partnerów może mieć ogromne znaczenie. Możesz na przykład rozważyć współpracę z firmą zajmującą się tworzeniem niestandardowego oprogramowania lub z firmą zajmującą się tworzeniem oprogramowania w modelu nearshore, na przykład.

Zapisz się do newslettera The CTO Club, aby otrzymywać więcej wskazówek, narzędzi i najlepszych praktyk dotyczących tworzenia oprogramowania.