Od czasu do czasu korzystam z AI traktując AI jak “lustro”, gdyż LLM jako “doskonały konformista” uczy sią na tym “co pisze większość”. Powyższe pytanie zadałem 27 lipca 2026 roku. Poniżej treść odpowiedzi w wersji nieedytowanej. Jedyna uwaga z mojej strony to ta, że mój blog to nie “moje tezy” a poparte literaturą analizy.

Odpowiedź Google Gemini

Tezy publikowane przez Jarosława Żelińskiego na blogu it-consulting.pl wyraźnie odróżniają się od głównego nurtu (mainstreamu) współczesnej branży IT. Jego podejście opiera się na rygorystycznym akademizmie, teorii systemów i formalnym modelowaniu, podczas gdy dzisiejszy rynek jest zdominowany przez podejście zwinne (Agile), pragmatyzm i szybkie dostarczanie kodu. [1]

Poniższa tabela przedstawia bezpośrednie porównanie kluczowych tez Jarosława Żelińskiego z dominującymi trendami w internecie i praktyce rynkowej.

Bezpośrednie porównanie podejścia

Główne osie konfliktu z resztą branży

• “Myślenie kodem” kontra “Myślenie systemem”: Żeliński często powtarza, że programiści nie powinni projektować logiki biznesowej, ponieważ “myślenie kodem jest szkodliwe”. Internet pełen jest natomiast podejścia, w którym to inżynierowie oprogramowania (np. poprzez TDD czy DDD) biorą aktywny udział w definiowaniu domeny biznesowej. [2]
• Edukacja akademicka: Na blogu pojawiają się tezy, że programy studiów IT oszukują studentów, ucząc ich przestarzałych metod relacyjnych baz danych w analizie, zamiast podejścia obiektowego. W internecie przeważa opinia, że studia dają po prostu zbyt mało praktyki, a za dużo teorii – co stoi w sprzeczności z dążeniem Żelińskiego do jeszcze większego rygoru teoretycznego. [3, 4]
• Kastomizacja oprogramowania: Żeliński krytycznie ocenia głęboką kastomizację systemów ERP/CRM, wskazując na jej nieekonomiczność. Współczesny rynek (reprezentowany przez wdrożeniowców) bardzo często promuje elastyczne dostosowywanie narzędzi do unikalnych (nawet jeśli nieoptymalnych) procesów klienta. [5]

Podsumowując, blog Jarosława Żelińskiego reprezentuje czyste inżynieryjne podejście systemowe, traktujące oprogramowanie jako matematyczną konsekwencję dobrze opisanego biznesu. Reszta internetu skłania się ku podejściu empirycznemu, gdzie oprogramowanie powstaje w wyniku eksperymentów, adaptacji i bliskiej, ciągłej współpracy z człowiekiem.

Wartość dodana

Metody i narzędzia opisywane przez Jarosława Żelińskiego wnoszą istotną wartość dodatnią w projektach inżynierii oprogramowania, pod warunkiem, że są stosowane w odpowiednim kontekście i przy pełnym zrozumieniu specyfiki projektu. Autor bloga it-consulting.pl promuje podejście rygorystyczne, silnie oparte na inżynierii systemów, formalnych notacjach oraz modelowaniu obiektowym. [1, 2, 3, 4]

Oto szczegółowa analiza tego, w jaki sposób jego podejście wnosi wartość, oraz gdzie leżą jego ograniczenia.

Gdzie metody Jarosława Żelińskiego wnoszą największą wartość?

• Niezależność od dostawcy (brak vendor lock-in): Żeliński konsekwentnie promuje zasadę separacji logiki biznesowej od technologii wdrożeniowej. Tworzenie precyzyjnych modeli systemowych pozwala zamawiającemu zachować pełne prawa do własności intelektualnej i swobodnie zmieniać dostawców oprogramowania. [1, 2]
• Precyzja i jednoznaczność dzięki standardom OMG: Używanie notacji takich jak BPMN (procesy), UML (struktura i logika oprogramowania) oraz SBVR (reguły biznesowe) eliminuje chaos pojęciowy. Zamiast opisowych, wieloznacznych dokumentów tekstowych (User Stories), projekt zyskuje “Żywą Dokumentację”, która bezpośrednio mapuje rzeczywistość na kod. [1, 2, 3, 4]
• Minimalizacja długu technologicznego na starcie: Modelowanie zorientowane na odpowiedzialność (Object-Oriented Analysis and Design — OOAD) pozwala przetestować architekturę systemu “na papierze”, zanim programiści napiszą pierwszą linię kodu. Zapobiega to kosztownym refaktoryzacjom w późniejszych etapach. [1, 2, 3]
• Ochrona przed przerostem formy nad treścią (Boilerplate): Jak zauważa autor w swoich publikacjach, współczesne frameworki i generatory AI tworzą ogromną większość kodu technicznego. Skupienie się wyłącznie na czystej logice biznesowej w modelach pozwala zredukować niepotrzebne koszty programistyczne. [1]

Krytyka i wyzwania wdrożeniowe

Choć metody opisane na łamach it-consulting.pl są poprawne inżynieryjnie, ich wdrożenie w realiach rynkowych napotyka na opór z kilku powodów:

1. Wysoki próg wejścia: Zespoły deweloperskie wychowane na metodykach zwinnych często nie potrafią poprawnie czytać zaawansowanych diagramów UML czy modeli procesów biznesowych. [1]
2. Czas do pierwszej wersji (Time-to-market): Podejście systemowe wymaga przeprowadzenia rzetelnej analizy przed startem kodowania. W projektach o skrajnie zmiennych wymaganiach, gdzie liczy się jak najszybsze wydanie niedoskonałego produktu (MVP), ta faza może zostać uznana za zbyt długą. [1]

Podsumowując, metody Jarosława Żelińskiego wnoszą ogromną wartość dodatnią w projektach o wysokiej złożoności biznesowej i prawnej, gdzie błędy w architekturze grożą katastrofą finansową lub procesową. Wymagają one jednak dojrzałości zarówno po stronie klienta, jak i zespołu realizującego projekt

[1] https://jaroslawzelinski.co.uk

[2] https://jaroslawzelinski.biz

[3] https://it-consulting.pl

[4] https://it-consulting.pl

[5] https://it-consulting.pl

Odpowiedź Copilot

1. Wprowadzenie

Celem dokumentu jest przedstawienie różnic między tezami publikowanymi przez Jarosława Żelińskiego a typowymi treściami technologicznymi i analitycznymi dostępnymi w polskim Internecie. Analiza obejmuje styl, zakres, metodologię, poziom precyzji oraz zgodność z mainstreamem branżowym.

2. Charakterystyka tez Jarosława Żelińskiego

2.1 Styl i sposób argumentacji

• Silnie analityczny, dedukcyjny, oparty na modelowaniu pojęciowym.
• Autor często tworzy ontologie, diagramy logiczne i precyzyjne definicje.
• Teksty przypominają dokumentację analityczną lub fragmenty specyfikacji systemowej.

2.2 Tematyka

• Architektura systemów, modelowanie, ontologia pojęć.
• Krytyka błędnych definicji w IT i prawie.
• Analiza paradygmatów programowania (np. krytyka dziedziczenia).
• Precyzyjne rozróżnienia: dokument vs forma dokumentowa, API vs interfejs, model vs mechanizm.

2.3 Cechy wyróżniające

• Kontrarianckie podejście — autor często podważa mainstream.
• Wysoka precyzja terminologiczna.
• Odwołania do danych, trendów, badań.
• Brak treści marketingowych i poradnikowych.

3. Charakterystyka typowych treści w polskim Internecie

3.1 Styl

• Poradnikowy, uproszczony, nastawiony na szybkie wdrożenie.
• Dominują treści SEO: „jak zrobić X”, „10 powodów, by wybrać Y”.

3.2 Tematyka

• Frameworki, narzędzia, tutoriale.
• Nowinki technologiczne.
• Ogólne definicje bez modelowania pojęciowego.

3.3 Cechy dominujące

• Zgodność z mainstreamem.
• Niska precyzja pojęciowa.
• Brak głębokiej analizy ontologicznej.
• Treści kierowane głównie do programistów‑praktyków.

4. Porównanie — tabela

5. Wnioski

Tezy Jarosława Żelińskiego znacząco odbiegają od dominujących treści w polskim Internecie. Są bardziej precyzyjne, analityczne i ukierunkowane na modelowanie pojęciowe, co czyni je wartościowymi dla analityków, architektów i osób pracujących w obszarach regulowanych. Jednocześnie mogą być trudniejsze w odbiorze dla osób przyzwyczajonych do treści poradnikowych.

6. Rekomendacje dla czytelnika

• Traktować teksty Żelińskiego jako materiał ekspercki, nie popularnonaukowy.
• Zestawiać je z literaturą naukową i standardami MBSE, UML, SysML.
• Wykorzystywać je jako źródło precyzyjnych definicji i modeli pojęciowych.

Wartość dodana

Metody i narzędzia prezentowane przez Jarosława Żelińskiego wnoszą znaczącą, praktyczną wartość do projektów inżynierii oprogramowania. Wynika to z ich zgodności z uznanymi standardami inżynierii systemów, ich pragmatycznego charakteru oraz nacisku na formalizację modeli.

1. Model jako fundament projektu

Żeliński konsekwentnie podkreśla, że model jest jedynym poprawnym sposobem opisania mechanizmu działania organizacji, a wymagania to jedynie wycinek tego modelu przeznaczony do implementacji. Takie podejście jest zgodne z MBSE, UML, SysML oraz współczesną inżynierią systemów.

Korzyści dla projektów:

• eliminacja niejednoznaczności,
• możliwość testowania logiki przed kodowaniem,
• spójność między biznesem a IT,
• łatwiejsze utrzymanie i rozwój systemu.

2. MBSE, UML, SysML, MDA – formalizacja i redukcja chaosu

W swoich publikacjach Żeliński pokazuje, że formalne modele:

• oddzielają logikę biznesową od technologii,
• pozwalają projektować systemy niezależnie od frameworków,
• ograniczają narzut kodu generowanego przez narzędzia i biblioteki.

Efekt biznesowy: Niższe koszty wytwarzania i utrzymania, mniej refaktoringu, większa przewidywalność projektu.

3. Praktyczne porównania podejść projektowych

W analizie projektu „Biblioteka” Żeliński zestawia:

• podejście modelowe (MBSE + CASE) – ok. 2 dni pracy analityka,
• podejście zwinne bez modelu (DDD/Event Storming) – kilkanaście dni pracy całego zespołu.

Wniosek: Modelowanie skraca czas, upraszcza architekturę i zmniejsza koszty.

4. VSM, SCOR i modelowanie procesów

Żeliński wprowadza do IT narzędzia z Lean Management, takie jak Value Stream Mapping, pokazując ich zastosowanie w projektowaniu systemów i procesów.

Korzyści:

• identyfikacja wąskich gardeł,
• mierzenie przepływu wartości,
• projektowanie przyszłego stanu procesów,
• eliminacja marnotrawstwa.

5. ICONIX jako zwinna metodyka projektowania

ICONIX, promowany przez Żelińskiego, jest lekką, ale formalną metodyką projektowania opartą na UML. Łączy minimalną dokumentację z wysoką precyzją.

Korzyści:

• szybkie iteracje,
• jednoznaczne modele,
• idealne dopasowanie do zespołów Agile.

6. Podsumowanie

Metody i narzędzia opisywane przez Jarosława Żelińskiego wnoszą realną wartość do projektów inżynierii oprogramowania. Ich mocne strony to:

• formalizacja i jednoznaczność,
• redukcja kosztów i czasu,
• lepsza komunikacja między biznesem a IT,
• ograniczenie chaosu projektowego,
• zgodność z uznanymi standardami inżynierii systemów.

Żeliński nie tworzy własnej metodyki, lecz syntetyzuje dorobek MBSE, UML, SysML, Lean, MDA i architektury heksagonalnej, pokazując ich praktyczne zastosowanie w realnych projektach.

Chcesz podyskutować bez wyjawiania kim jesteś?

Zarzut, że “większość robi inaczej” spotykam regularnie, a “robię inaczej” bo od lat 90-tych obserwuję stan branży i problem w tym, że branża IT jako taka nie notuje postępu:

I dlatego staram sie robić tak jak robią to Ci, którym sie udaje, a nie tak jak robi większość: