Syndrom NIH - czyli jak kochamy się w swoich problemach

Raz na jakiś czas na konsultacji słyszę: “Te rekomendowane architektury chmurowe to nie dla nas, my mamy specyficzne wymagania. Zrobimy to po swojemu.”

Dlaczego po swojemu? “Bo będzie dokładnie robić to czego potrzebujemy.”

Standardowo zespół walczy z problemami które dostawca chmury rozwiązał lata temu.

Poznajcie syndrom NIH - Not Invented Here.

Co to jest ten NIH?

NIH to tendencja do unikania używania produktów, standardów czy rozwiązań z zewnętrznych źródeł. W IT to kompulsywne tworzenie własnych wersji wszystkiego.

“Po co używać sprawdzonego rozwiązania, jak możemy napisać swoje?” 🤦‍♂️

Najczęstsze przykłady które widziałem

➡️ Referencyjne architektury chmurowe są złe, stworzymy coś własnego - co z tego że nie ma sensu, ale to jest NASZE

➡️ Własny framework bo istniejące biblioteki nie spełniają 100% wymagań - ale dostosowanie procesu byłoby bezbolesne

➡️ Tool do deploymentu którego nikt nie potrzebował, ale manager który przed chwilą był jeszcze seniorem inżynierem wpchnął na siłę bo “to nasze rozwiązanie”

Dlaczego tak się dzieje?

DHH w ostatnim podcaście (nie lubię słuchać Lex’a ale warto było) trafił w sedno: “Wielu programistów jest niekomfortowych z faktem, że są zasadniczo CRUD monkeys. Tworzą systemy które głównie służą do create, read, update, delete w bazie danych i muszą zrekompensować ten strach przed robieniem czegoś nieznaczącego przez nadmierne komplikowanie rzeczy.”

🧠 EGO - jestem w IT, zrobię lepiej

🎯 KONTROLA - jak napiszemy sami, będziemy wszystko rozumieć

😴 NUDNOŚĆ - utrzymywanie istniejącego kodu to nie challenge

💔 KOMPENSACJA - potrzeba tworzenia czegoś “bardziej znaczącego”

Kiedy NIH ma sens?

✅ Istniejące rozwiązania naprawdę nie pasują do problemu

✅ Mamy unikalny przypadek użycia

✅ Koszt licencji jest wyższy niż koszt development i utrzymania

Ale to są WYJĄTKI, nie reguła.

Jak z tym walczyć?

🔍 Używaj 5xWhy - drąż głębiej dlaczego istniejące rozwiązania “nie działają”

💰 Licz prawdziwe koszty - development, utrzymanie, dokumentacja, onboarding

🪞 Sprawdź czy problem nie wynika z wcześniejszych decyzji lub założeń w które ślepo brniesz

Drodzy decydenci…

Jeśli w waszej firmie pada argument “napiszemy swoje, bo będzie lepsze” - zapalcie czerwoną lampkę. Szczególnie gdy dotyczy to infrastruktury, deploymentu czy narzędzi wspierających.

Pytanie nie brzmi: “czy umiemy to napisać?”

Pytanie brzmi: “czy POWINNIŚMY to pisać?”

Bo różnica między tymi pytaniami to często rok życia zespołu i setki tysięcy złotych.

Macie swoje historie z NIH? 😅

Tekst oryginalnie opublikowany na LinkedIn