Im większy system, tym trudniej mu się ruszyć

Skąd ta myśl.

Dziś rano patrzyłem, jak zmiana w mojej aplikacji wchodzi na serwer. Dwie minuty i jest u wszystkich. I naszła mnie myśl o tych największych na rynku, z tysiącami gabinetów na pokładzie. Oni tak nie mają.

Od razu zaznaczę: nie piszę tego, żeby komuś dokopać. Zbudowali rzeczy, z których korzysta pół branży, i należy im się za to szacunek. Ale im dłużej sam buduję system rezerwacji, tym lepiej rozumiem, jaką cenę płaci się za bycie dużym.

Stary kod nie wybacza.

Każdy system zaczyna tak samo: szybko, byle działało, bo klienci czekają. Na starcie to zaleta. Problem w tym, że kod z tamtych pierwszych lat zostaje na zawsze. Obrasta poprawkami i wyjątkami, których po latach nikt już nie umie wytłumaczyć.

Aż przychodzi moment, w którym nikt nie chce niczego dotykać. Bo nie wiadomo, co się posypie.

Duży nie może się pomylić.

Kiedy masz tysiące gabinetów, każda zmiana to operacja na żywym organizmie. Coś przestawisz i w setkach salonów właśnie zniknął komuś kalendarz na jutro. Trzeba szkolić ludzi, obdzwaniać klientów. Więc zmienia się rzadko i ostrożnie, a z czasem najbezpieczniej jest nie zmieniać nic.

To nawet nie jest niczyja wina. To logika dużej skali. Tylko że przez tę logikę produkt zaczyna stać w miejscu, a klienci to prędzej czy później czują.

Mały porusza się inaczej.

Ja mogę dziś przebudować pół aplikacji w tydzień. Nie dlatego, że jestem mądrzejszy. Dlatego, że jestem mały. Jak coś zepsuję, naprawiam w godzinę i przepraszam garstkę ludzi, a nie pół Polski.

To uczciwa przewaga małych. I jedyny moment, w którym się ją ma, bo duzi też ją kiedyś mieli.

Kiedyś to my będziemy duzi. Oby.

Piszę to trochę jako notatkę dla samego siebie. Staram się budować prosto, z małą liczbą reguł, i zapisywać, czemu coś działa tak, a nie inaczej. Nie z porządności. Z wyrachowania, bo wiem, że za parę lat sam mogę być tym gościem, który boi się dotknąć własnego kodu.

Może uda się tego uniknąć. Wszyscy przede mną też tak myśleli.