Over-engineering po cichu winduje koszty
Znasz to? Zatrudniasz zespół, który ma zbudować prosty landing page z formularzem kontaktowym, a oni proponują architekturę mikroserwisową, konteneryzację na K8s, event-driven messaging i deployment na trzech strefach dostępności w chmurze. Po trzech miesiącach masz przepłacony projekt, który nadal nie działa, bo „trzeba jeszcze zintegrować monitoring i logowanie”.
Over-engineering to jedna z najczęstszych przyczyn utraty kontroli nad budżetem IT w małych i średnich firmach. Brzmi znajomo?
Jako inżynier i właściciel firmy technologicznej widzę to nagminnie. Programiści – często w dobrej wierze – chcą zastosować najlepsze praktyki, które słyszeli na konferencjach. Tymczasem biznes płaci za coś, czego w ogóle nie potrzebuje.
W tym artykule pokażę Ci 3 konkretne sygnały, że over-engineering niszczy Twój budżet. Każdy z nich ilustruję realnym przykładem z rynku.
Sygnał nr 1: Abstrakcje dla abstrakcji
Kiedy widzę w projekcie małej firmy warstwę abstrakcji dla repozytorium, interfejsy dla każdej klasy (nawet tej, która ma jedną implementację) i factory pattern dla factory patternu – wiem, że ktoś czytał za dużo książek o wzorcach projektowych.
Przykład z życia
Klient – średniej wielkości sklep e-commerce – zamówił aplikację do zarządzania magazynem. Zespół deweloperski (3 osoby) zaimplementował:
- abstrakcyjną fabrykę do tworzenia encji,
- repozytorium z interfejsem i dwoma implementacjami (jedna dla PostgreSQL, druga dla MongoDB – bo „na przyszłość może zmienimy bazę”),
- warstwę usług z oddzielnymi interfejsami dla każdej operacji CRUD.
Efekt? Kod miał 15 tysięcy linii dla funkcjonalności, którą można było napisać w 3 tysiącach. Czas developmentu wydłużył się o 40%. Koszt projektu wzrósł z planowanych 80 tys. zł do 130 tys. zł.
Po roku żadna z „przyszłościowych” abstrakcji nie została wykorzystana. Kod stał się trudny w utrzymaniu, a każda zmiana wymagała modyfikacji w 5 miejscach.
Konsekwencje biznesowe
Abstrakcje nie są złe – ale muszą być uzasadnione. Jeśli Twój zespół dodaje warstwę, która nie rozwiązuje realnego problemu dzisiaj, tylko „może się przydać” – płacisz za nią w czasie pisania, testowania i utrzymania.
Sygnał nr 2: Przeskalowana architektura na starcie
Kolejny klasyk: zanim produkt ma pierwszego użytkownika, architektura zakłada miliony requestów na sekundę. Mikroserwisy, event sourcing, CQRS, Kubernetes, CDN z edge computingiem… Tymczasem MVP to aplikacja obsługująca 50 użytkowników dziennie.
Przykład z życia
Startup z branży HR-tech budował platformę do onboardingu. CEO chciał być przygotowany na „eksplozję wzrostu” po publikacji w Product Hunt. Zespół (4 senior developerów) postawił na 12 mikroserwisów, każde w osobnym kontenerze na Kubernetes, z load balancerem i automatycznym skalowaniem.
Koszty chmury: 2000 USD miesięcznie – na samą infrastrukturę, zanim pojawił się pierwszy płacący klient. Po 6 miesiącach startup miał 150 użytkowników, a rachunek za chmurę wyniósł łącznie 12 000 USD za nic.
Gdyby postawili na prostą aplikację monolityczną na VPS za 50 USD miesięcznie – zaoszczędziliby 11 700 USD. I mieli czas na walidację produktu.
Konsekwencje biznesowe
W małej firmie skalowanie powinno być odpowiedzią na realne obciążenie, a nie założeniem. Każdy miesiąc utrzymania heavy infrastruktury bez użytkowników to pieniądze, które mogły pójść w marketing lub rozwój produktu.
Sygnał nr 3: Testy jednostkowe kosztujące więcej niż kod produkcyjny
Testy są ważne. Ale jeśli Twój zespół pisze testy dla każdego gettera i settera, osiągając 100% pokrycia kosztem czasu i czytelności – to jest sygnał alarmowy.
Przykład z życia
Klient – firma logistyczna – zleciła rozbudowę wewnętrznego systemu do zarządzania flotą. Programiści mieli narzucony standard 95% pokrycia kodu testami. Efekt? Pisanie testów zajmowało 60% czasu sprintu. Kod produkcyjny był prosty (CRUD + kilka procesów biznesowych), ale testy były ogromne – z mockami, stubami i wieloma przypadkami brzegowymi, które nigdy nie wystąpią.
Projekt miał termin 4 miesięcy. Zespół opóźnił się o 2 miesiące, a koszt wzrósł z 200 tys. zł do 320 tys. zł. Po wdrożeniu okazało się, że testy nie złapały krytycznego buga w logice biznesowej, bo były zbyt skupione na izolowanych jednostkach.
Konsekwencje biznesowe
Nadmiar testów jednostkowych nie tylko wydłuża czas, ale też uśpi czujność. Prawdziwe problemy leżą w integracji i logice biznesowej, a nie w tym, czy getter zwraca to, co dostał w konstruktorze.
Jak rozpoznać over-engineering w swoim projekcie? Checklista dla CTO i CEO
Oto pytania, które warto zadać:
- Czy istnieje co najmniej jeden powód biznesowy dla każdej warstwy abstrakcji?
- Czy architektura odpowiada aktualnej skali, czy „przyszłej” (którą może nigdy nie osiągniemy)?
- Czy zespół więcej czasu spędza na konfiguracji narzędzi niż na pisaniu logiki biznesowej?
- Czy każda zmiana wymaga modyfikacji w wielu miejscach?
- Czy koszty utrzymania infrastruktury przewyższają koszty samego produktu?
- Czy testy są proporcjonalne do ryzyka biznesowego? (Czy testowanie gettera ma sens, skoro koszt błędu to 0 zł?)
Jeśli odpowiedź na któreś pytanie brzmi „tak” – masz over-engineering.
Podsumowanie
Over-engineering to cichy zabójca budżetu IT. Nie rzuca się w oczy, bo każda decyzja wydaje się racjonalna w oderwaniu. „Może się przyda”, „lepiej być przygotowanym”, „tak się robi profesjonalnie” – to pułapki.
W JurskiTech stawiamy na pragmatyzm. Zbudujemy takie rozwiązanie, jakiego potrzebujesz na dzisiaj – z myślą o łatwej rozbudowie, ale bez przepłacania za niepotrzebną złożoność. Bo dobra architektura to nie ta najnowocześniejsza, ale ta, która przynosi wartość.
A Ty? Widzisz któryś z tych sygnałów w swoim projekcie? Daj znać w komentarzu – chętnie podyskutuję o realnych kosztach over-engineeringu.
