Czy przepisywać system od zera? Case study z błędów

Odpowiedź brzmi: prawie nigdy. A jeśli już musisz, to najpierw przeczytaj ten artykuł, żeby uniknąć kosztownych błędów, które my – z właściwym sobie talentem do wpakowania się w kłopoty – już popełniliśmy. W NexTech Solutions przeszliśmy przez trzy pełne „rewolucje systemowe”, zanim zrozumieliśmy, że większość problemów da się rozwiązać bez palenia mostów i zaczynania od zera. Oto nasza historia – pełna bolesnych lekcji, niepotrzebnych wydatków i momentów, w których chcieliśmy uderzać głową w klawiaturę.

Dlaczego każdy chce przepisywać system od zera?

Bo to takie katharsis w wersji dla programistów. Stary, pokraczny kod to jak mieszkanie po teściowej – wydaje się, że łatwiej wyburzyć i postawić nowe, niż próbować remontować. Niestety, życie (i biznes) rzadko bywa tak proste.

W naszym przypadku impulsy były trzy:

• Zespół narzekał na „spaghetti code” – a kto nie narzeka? Problem w tym, że nowy kod po 6 miesiącach też staje się spaghetti, tylko droższym.
• Nowe technologie kusiły – bo przecież jeśli konkurencja używa Reacta 18, to nasz AngularJS to już „dinozaur”. Zapomnieliśmy tylko spytać klientów, czy zauważają różnicę.
• Architektura „nie skalowała” – prawda, tylko że nasz biznes też nie skalował tak szybko, jak zakładaliśmy. Wyszło na to, że przepisaliśmy system na milion użytkowników, gdy mieliśmy ich 50 tysięcy.

Pierwsza rewolucja: Wielkie Sprzątanie 2018

Rok po założeniu firmy uznaliśmy, że nasz MVP to „hańba dla inżynierii oprogramowania”. Zatrudniliśmy więc zespół „dojrzałych specjalistów” (czytaj: droższych), którzy mieli zbudować wszystko „jak należy”.

Najzabawniejsze? Po roku nowy system miał te same problemy co stary, tylko był trudniejszy w modyfikacji, bo „profesjonalna architektura” wymagała 5 warstw abstrakcji do zmiany koloru przycisku.

Druga rewolucja: Microservices Mania 2020

Wpadliśmy w modę na mikrousługi jak nastolatek w pierwszym związku – bezrefleksyjnie i z przekonaniem, że to rozwiązanie na wszystko. Podzieliliśmy monolitu na 37 (!) oddzielnych serwisów. Efekty?

• Zespoły spędzały 60% czasu na ustalaniu interfejsów między serwisami
• Proste funkcje wymagały koordynacji 5 zespołów
• Koszty infrastruktury wzrosły 4-krotnie
• Debugowanie przypominało szukanie igły w stogu siana… gdzie siano też było rozrzucone po 37 kontenerach

Po 8 miesiącach wróciliśmy do… no właśnie, nie do monolitu, ale do „modularnego monolicitu”, czyli czegoś bardzo podobnego do tego, od czego zaczynaliśmy. Tylko że wydaliśmy pół miliona dolarów, żeby to zrozumieć.

Czego się nauczyliśmy? 7 bolesnych lekcji

1. „Stary system” zwykle działa lepiej niż Ci się wydaje

To jak z samochodem – może nie lśni jak nowy, ale jeśli wozi Cię z punktu A do B, może nie warto go wymieniać na leasingowy cud techniki, który kosztuje 3x więcej?

2. Refaktoryzacja > Rewolucja

Zamiast „wszystko od nowa”, spróbuj:

• Wyodrębniania modułów krok po kroku
• Stopniowego zastępowania najsłabszych elementów
• Budowania nowych funkcji w „czystym kodzie” obok starego

3. Nowe technologie to narzędzia, nie cele

React, Kubernetes, blockchain – świetne rozwiązania… dla problemów, które faktycznie masz. My wpadliśmy w pułapkę „rozwiązań szukających problemów”.

4. Klienci nie płacą za czystość kodu

Oczywiście, jakość ma znaczenie. Ale jeśli poświęcasz 6 miesięcy na „udoskonalanie architektury” zamiast dodawać funkcje, za które klienci gotowi są płacić… cóż, gratulacje, właśnie zbudowałeś najpiękniejszy produkt bez rynku.

5. Zespół zawsze będzie narzekać na kod

To jak z biurem – zawsze za ciasne, za ciemne lub za głośne. Kod też nigdy nie będzie idealny. Zamiast ulegać każdej frustracji, stwórz proces ciągłej poprawy.

6. Migracja danych to Twój nowy koszmar

Myślałeś, że pisanie systemu to trudne? Poczekaj, aż spróbujesz przenieść do niego dane ze starego rozwiązania. To jak przeprowadzka, gdzie wszystkie kartony nagle zmieniają kształt i wagę.

7. Biznes nie wybacza przestojów

Te 2 tygodnie awarii podczas naszej pierwszej migracji? Kosztowały nas utratę 3 kluczowych klientów. Żaden z nich nie uwierzył w tłumaczenie „ale teraz mamy super system”.

Kiedy jednak warto przepisać system?

Istnieją sytuacje, gdy „wielka rewolucja” ma sens:

• Zmiana fundamentalnych założeń biznesowych – jeśli z marketplace’u przechodzisz na SaaS, to faktycznie potrzebujesz nowej architektury
• Technologiczna zapaść – gdy Twoja platforma oparta jest na technologiach, które nie są już wspierane (np. Flash w 2020)
• Skala naprawdę przestaje pasować – i mówimy o wzroście 100x, nie 2x
• Bezpieczeństwo – gdy obecny system ma luki, których nie da się rozsądnie załatać

Nawet wtedy jednak warto rozważyć podejście ewolucyjne – budowanie nowego systemu równolegle do starego i stopniowe przełączanie funkcji.

Nasze obecne podejście: chirurgia, nie rewolucja

Dziś stosujemy prostą zasadę: jeśli coś boli, leczymy konkretny ból, nie cały organizm. Oto nasz przepis:

1. Zidentyfikuj rzeczywisty problem – co konkretnie nie działa? Wydajność? Utrzymanie? Skalowalność?
2. Zmierz – zanim zoptujesz kod, który „wydaje się wolny”, sprawdź, czy to faktycznie wąskie gardło
3. Napraw lokalnie – często wystarczy przepisać 10% systemu, by uzyskać 90% korzyści
4. Izoluj nowe funkcje – nowe moduły buduj w „czystej architekturze”, stopniowo odcinając stare części
5. Ucz się na błędach – każda zmiana to lekcja na przyszłość; dokumentuj, co poszło nie tak

Od dwóch lat stosujemy to podejście i… cóż, system wciąż nie jest idealny. Ale działa, rozwija się i – co najważniejsze – przynosi pieniądze, zamiast pochłaniać je na niekończące się przepisywanie.

Podsumowanie: czy warto przepisywać system od zera?

Jeśli szukasz krótkiej odpowiedzi: nie. Jeśli szukasz dłuższej: prawie nigdy, chyba że masz bardzo konkretny powód, poparty twardymi danymi, a nie tylko programistyczną frustracją lub technologiczną modą.

Pamiętaj: w biznesie liczy się wartość dostarczana klientom, nie elegancja Twojego kodu. A najlepszy system to taki, który – mimo wszystkich swoich niedoskonałości – pozwala Ci zarabiać pieniądze i rozwijać biznes.

Chyba że jesteś venture capitalistą płacącym za te eksperymenty. W takim przypadku – śmiało, przepisujcie! My zawsze chętnie skorzystamy z Twoich lekcji… za darmo.

Piotrek

Cześć, jestem Tomasz Nowak – CEO i współzałożyciel NexTech Solutions, globalnego startupu technologicznego, który z 3-osobowego zespołu rozrósł się do ponad 200 pracowników w 7 krajach.

Kim jestem?

Mam 35 lat i od 12 lat działam w branży technologicznej, w tym od 5 lat jako CEO. Z wykształcenia jestem magistrem informatyki (Politechnika Warszawska), ukończyłem również MBA na INSEAD, ale moim prawdziwym uniwersytetem był proces budowania firmy od zera do globalnego zasięgu.

Wierzę w podejmowanie decyzji w oparciu o dane, nie intuicję. Cenię sobie bezpośrednią komunikację i transparentność – zarówno w relacjach z zespołem, jak i na tym blogu. Jestem pragmatycznym wizjonerem – potrafię marzyć o wielkich rzeczach, ale zawsze z planem realizacji w ręku.

Moje wartości

• Transparentność i uczciwość – fundamenty każdego trwałego biznesu
• Innowacyjność – nie jako modne hasło, ale codzienna praktyka
• Kultura organizacyjna oparta na odpowiedzialności i autonomii
• Rozwój pracowników jako klucz do sukcesu firmy
• Globalne myślenie od pierwszego dnia działalności

Poza biznesem

Wstaję codziennie o 5:30, by zacząć dzień od medytacji i treningu. Mimo intensywnego grafiku (ponad 50 lotów biznesowych rocznie), staram się utrzymywać work-life balance. Biegam w triatlonach, gram w tenisa i jestem aktywnym mentorem dla młodych przedsiębiorców.

Najważniejsza rola w moim życiu? Ojciec dwójki dzieci, dla których staram się być obecny mimo wymagającego biznesu.

Dlaczego ten blog?

„Strona Szefa” to moja przestrzeń do dzielenia się praktyczną wiedzą z zakresu zarządzania i budowania globalnego biznesu. Bez korporacyjnego żargonu, bez pustych frazesów, za to z konkretnymi przykładami i danymi.

Piszę zarówno o sukcesach, jak i porażkach – bo to z tych drugich płyną najcenniejsze lekcje. Jak mawiamy w zespole: „Nie ma nieudanych projektów, są tylko eksperymenty z nieoczekiwanymi rezultatami.”

Jeśli szukasz praktycznej wiedzy o budowaniu startupu, zarządzaniu zespołem w szybko rosnącej firmie i skalowaniu biznesu na globalną skalę – jesteś we właściwym miejscu.