netto

Pan Autor bloga netto Marcin Jagodziński postanowił zmienić profesję na gotowanie, więc niniejszym usuwam link do netto z blogów polecanych. Jeśli ktoś chce dowodu, że informatyk może umieć gotować - polecam kulinarny blog Marcina: http://moznagosciom.wordpress.com Hurtowo dorzucam jeszcze blog o wszystkim czyli http://brutto.tumblr.com. Enjoy.

Stabilność aplikacji

Goście siedzący obok mnie zajmują się utrzymaniem sporej aplikacji napisanej dawno temu. Jakość tego systemu po prostu mnie zadziwia (no ale czego można było się spodziewać po włochach, chyba nie tego że napiszą jakiś porządny soft). Jest więc sobie wesoły team 4 osób, użerających się z tym spaghetti-like systemem. Codziennie jedna osoba musi być od 7 rano, reszta przychodzi trochę później. Osoby przychodzące później codziennie zadają pytanie tym wcześniejszym: "i co, ile się dziś wywaliło?". Podkreślam - nie "czy się coś wywaliło", tylko _ile_. Z tego co z nimi rozmawiam, to system sypie się koncertowo. I nie ma żadnego zespołu, który zajmowałby się poprawianiem błędów i/lub ogólnie programowaniem. Nasz wspaniały team codziennie odkręca coraz to nowe błędy, bo każdy wysyp powoduje zamęt w danych. Było kilka dni (w skali lat) kiedy nic się nie wysypało, normalnie było wtedy święto lasu. To tak się pisze te duże i drogie aplikacje? :) Do pizzy i spaghetti marsz!

Jak teamy nabywają nieśmiertelność

W życiu każdej firmy zdarza się, że powstaje potrzeba wykonania pewnego projektu na potrzeby wewnętrzne. Jako przykład weźmy rzeczywistą sytuację - projekt "migracja novella do activedirectory". Nowopowstały team wyznaczony do tego zadania zostaje skompletowany w większości z aktualnie pracujących ludzi ("ty zenuś robiłeś w activedirectory więc będziesz tu teraz architektem nowego rozwiązania"). W większości przypadków ludzie idący do nowego teamu robią to z własnej woli - by wyrwać się z obecnego zespołu, by zmienić coś na lepsze, by uzyskać "awans" itp. No i mamy taki wesoły team, który robi _pożyteczny_ projekt i wszystko jest cacy. Koniec projektu, sukces, "celebration", life is good. Ale co dalej? Team wykonał projekt... rozwiązać team? Hm dla niektórych oznaczałoby to degradację, dla innych powrót do roboty z której właśnie chcieli się wyrwać. Tym bardziej, że prawdopodobnie na ich miejscu już ktoś jest. Podczas tajnego spotkania teamu pada więc propozycja: "wymyślmy nowy projekt i przekonajmy bossów, że to będzie korzystne dla firmy". Team wymyśla więc na szybko _cokolwiek_ - pada na "projekt zmniejszenia potrzebnej przestrzeni dyskowej". Mniej więcej - poprzez gimnastyczne kopiowanie, kompresowanie, przerzucanie itd - uzyskamy 10% oszczędność miejsca na serwerach. Nic to, że takie rozwiązanie jest dostępne out-of-box w już działającym systemie. Jeśli ktoś o to zapyta, powiemy że nasze rozwiązanie jest lepiej dopasowane do potrzeb naszej firmy. Nadchodzi dzień rozmowy z Bossami. Bossowie nawet jeśli kiedyś byli techniczni, teraz są już całkowicie nie na czasie. Potrzegają świat z perspektywy excela. Team entuzjastycznie prezentuje swój pomysł Bossom. 10% mniejsze zapotrzebowanie, to mniejsze koszty... czyż nie? Otumanieni Bossowie zgadzają się. Team projektuje i wdraża nikomu niepotrzebne rozwiązanie o znikomej użyteczności, pomiając koszty projektu (ale to mówi się Bossom, że jeśli nasze rozwiązanie się sprawdzi, będziemy mogli je wdrażać w innych lokacjach). Tym sposobem team ma co robić, aż do końca projektu. Wtedy musi powstać kolejny pomysł, GOTO 10. Jaka jest puenta tej opowiastki? Oto: teamy powołane do jednego zadania stają się nieśmiertelne (IDDQD) poprzez wymyślanie dla siebie nowych projektów o znikomej użyteczności. Każdy kolejny projekt charakteryzuje się niższą użytecznością a większą absurdalnością. Nie, nie jestem w takim teamie ale na codzień muszę zmagać się z efektami pracy wymienionych powyżej, bo im bardziej absurdalny projekt, tym bardziej utrudnia życie end-userom.