Pod koniec kwietnia pracowałem nad drugim produktem — narzędziem do rozliczania pracy w grantach. Stałem przed jedną z tych decyzji, które wyglądają na czysto techniczne, a w rzeczywistości decydują, czy produkt będzie potem do uratowania.
Plan był prosty: skoro każdy wpis kosztu w grancie musi mieć konkretną firmę, na rzecz której praca się odbywa, to każdy użytkownik systemu musi należeć do jakiejś firmy. Tylko że w pierwszej fazie chcę puścić produkt dla pojedynczych użytkowników — osób fizycznych, freelancerów, naukowców, którzy dopiero zakładają działalność. Co z nimi?
Najprostsze rozwiązanie podpowiedziało się samo: dla każdego nowego użytkownika automatycznie tworzysz fikcyjną „organizację osobistą” — taki techniczny stub, który spina jego konto z resztą modelu danych. Użytkownik nie wie, że ją ma. System ma wszędzie ten sam typ tożsamości. Produkt gotowy do pokazania w trzy tygodnie zamiast sześciu.
Tabelka wyglądała kusząco. Im dłużej jej się przyglądałem, tym bardziej widziałem, że to nie jest skrót — to jest fundament zbudowany ze styropianu.
NCBR i PARP — czyli dwie z najważniejszych instytucji rozdzielających pieniądze publiczne w Polsce — w każdym sprawozdaniu wymagają, żeby koszt był przypisany do realnej spółki z konkretnym numerem NIP. Audyt sprawdza NIP, podatki sprawdzają NIP, urzędnik z PARP-u patrzy w NIP. „Personal organization” z wygenerowanym wewnątrz systemu identyfikatorem nie zda żadnego z tych testów. Jeśli ktoś rozlicza grant na naszym produkcie i audytor zażąda historii kosztów, dostanie zestawienie, którego nie da się obronić — bo połowa rekordów wskazuje na podmioty, które prawnie nie istnieją.
Można powiedzieć: „dobra, dorobimy konwersję ze stuba na realną firmę w drugiej fazie”. To brzmi rozsądnie, dopóki nie zacznie się o tym myśleć. Konwersja to nie jest zmiana flagi w bazie. To rekonstrukcja historii — co stało się kiedy, na jakim podmiocie, w jakim stanie prawnym. Audyt sprawdza ciągłość: od momentu, w którym pieniądz wszedł do firmy, do momentu, w którym wyszedł. Jeśli przez pierwsze pół roku ten pieniądz był przypisany do fikcyjnego bytu, a potem nagle „migrowany” do realnej spółki, każda audytowa pętla pyta: które dane są prawdziwe — te pierwsze czy te po migracji? I nie ma na to dobrej odpowiedzi.
Audit log, na którym opiera się cała ta klasa produktów, ma dokładnie jedną twardą zasadę: zapisy są niezmienne, a referencje, do których wskazują, muszą być realnymi bytami w realnym świecie. Personal organization stub łamie tę zasadę przy pierwszym wpisie. Reszta jest tylko kwestią czasu, zanim ktoś to wykryje.
Więc napisałem ADR — krótki, pół strony — z decyzją „nie robimy tego”. Tytuł brzmiał chłodno: „Reject Personal Organization stub”. W praktyce oznaczał: kupuję sobie cztery tygodnie więcej pracy, żeby fundament był prawdziwy.
To jest dla mnie ważna lekcja o tej konkretnej kategorii skrótów. Bywają skróty, które oszczędzają czas i nic nie kosztują — usuwam zbędną abstrakcję, upraszczam interfejs, łączę dwa kroki w jeden. To są wszystkie skróty w obrębie kodu, których konsekwencje rozgrywają się w mojej głowie.
I są skróty, które oszczędzają czas teraz, a koszt płacą na zewnątrz — w audycie, w prawie, w relacji z instytucją. To są skróty w obrębie modelu biznesu. Tych po prostu nie wolno brać, choćby tabelka wyglądała ile by nie miała.
Cztery tygodnie pracy nad prawdziwym anchorem tożsamości firmy — z weryfikacją przez rejestr CEIDG i KRS — kosztują dokładnie tyle, ile kosztują. Pierwszy audyt na fikcyjnym stubie kosztowałby cały produkt.