15-krotny koszt złej decyzji o bazie danych: lekcje dotyczące czasu podejmowania decyzji

Zmierzyłem koszt decyzji o bazie danych w trzech systemach produkcyjnych. Koszt migracji wzrósł 15-krotnie w ciągu trzech lat nagromadzonych danych i zależności schematów.

TL;DR

Większość inżynierów odwraca logikę czasu podejmowania decyzji: deliberują dniami nad odwracalnymi wyborami (którą bibliotekę klienta API wybrać), a nieodwracalne decyzje podejmują w minuty (schemat bazy danych podczas planowania sprintu). Ray Dalio i Jeff Bezos opisują te same ramy z różnych perspektyw: odwracalne decyzje powinny zapadać szybko, bo opóźnienie kosztuje więcej niż niedoskonałość. Nieodwracalne decyzje zasługują na analizę proporcjonalną do stawki. Nauczyłem się tego na własnej skórze w trzech systemach, gdzie wczesne skróty w schemacie przerodziły się w koszty migracji rzędu sześciocyfrowych kwot.

---

Migracja, która mnie nauczyła

W pierwszym roku pracy w ZipRecruiter odziedziczyłem system, w którym pierwotny zespół wybrał zdenormalizowany schemat, aby przyspieszyć początkowy rozwój. Decyzja miała wtedy sens: wysyłaj szybko, normalizuj później. „Później” nigdy nie nadeszło.

W drugim roku trzy usługi zależały od zdenormalizowanej struktury. W trzecim roku schemat nagromadził 14 miesięcy danych produkcyjnych, relacje kluczy obcych zakładające zdenormalizowany układ oraz sześć zapytań raportowych, które psuły się przy każdej zmianie strukturalnej.

Koszt migracji w pierwszym miesiącu wyniósłby około dwóch dni inżynierskich. W dwunastym miesiącu — dwa tygodnie. W trzydziestym szóstym miesiącu szacunek wynosił trzy miesiące dedykowanego czasu inżynierskiego plus wdrożenie kroczące z logiką podwójnego zapisu, aby uniknąć przestojów. To właśnie ten 15-krotny mnożnik: nie dlatego, że problem się skomplikował, ale dlatego, że zasięg rażenia rozszerzał się z każdym miesiącem nagromadzonych zależności.¹

---

Ramy decyzyjne

Decyzje odwracalne: decyduj w minuty

Wybór frameworka frontendowego do prototypu. Wybór konwencji nazewnictwa zmiennych. Wybór regionu chmury dla środowiska testowego. Wybór, który wpis na bloga napisać jako pierwszy.

Łączy je wspólna cecha: zmiana kursu kosztuje mniej więcej tyle samo, niezależnie od tego, kiedy ją wprowadzisz. Zwlekanie marnuje czas, nie poprawiając wyniku.²

Mój test: Jeśli mogę cofnąć tę decyzję w przyszłym tygodniu w mniej niż jeden dzień pracy, decyduję teraz.

Budując tę stronę, wybrałem HTMX zamiast React w około dziesięć minut. Gdyby HTMX okazał się złym wyborem, zmiana frameworka na osobistej stronie z szablonami renderowanymi po stronie serwera zajęłaby weekend. Niski koszt odwrócenia oznaczał, że szybkość miała większe znaczenie niż analiza.

Decyzje nieodwracalne: decyduj w dni

Wybór silnika bazy danych dla danych klientów. Definiowanie kontraktu API, od którego zależą systemy zewnętrzne. Wybór architektury hooków, na której zbudowanych zostanie 86 hooków.

Te decyzje się kumulują. Koszt odwrócenia rośnie z czasem, często wykładniczo.³

Mój test: Jeśli koszt cofnięcia tej decyzji podwaja się co sześć miesięcy, inwestuję w analizę proporcjonalną do stawki.

Moja architektura hooków .claude/ to przykład nieodwracalnej decyzji podjętej właściwie. Spędziłem dwa tygodnie na projektowaniu modelu cyklu życia hooków (PreToolUse, PostToolUse, Stop i trzy inne), zanim napisałem choćby jeden hook. Ten projekt obsługuje teraz 86 hooków obejmujących bezpieczeństwo Git, kontrolę rekurencji, egzekwowanie filozofii, bramki jakości i obserwowalność. Zmiana modelu cyklu życia na tym etapie wymagałaby przepisania każdego hooka. Początkowa analiza zwróciła się wielokrotnie.⁴

---

Pięć decyzji, które podjąłem dobrze i źle

Dobrze: wybór czystego CSS zamiast Tailwind

Typ: Odwracalna. Czas poświęcony: 20 minut.

Wybrałem czysty CSS z właściwościami niestandardowymi zamiast Tailwind dla tej strony. Gdybym się mylił, mógłbym zmigrować do Tailwind w weekend. Decyzja zajęła 20 minut: bardziej ceniłem naukę podstaw CSS niż produktywność frameworka. Po dwóch latach cieszę się z wyboru czystego CSS, ponieważ każda optymalizacja (osiągnięcie idealnych wyników Lighthouse) wymagała zrozumienia, co CSS faktycznie robi. Ale decyzja mogła pójść w obie strony bez konsekwencji.

Dobrze: inwestycja w projektowanie architektury hooków

Typ: Nieodwracalna. Czas poświęcony: Dwa tygodnie.

86 hooków zależy teraz od modelu cyklu życia. Warta każdej godziny początkowego projektowania.

Źle: pośpieszny schemat treści bloga

Typ: Nieodwracalna. Czas poświęcony: 30 minut.

Zdefiniowałem dataclass ContentMeta wpisu blogowego w jednej sesji: title, slug, date, description, tags, author, published. Nie uwzględniłem category, series, hero_image, scripts ani styles. Każde późniejsze dodanie wymagało modyfikacji parsera, aktualizacji każdego szablonu konsumującego metadane i ponownego przetestowania całego potoku bloga. Pięć dodatków w ciągu trzech miesięcy kosztowało łącznie więcej czasu niż kosztowałoby staranne zaprojektowanie schematu na początku.

Źle: deliberacja nad kolejnością wpisów blogowych

Typ: Odwracalna. Czas poświęcony: Dwie godziny na sesji planowania.

Spędziłem dwie godziny na decydowaniu, które wpisy blogowe napisać najpierw. Kolejność była całkowicie odwracalna. Powinienem był zacząć pisać cokolwiek i zmienić kolejność później na podstawie tego, czego się nauczyłem.

Dobrze: staranne projektowanie progów konsensusu

Typ: Nieodwracalna. Czas poświęcony: Jeden tydzień.

Mój system deliberacji wykorzystuje adaptacyjne progi konsensusu dostosowane do zadania: 85% dla decyzji bezpieczeństwa, 80% dla funkcji, 65% dla refaktoryzacji, 50% dla dokumentacji. Źle dobrane progi albo blokowałyby uzasadnioną pracę (progi zbyt wysokie), albo zatwierdzały niebezpieczne zmiany (progi zbyt niskie). Przetestowałem każdy próg na rzeczywistych historiach zadań przed zatwierdzeniem.

---

Powszechne odwrócenie priorytetów

Inżynierowie spędzają dni na wyborze bibliotek klienta API (odwracalne, niski koszt zmiany), projektując jednocześnie schematy baz danych na spotkaniach planowania sprintu (nieodwracalne, wysoki koszt migracji).

Menedżerowie robią to samo: tygodnie na ocenę narzędzi do zarządzania projektami (odwracalne), jednocześnie restrukturyzując zespoły z dnia na dzień (nieodwracalne, wysoki koszt ludzki).⁵

Odwrócenie priorytetów zachodzi, ponieważ odwracalne decyzje wydają się istotne w danym momencie (zespół może ocenić mój wybór biblioteki), podczas gdy nieodwracalne decyzje wydają się abstrakcyjne (migracja jest za trzy lata). Te odczucia są dokładnie odwrotne do rzeczywistości.

---

Dwa pytania przed każdą decyzją

1. Ile kosztuje odwrócenie za sześć miesięcy? Jeśli odpowiedź brzmi „trywialnie” — decyduj teraz.
2. Czy opóźnienie poprawi dostępne informacje? Jeśli czekanie nie przyniesie nowych danych — decyduj teraz.

Deliberuj tylko wtedy, gdy oba warunki przemawiają za czekaniem: odwrócenie jest kosztowne i z czasem pojawią się lepsze informacje.⁶ Wszystko inne decyduj natychmiast.

---

Kluczowe wnioski

Dla inżynierów: - Wybory stosu technologicznego do prototypów są odwracalne; podejmuj je w minuty, nie na spotkaniach - Schematy baz danych i kontrakty API są nieodwracalne w skali; inwestuj w analizę z góry proporcjonalnie do tego, ile systemów będzie zależeć od decyzji - Śledź koszty swoich decyzji; zmierzenie 15-krotnego mnożnika migracji zmieniło sposób, w jaki oceniam inwestycje początkowe

Dla menedżerów: - Zmiany narzędzi i procesów są zwykle odwracalne; pilotuj szybko i iteruj - Struktura zespołu i decyzje rekrutacyjne niosą wysoki koszt odwrócenia; deliberuj proporcjonalnie - Gdy zespół spędza tydzień na wyborze biblioteki, zapytaj, czy koszt odwrócenia uzasadnia czas deliberacji

---

Źródła