Dekonstrukcja architektury w czasach kryzysu.
summary
Argues that software problems are systemic not technical, using systems thinking and complexity theory to explain architecture crises: stocks and flows, balancing and reinforcing loops, and common traps. Gives concrete failures — a memory leak with cron restarting every 30 minutes that hid the root cause, and schema upgrades that balloon from 15 minutes to 6 hours because backups contend for I/O — and traces how buying hardware failed. Recommends measuring absolute metrics (pick 2–3), privatizing shared resources, and reading Thinking in Systems and Complexity for practical leverage points.
AI-written summary · about
chapters (19)
- 0:00Wprowadzenie do dekonstrukcji architektury
- 1:04Codzienna praca programisty bez internetu
- 3:36Systemy to nie tylko kod w repozytorium
- 5:26Ewolucja systemów a wzrost złożoności
- 8:18Rozpoznawanie kryzysu w architekturze
- 11:36System thinking a problemy inżynierskie
- 13:03Tech narcissism in meetings
- 15:10Podstawy myślenia systemowego
- 18:05Kluczowe pojęcia systemów: stany i przepływy
- 20:39Pętle wzmacniające i równoważące w systemach
- 24:16Opóźnienia w systemach i ich niebezpieczeństwo
- 25:22Systems in finance ecology IT
- 26:26Pułapki systemowe: Tragedia wspólnego pastwiska
- 29:24Boiling frog trap in software
- 33:46Studium przypadku: Rosnąca złożoność systemu
- 36:37Mierzenie zmian systemowych wartościami bezwzględnymi
- 38:04Punkty dźwigni systemowej i ich ograniczenia
- 40:09Dlaczego branża IT powinna uczyć się od starszych dyscyplin
- 40:53Zakończenie: Zabij framework, użyj mózgu
related talks
45mThe Unbearable Weight of Architecture
48mArchitecture: The Stuff That's Hard to Change
50mThe Unbearable Weight of Architecture
52mFrom Code to Complexity: Shifting to Systems Thinking in Software Development
49mWhy software architects fail: and what to do about it
51mSoftware Architecture for Humans!
54mSoftware architecture evolution, what to expect? Panel Discussion
58mThe past, present and future of Architecture