IT u psychiatry

Gdyby IT było człowiekiem, jak zdiagnozowałby go psychiatra? W prezentacji Nothing New Under the Sun: Continually Rediscovering the Good Ways to Build Software pada następujące rozpoznanie przypadłości branży IT:

1. ADHD. Nie skupiamy się na celu, rozpraszają nas technologiczne błyskotki.
2. Amnezja wsteczna. Powtarzamy te same błędy.
3. Zaburzenia obsesyjno-kompulsyjne. Powtarzamy bezmyślnie nic nie wnoszące rytuały.

Serwery lubią prad

James Hamilton, jedna z postaci stojących za Amazon Web Services, popełnił interesującą analizę kosztów utrzymania Data Center: Overall Data Center Costs. Nie chodzi tu o koszt administratorów czy sieci, lecz koszt utrzymania koniecznej infrastruktury: klimatyzacji, stacji transformatorowych itp.

It turns out that power is incredibly important but it’s not the utility kWh charge that makes power important. It’s the cost of the power distribution equipment required to consume power and the cost of the mechanical systems that take the heat away once the power is consumed.

Okazuje się, że jest to dominujący koszt - zaraz po koszcie samych serwerów (przy czym serwery amortyzują się znacznie szybciej). Autor podaje oszacowanie PUE dla ich DC na poziomie 1,45 i <1,2 dla Google, które uchodzi już za state of the art. ;)

Ciekawe, jakim PUE mogą pochwalić się serwerownie dużych instytucji oraz centrów kolokacyjnych w Polsce?

Luka międzyramkowa

Czasem człowiek myśli, że zna jakiś temat dość dobrze. Może nie bardzo dogłębnie, ale generalnie - ciężko go czymś zaskoczyć... do czasu. ;)

Pisałem w sierpniu o zmiennym narzucie stosu protokołów w ATM. Okazuje się, że podobny problem występuje w sieci Ethernet. Między ramki Ethernet wprowadzana jest luka (interframe gap) o stałym rozmiarze 96 bitów. Taka międzyramkowa luka wprowadza więc większy narzut (overhead) w przypadku, gdy w transmisji dominują małe ramki, a mniejszy, gdy w transmisji dominują większe ramki.

Pocieszam się, że inżynierów sieciowych CCIE też potrafi to zaskoczyć. ;)

Obgryzanie Wymagań

Pracuje sobie człowiek (nie)spokojnie, a tu nagle trach! - wpada nowy projekt. Trzeba coś zrobić.

W odróżnieniu od życia, kiedy pewne fundamentalne pytania człowiek zadaje sobie raczej u kresu ;) w projekcie zdecydowanie warto postawić te pytania od razu: "Dlaczego?", "Jak?", "Kiedy?", "Co?", "Gdzie?", "Kto?". Inaczej coś może przeobrazić się w skrzyżowanie meduzy z kameleonem - projekt o bardzo bardzo płynnym zakresie. ;)

Stawianie tych pytań to element zarządzania wymaganiami, a same pytania pożyczyłem z bloga "O wymaganiach". Stwierdziłem, że pomarudzę o tym, bo prześladuje mnie Potwór Zmiany Zakresu, a szczególnie jego odmiana bezkapuchowiec objawiająca się obgryzaniem zakresu do kości. Brr!

Potwora wywołuje zwykle sponsor, kiedy jego wybujałe oczekiwania zderzą się ze ścianą realnych kosztów projektu. Wywoływanie zachodzi np. na rytualnym, tajnym spotkaniu ważnych osób na szczycie, podczas którego rysuje się markerem tajemne znaki na białej tablicy. Zwykle łatwiej jest obciąć zakres projektu niż załatwić dodatkowe finansowanie. Rozpoczyna się polowanie, atmosfera absurdu tężeje jak w Misiu: "A gdyby tu było nagle przedszkole"?

Oczywiście, zakres nie jest cięty z chirurgiczną prezycją, powstają rany projektowe gryzione (choć niekoniecznie widać je w PowerPoincie). W efekcie powstaje wtórna fala nowych wymagań, kompensujących braki powstałe po cięciu zakresu. Tak, właśnie w środku projektu (albo nawet na końcu) nastąpiła zmiana wymagań. Wypełzają wszelkiej maści ohydne obejścia, których normalnie nikt nie odważyłby się nawet zaproponować.

Budżetowo wygląda to tak: klient chciał jaguara, ale nie było go stać więc zapłacił za mercedesa, tyle że funkcjonalnie dostał malucha. Ale mamy sukces, budżet został dotrzymany. ;)

Wracając do wymagań - po co nimi zarządzać? Cóż, warto wiedzieć, co właściwie robimy, jak i na kiedy ;) ale też trzeba mieć listę, którą można będzie rzucić Potworowi Zmian Zakresu na pożarcie. On na pewno kiedyś się pojawi i nie będzie z Tobą dykutował.

Czym powina być inżynieria oprogramowania?

Polecam wykład Glenna Vanderburga nt. tego, czym stała się i czym powinna być inżynieria oprogramowania: Real Software Engineering. Nie jest nudny. :)