Pracownik IT ma generować zyski

Dziś będzie brutalnie. Dlaczego pracodawca miałby Tobie dużo płacić? "Bo to IT"? Dobre żarty. "Bo znam się na X"? Ha ha ha! Otóż pracodawca może dużo zapłacić, jeśli czuje, że zarobi na Tobie jeszcze więcej. :-)

Jak można zarobić na pracowniku IT?

• Można go komuś odsprzedać z marżą. Popularny motyw w różnych informatycznych stonkach. Firma ma dojście do koryta, a studenci lubią pracę po nocach bo chcą zarobić na piwo.
• Można też wykonać jego rękami zmiany, które przyniosą realne oszczędności w firmie. I taki jest sens istnienia IT w firmie: obniżać koszty poprzez automatyzację, umożliwiać poprzez informatyzację.

Płyną z tego pewne oczywiste wnioski dotyczące zarobkowania w IT:

• nie idziesz do stonki po kasę, a co najwyżej po know-how
• jeśli IT w firmie jest tylko kosztem, to mogą mieć kiepski budżet na płace
• jeśli sprzedajesz się do jakiejś firmy, nie skupiasz się tylko na tym co umiesz, ale także na tym, ile to pozwoliło poprzednim firmom zaoszczędzić/zarobić pieniędzy
• im bardziej niszowa i gówniana technologia, tym lepiej dla portfela (choć gorzej dla satysfakcji)
• warto być blisko koryta (prawidło uniwersalne)
• dobrze jest wynajmować tanich wyrobników w Polsce B, sprzedawać ich za dobrą stawkę w Polsce A i odcinać kupony od podjętego ryzyka

Komplikacja

Świat jest skomplikowany i jego komplikacja postępuje, nic to odkrywczego. Komplikacja nieustannie przyspiesza. Coraz trudniej jest objąć zrozumieniem nawet fragment dziedziny, pogłębia się specjalizacja.

Wyzwania społeczne płynące z szybkiego rozwoju opisał m.in. Alvin Toffler w "Szoku przyszłości" już w roku 1970.

Jakie to wyzwania rodzi dla specjalistów IT? Warto przeczytać "Dizzying but invisible depth" by uświadomić sobie na prostym przykładzie, złożeniem jak wielu kolejnych warstw abstrakcji jest choćby proste skorzystanie z Internetu. Co się stanie, gdy autorzy tych wszystkich komplikacji umrą? Czy i w jakim czasie kolejne pokolenia dadzą radę się tego nauczyć? Już teraz prościej jest wrzucić cały mikroprocesor MC68000 w roli pomocniczej dla procesora właściwego, niż projektować własny układ.

Na dodatek mamy inflację danych. Dzięki narzędziom techniki można bezpiecznie i długo składować ogromne ilości danych. Kiedyś dane w naturalny sposób znikały: pożary, powodzie, gnicie i odruch sprzątania śmieci na strychu. ;-) Dlatego tak trudno nam teraz odkryć, co było kilka wieków temu. Czy nasza epoka będzie równie trudna do zbadania dla przyszłych pokoleń? Być może zdigitalizowane obrazy niemal każdego aspektu życia naszego społeczeństwa zmieszczą się na pendrivie przyszłości? :)

Krępująca kontrola kosztów

Pisałem kiedyś o dyktacie business case oraz o wydumanych zapytaniach ofertowych. Dziś popijam sobie browarek, przeglądam zaległości w czytaniu RSS-ów i naszło mnie na wynurzenia o kolejnej potencjalnej patologii, czyli forsowaniu dokładnej kontroli kosztów. Pretekstem jest tekst "Beware the Cult of ROI".

Każdy wydatek powinien być opłacalny... myśl ta brzmi sensownie. Ale jak sprawdzić, czy jest opłacalny? Można wdrożyć monitoring kosztów. To również brzmi sensownie. :-) Problem pojawia się wtedy, gdy monitoring kosztów sam z siebie generuje narzut, a więc koszty. Koszty wsparcia systemów, zasobów ludzkich zaangażowanych w utrzymanie i raportowanie, koszty opóźnień w projektach, wreszcie trudne do uchwycenia koszty jak spadek morale pracowników, jeśli system staje się uciążliwy.

Taki problem jest dobrze znany w skali państwa (fiskalizm): "Ściąganie podatków w Polsce jest drogie".
Schodząc na poziom firmy, możemy mieć następującą sytuację: w ramach projektu trzeba zakupić serwery i oprogramowanie za kwotę około 100 tys. PLN. Co robimy? Przetarg. Po co? Gdyż uzyskamy niższą cenę.

O ile niższą cenę uzyskamy? O 3 tys. PLN? A może o 9 tys. PLN? Może. Kwota nie taka znów mała. Co jednak stracimy? Czas. A czas to pieniądz. ;) Na takim mini przetargu spokojnie możemy mieć kilka tygodni "do tyłu". To mogą być konkretne, utracone korzyści biznesowe. Do tego tracimy pracę ludzi. Dokładne przygotowanie zapytania ofertowego, rozesłanie, zebranie odpowiedzi, ocena—to wszystko nie robi się samo.

Jest też druga strona medalu—poluzowanie kontroli może skończyć się wywalaniem kasy na lewo i prawo i nieuzasadnionym wzrostem kosztów w całej organizacji w perspektywie kilku lat. Finanse tylko dzielnie bronią nas przed takim czarnym scenariuszem. ;-)

Kluczowe wydaje się zachowanie zdroworozsądkowego balansu. Jeśli ktoś jest już obdarzony zaufaniem i budżetem, nie ma sensu dodatkowo krępować jego wydatków. Zwłaszcza jeśli są ułamkiem tegoż budżetu, który ktoś kiedyś przyznał i dotyczą projektu, który ktoś kiedyś zlecił i zaakceptował. ;)

Mrzonka

Kto trzyma kasę w firmie—Biznes czy IT? Oczywiście, że Biznes. Biznes generuje przychody, a IT generuje koszty. ;)

A co, gdy firma dostarcza usługi lub produkty IT? Wówczas służebna rola IT nie jest taka oczywista. Możliwa jest sytuacja, w której to Biznes to głównie handlowcy. Pełnią rolę służebną i generują koszty. ;) Jeśli źle sprzedają, to się ich zwalnia.

Kogo jest łatwiej wymienić—Biznes czy IT? To zależy od profilu firmy i stopnia jej informatyzacji. Zaryzykowałbym twierdzenie, że w firmach z branży nowych technologii Biznes można wymienić w kilka miesięcy, zaś wymiana IT jest projektem na lata.

Powstaje więc wzajemny szach: Biznes wie, że firma jest zbyt zależna od wsparcia informatyki i bez niej padnie; IT wie, że łapę na kasie trzyma Biznes.

Gdzie tytułowa mrzonka? :) Siedzi właśnie na spotkaniu z Biznesem i pokazuje, jak uczynić IT bardziej probiznesowym, ludzkim, prostym, efektywnym, przezroczystym, tanim a nawet... zbędnym dzięki outsourcingowi i chmurom. Na ekranie kolorowe kwadraty, okręgi i strzałki. Mój Boże! IT nigdy wcześniej nie było tak jasne jak teraz!

Konsultanci poważanych firm dobrze wiedzą, co boli Biznes. Na pewno IT reaguje mało elastycznie. Jest drogie, a projekty ciągle się spóźniają i kończą się porażkami, nigdy nic się nie da (nawet coaching nie pomaga). Nade wszystko wiedzą jednak, co Biznes chce usłyszeć: będzie taniej, szybciej, bardziej zrozumiale, będzie można wszystko samemu konfigurować na prostych konsolach biznesowych. Mówią więc to, co klient chce usłyszeć. Nie po to ich zatrudnili, by słuchać połajanek. ;)

Odpalimy więc projekt, dosypiemy trochę grosiwa, kupimy nowe fajne rzeczy, poczekamy na koniec wdrożenia i IT będzie jak nowe. Gotowe do wspierania kolejnych ambitnych celów biznesowych.

Czy na pewno? Kształt IT to przecież odbicie stanu Biznesu. Ciągłe zmiany wizji, chaotyczne i wyolbrzymione wymagania, okrojony budżet, ograniczone zakresy projektów—to wszystko akumulowane latami dało wiadome efekty. Właśnie dlatego zmiana powinna objąć całą organizację, a głównie... sam Biznes. Liczenie, że wystarczą same zmiany IT, to właśnie mrzonki.

Zresztą, czy te zmiany w ogóle się udadzą? Na dobry początek obetniemy budżet, powiększymy zakres projektu bez wydłużania harmonogramu oraz zrównoleglimy projekt z innymi ważnymi projektami na tych samych zasobach.

Projekt z uśmiechem

Projekt z uśmiechem—brzmi pozytywnie, ale jest jeszcze gorszy niż zwykły projekt z niesmakiem (jeśli ktoś nie wie co to, polecam dowcip).

To jeden z tych projektów, kiedy już na początku wiadomo, że się widowiskowo nie uda. Oraz że góra tego do wiadomości nie przyjmuje. Na pewno coaching (więcej pozytywnego nastawienia), praca w weekendy i damy radę... pardon, dacie radę. Siadamy w zespole, patrzymy po sobie i jest wesoło. Wesołość to ostatnia faza rozpaczy, po prostu nic już innego nie pozostało jak się chociaż pośmiać. :-) Potem trzeba tylko uważać na odłamki.

Terytoria IT

Kilka dni temu wysłałem IT do psychiatry. Dziś serwuję (za Just Enough Developed Infrastructure) IT wraz z otoczeniem zobrazowane na mapie - The Map is not the Territory: The IT-World Anno 2010. Klienci, użytkownicy, wielka czapa wszelkich form zarządzania, rozwój, testowanie i utrzymanie, bezpiecznicy, service desk oraz infrastruktura.
Ładnie to wygląda, ale co to oznacza w praktyce? W realnym świecie mamy np.:

1. Podział na biednych i bogatych. Jeden dział ma lepsze "przełożenie" i konsumuje pieniądze potrzebne innym działom.
2. Strefy skażenia. Nikt nie chce ich nawet dotykać (syndrom "to nie moje").
3. Wojenki. Jeden lokalny kacyk robi na złość drugiemu za nie swoje pieniądze i trzeba go jakoś obchodzić, żeby dopiąć celu.
4. Każdy sobie rzepkę skrobie. Brak zdolności współpracy w obliczu nadciągającej katastrofy.

Brzmi znajomo?

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.

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ł.

e-Bawidełko

Mianem e-bawidełka określił "komputery dla dziecka do nauki" jeden z komentujących posta Darmowe komputery przeszkadzają w nauce. Według mnie bardzo trafnie. Komputer jako narzędzie niesie pewne szanse, ale i ryzyka.

Niewątpliwą szansą jest możliwość dostępu do potężnej bazy wiedzy i (z czasem) nabrania biegłości w odrzucaniu rzeczy nieistotnych.

Ryzykiem jest upośledzenie rozwoju psychoruchowego, utrata koncentracji i tracenie czasu na bzdety. Jest wiele fascynujących serwisów Web 2.0, społecznościowych i znajomych w komunikatorze. Można tym wszystkim spokojnie wypełnić dobę, nawet kosztem snu.

Kluczowa jest więc umiejętność odmówienia sobie rozrywki. Które dziecko potrafi coś takiego? ;)

Zabrzmi to niewiarygodnie, ale największy rozwój moich kompetencji IT przypadł na czas, w którym nie miałem komputera. Czytałem wtedy książki lub czasopisma. ;) Dostęp do komputera i Internetu miałem w szkole i tam - w ograniczonych ramach czasowych - zajmowałem się dokłanie tym, co mnie interesowało.

Jeśli ktoś chce wydawać cudze pieniądze na sponsorowanie komputerów dla dzieci, to pewnie ma jakieś dowody na dobroczynny wpływ komputerów na intelekt dziecka? ;) Cytacik z Computers at Home: Educational Hope vs. Teenage Reality:

Students posted significantly lower math test scores after the first broadband service provider showed up in their neighborhood, and significantly lower reading scores as well when the number of broadband providers passed four.

Slajdologia

Podejmujesz dużo ważnych decyzji i nie masz czasu wnikać w ich materię? Nic trudnego, wystarczy poprosić interesariuszy o prezentacje w postaci slajdów.

Slajdy są jak papier - zniosą wszystko. Ba, są nawet lepsze, jeśli plik źródłowy nie zostanie rozpowszechniony - nie zostawiają śladów. Dobre slajdy mogą uzasadnić niejeden pokrętny Business Case. Slajdy są proste więc nawet dziecku łatwo je zrozumieć. Na slajdach można się też uprawiać korpoślizg - prezentujący sprzedaje się szerokiemu i ważnemu gremium jako kumaty gość, podczas gdy wsad do slajdów powstaje w mało widowiskowej, żmudnej pracy wielu szarych ludzi.

Oczywiście, nie chodzi o slajdy same w sobie (one są bardzo przydatnym narzędziem), lecz o to, jak wpływają na kulturę podejmowania decyzji.

Natknąłem się ostatnio w sieci na kilka niepochlebnych opinii nt. stosowania PowerPointa. Co prawda pochodzą one ze środowisk wojskowych, ale procesy decyzyjne zachodzą również w organizacjach cywilnych - zatem pozwolę sobie zacytować i polecić lekturę. ;)

We Have Met the Enemy and He Is PowerPoint

• PowerPoint makes us stupid
• It's dangerous because it can create the illusion of understanding and the illusion of control

Dumb-dumb bullets

Unfortunately, as soon as they graduate, our people return to a world driven by a tool that is the antithesis of thinking: PowerPoint. Make no mistake, PowerPoint is not a neutral tool - it is actively hostile to thoughtful decision-making. It has fundamentally changed our culture by altering the expectations of who makes decisions, what decisions they make and how they make them.

Rola szkoły

Nastał wrzesień. Czas wspominek o II Wojnie Światowej, rocznic solidarnościowych, jęk szklany deszczu i szkolnych dzwonków.

Z okazji rozpoczęcia roku szkolnego postanowiłem nawiązać do roli edukacji szkolnej w dzisiejszym społeczeństwie i polecić leciwy już nieco esej Paula Grahama: "Why Nerds are Unpopular".

Autor analizuje w nim przyczyny niskiej popularności społecznej tzw. nerdów. Przyrównuje także szkołę do organizacji typu więziennego, gdzie dorośli celowo skoszarowują swoje dzieci, które są w dzisiejszym społeczeństwie nieużyteczne (wydłużony czas edukacji potrzebnej do podjęcia jakiejkolwiek pracy, zakaz zatrudniania dzieci), może nie licząc tradycyjnej pracy na wsi przy żniwach. Po prostu nie ma co z nimi zrobić, nie ma ich kto pilnować - więc zbierzmy ich w jedno miejsce, postawmy kilku dorosłych do pilnowania i dajmy do wkucia pełno niepotrzebnych rzeczy. Lepsze to, niż żeby łazili w samopas po mieście i psuli nasze mienie. :-)

Moim zdaniem jedną z najważniejszych rzeczy, które mogą w tej sytuacji zrobić rodzice, to zaszczepiać dziecku zdolność samodzielnego myślenia, żeby nie zatonęło w szkolnej masie postępującego zidiocenia i jednomyślności.


Na zachętę cytacik:

Public school teachers are in much the same position as prison wardens. Wardens' main concern is to keep the prisoners on the premises. They also need to keep them fed, and as far as possible prevent them from killing one another. Beyond that, they want to have as little to do with the prisoners as possible, so they leave them to create whatever social organization they want. (...) What bothers me is not that the kids are kept in prisons, but that (a) they aren't told about it, and (b) the prisons are run mostly by the inmates. Kids are sent off to spend six years memorizing meaningless facts in a world ruled by a caste of giants who run after an oblong brown ball, as if this were the most natural thing in the world. (...) Now adults have no immediate use for teenagers. They would be in the way in an office. So they drop them off at school on their way to work, much as they might drop the dog off at a kennel if they were going away for the weekend. (...) Someone has to watch over them, and the most efficient way to do this is to collect them together in one place. Then a few adults can watch all of them. (...) This is the sort of society that gets created in American secondary schools. And it happens because these schools have no real purpose beyond keeping the kids all in one place for a certain number of hours each day. (...) If life seems awful to kids, it's neither because hormones are turning you all into monsters (as your parents believe), nor because life actually is awful (as you believe). It's because the adults, who no longer have any economic use for you, have abandoned you to spend years cooped up together with nothing real to do. Any society of that type is awful to live in. You don't have to look any further to explain why teenage kids are unhappy.

Jak hartowało się IPv6

Uwaga nadchodzi IPv6 - krzyczy okładka magazynu NetWorld. Z którego roku? 2010? 2009? Nie, przestałem prenumerować to pismo chyba jeszcze w ubiegłym wieku. ;) To numer 5/97 (29) - znów pochyliłem się nad szafką ze starociami.

 

Artykuł ze strony 42. informuje:

W Ameryce Północnej, Europie i Japonii rozpoczęto szeroko zakrojone prace nad stworzeniem próbnych sieci IPv6. Udział w nich biorą producenci sprzętu i administratorzy sieci. Większość producentów oczekuje, że protokół IPv6 przyjmie w połowie tego roku postać, która pozwoli na pełne wykorzystanie w przyszłym roku jego zalet w rzeczywistych sieciach.

Minęło kilkanaście lat i co? Jeśli chodzi o wdrażanie IPv6 w Internecie, nadal jesteśmy w ciemnej... leśnej gęstwinie.

Nadchodzi czas IPv6 - informuje inne pismo IDG, PC World. Tym razem z 2008 roku. ;)

Kiedy więc można spodziewać się przejścia na IPv6? Powinno to nastąpić wkrótce, gdyż przewiduje się, że pula adresów IPv4 zostanie wykorzystana do 2012 roku.

To jak to w końcu jest, skończą się te adresy IPv4 czy nie?

 

Prawdę mówiąc, świat tak dobrze czuje się z IPv4, że chyba jedynym motywatorem do migracji do IPv6 jest faktyczne wyczerpywanie się 32-bitowej przestrzeni adresowej.

 

 

 

Poza tym, adresy IPv6 są paskudne i trudne do zapamiętania. Zapamiętywanie adresów IPv4 jest łatwe i podobne do zapamiętywania numerów telefonów - nasze społeczeństwo jest do tego ewolucyjnie przystosowane. ;-)

 

O tym, że adresy IPv4 się wyczerpują, słyszymy od wielu lat. Tak wielu, że już się człowiek do tego przyzwyczaił. Wypracowano różne rozwiązania przedłużające życie IPv4. NAT pozwala podłączyć do sieci więcej komputerów niż mamy faktycznie adresów. SNI pozwala hostować wirtualki HTTPS na jednym adresie IP. Regionalni rejestratorzy wywierają presję ekonomiczną na organizacje, którym przypisano fragmenty przestrzeni adresowej, w tym posiadaczy klas PI. Trwa odzyskiwanie bloków adresowych, które przydzielano zbyt lekką ręką. Rozdawane są adresy z bloków zaznaczonych uprzednio jako zarezerwowane (sławetna sprawa alokacji 83.0.0.0/11 dla TP, która była firewallowana z wielu miejsc na świecie przez nadgorliwych administratorów; dziś prowadzi się debogonizację adresów).

 

Nieuchronnie jednak zbliżamy się do ściany. Spójrzmy do rejestru IANA. Nawet gdyby uwolnić bloki tzw. klasy E, a zrodzi na pewno wiele problemów z różnych urządzeń sieciowych, to wciąż tylko kilka dodatkowych lat.

 

Czy IPv6 oferuje coś więcej poza większą przestrzenią adresową? No cóż, na pewno wiele nowych problemów i dalszą komplikację sieci, szczególnie w czasie koegzystencji sieci IPv4 i IPv6 w Internecie. Z tematem rozprawia się Ivan Pepelnjak w poście IPv6 myths.

 

 

Na koniec smakołyki z wspomnianego numeru NetWorld z 1997, aby oddać ducha epoki... i pochichotać.

• Modnym tematem były NC
• "Plan rozszerzenia nazw domen internetowych o siedem nowych (.firm, .store, .web, .arts, .rec, .info i .nom) zyskuje coraz szersze poparcie"
• Na reklamach szacownych 3Coma, SMC czy HP widzimy, zarządzalne, stackowalne huby
• NT kontra Unix
• Przenoszenie użytkowników NT do schematu NDS
• Test wypasionego serwera HP LX Pro 6/166 SMP z 4 procesorami Pentium Pro 166MHz. Cena - skromne 30 tys. USD.
• HTML i okolice. Nowe możliwości WWW (I), a na screenshocie strona HotWired, layout przyprawiłby o zawał dzisiejszych specjalistów ;)
• Narzędzia projektowe Javy: "Istnieje już tak wiele produktów określanych mianem narzędzi projektowych Javy, że wybór między nimi staje się niemal tak kłopotliwy, jak wybór marki samochodu". (Biedacy, nie wiedzieli jeszcze o szykującej się mnogości frameworków).

Całość dopełniają dwa bardzo solidne artykuły:

• Dystrybucja strumieni multimedialnych MPEG z wykorzystaniem technologii ATM
• System RDS w Polsce

Kaszmirowy sweterek informatyka

Kiedy na spotkaniu projektowym nie jesteś w stanie rozróżnić po ubiorze szeregowych przedstawicieli IT od eleganckich Kierownika Produktu i Kierownika Projektu, to może być sygnał, że z firmą coś jest nie tak. Kiedy firma ma za dużo pieniędzy, manifestuje się to nie tylko rozdętymi systemami, ale także przesiąkaniem świata menedżerów do świata informatyków.

Idziesz do kuchni i nie słyszysz rozmowy o optymalizacji wydajności albo użytecznych bibliotekach, tylko np. o quick winach, challengowaniu, celach premiowych i wdrażaniu inicjatyw polepszających komunikację. Na spotkaniu projektowym grupa średnio zorientowanych osób debatuje nad niezbyt złożonym technologicznie problemem. Grupa nie dochodzi do konsensusu więc zaprasza się jeszcze więcej osób i dyrektorów.

Paul Graham, znany popularyzator idei start-upów, w felietonie "What Happened to Yahoo" opisuje wynaturzenia, jakie zrodziły dla tej spółki łatwe pieniądze. Zwraca szczególną uwagę na odpływ kompetencji technicznych i zestawia to z przykładami firm takich jak Google czy Facebook, które potrafią kultywować "kulturę hakerską". Ostatecznie Yahoo oddał walkowerem rynek reklam w wynikach wyszukiwania Googlowi.

Pozwolę sobie podprowadzić fragment felietonu na zachętę:

In technology, once you have bad programmers, you're doomed. (...) Most technology companies eventually get taken over by suits and middle managers. At Yahoo it felt as if they'd deliberately accelerated this process. They didn't want to be a bunch of hackers. They wanted to be suits. (...) Why would great programmers want to work for a company that didn't have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can't attract good programmers to work in a suit-centric culture. And without good programmers you won't get good software, no matter how many people you put on a task, or how many procedures you establish to ensure "quality".

Aplikacje jak krzyże

Nowe aplikacje w organizacji są jak krzyże - łatwo się je stawia, a trudno usuwa.

W gruncie rzeczy to zrozumiałe i zasadne. Komplikacja świata rośnie i znajduje odbicie w komplikacji i mnogości systemów w danej organizacji. Ale czy to jedyny powód mnożenia systemów? Wydaje mi się, że nie.

Czasem nowa aplikacja pojawia się, bo ktoś dał się przekonać slajdom na prezentacji Bardzo Drogiego Produktu, że taki produkt jest naprawdę dobry i profesjonalny. Umożliwi naszej firmie podążanie w kierunku, w którym podążają już inni. Rzeczywiście, znajomy prezes innej firmy podczas gry w golfa wspomniał, że właśnie go wdrażają. Nie możemy być gorsi - wdrażamy i my. (Charakterystyczne dla firm, które mają za dużo pieniędzy).

Kiedy indziej okazuje się, że pewien obszar działalności organizacji powinien zostać wsparty systemami IT, ale niestety kilka dotychczas wdrożonych systemów jakimś cudem nie nadaje się do tego celu. Kupujemy więc kolejny i spokój. Albo lepiej, dewelopujemy jakieś własne rozwiązanie, które ukrywa braki produktów komercyjnych.

Z czasem może się okazać, że takie własne rozwiązanie nieco się rozrosło i bez niego firma nie może funkcjonować. Co by nie mówić, rozwój własnych aplikacji daje niemal nieograniczoną elastyczność w reagowaniu na zmiany potrzeb biznesowych. Nie ma jednak wsparcia producenta - na kogo dyrekcja zwali ewentualne problemy? (Jakie problemy? - zastawia się deweloper aplikacji znający ją na wskroś i usuwający błędy "od ręki"). Doskonały powód, by wymienić je na jakieś nowe, komercyjne rozwiązanie ze wsparciem. Drogim wsparciem. W praktyce może się okazać, że co prawda wdrożono nowe, ale z jakiegoś powodu wciąż nie można wyłączyć tego starego...

Mamy więc systemy, które nie były przeznaczone do likwidacji, takie, które chciano zlikwidować, ale się nie udało, i oczywiście te nowe, które były mniej lub bardziej potrzebne.

Tych nowych nie będziemy przecież likwidować - tyle pieniędzy na to wydaliśmy... już lepiej wydać drugie tyle, by je "udrożnić" i zacząć stosować.

Tych starych nie będziemy przecież likwidować - są filarem naszej firmy, za duża rewolucja. Czasem nawet upgrade jest zbyt ryzykowny - a że utracimy wsparcie? Cóż, korzystamy z tego X lat i ile tych zgłoszeń do supportu poszło? Trzy? I rozwiązywali je ile? Dwa... tygodnie? To o całe 13 dni dłużej niż robili to nasi administratorzy.

Można spróbować zlikwidować te już raz przeznaczone do likwidacji, a co się dotąd nie udało. Pozostaje życzyć powodzenia. :-)

Migracja zawodowa w IT

Zdarzyło mi się zmienić miejsce zamieszkania celem uzyskania dostępu do lepszego rynku pracy IT (czytaj: przeprowadziłem się do Warszawy). Nigdy jednak nie rozważałem serio wyjazdu z Polski. Powodów jest kilka:

• w Polsce są rodzina, znajomi i przyjaciele
• odwiedziny kogoś w innym mieście zwykle są w zasięgu kilkugodzinnej podróży
• w Warszawie można uzyskiwać bardzo dobre dochody
• pomijając niektóre sklepy, koszty życia w Polsce są stosunkowo niskie
• bariera językowa - angielskiego używam głównie do czytania dokumentacji technicznej

Jednak od czasu do czasu dociera do człowieka impuls, który każe się zastanowić, czy nie lepiej byłoby stąd wyjechać do jakiegoś milszego kraju, np.:

• majstrowanie rządu przy VAT i OFE
• oszołomstwo obrońców krzyża i innych
• tor przeszkód między żebrakami, wszelkiej maści cwaniaczkami i agresywnymi pijanymi wyrostkami, jaki trzeba czasem zaliczyc idąc przez Centrum
• śmieci na trawnikach, palenie papierosów na przystankach i inne przejawy buraczanej mentalności
• irracjonalnie wysokie wyceny nieruchomości w Warszawie

Do tego dodałbym czynniki strategiczne:

• fatalne perspektywy demograficzne i praktycznie pewne załamanie systemu emerytalnego
• brak klasy rządzącej z prawdziwego zdarzenia i długofalowej strategii rozwoju Państwa
• podtrzymywanie iluzji dobrobytu poprzez bieżące przejadanie majątku narodowego
• mentalność "Państwo powinno mnie wspomóc" i silne poparcie polityków, którzy obiecują rozdawnictwo
• potencjalnie groźnych sąsiadów

Mówiąc wprost, o ile nie nastąpi jakaś istotna zmiana, perspektywy Polski za 20-30 lat widzę w barwach raczej ciemnych niż jasnych.
 
Wracając jednak do migracji zawodowej - do podjęcia rozważań i umieszczenia tego posta zainspirowali mnie rekruterzy firm zagranicznych, którzy zechcieli do mnie zagadnąć. Oczywiście, zagadują oni pewnie wiele osób, a tylko niektórym faktycznie udaje się przejść rekrutację (po czym jeszcze mniej z nich faktycznie decyduje się na przeprowadzkę). Konkretnie, poproszono mnie o wysłanie CV w następujących kierunkach:

1. Dublin (Irlandia)
2. Zurych (Szwajcaria)

Przyznam, że nigdy nie byłem w tych krajach i nie wiem o nich wiele. Szybkie skojarzenia miałem następujące:
 
Irlandia

• w niedalekiej przeszłości przepychanki z Wielką Brytanią i bieda
• wielka migracja Polaków w tym kierunku
• załamanie na rynku nieruchomości i ogólnie kryzys
• zdolność do szybkiego powstawania z kryzysów i rozwoju (ich kiełbasa łatwo przegoni naszą)
• niskie podatki, którymi narażali się UE
• są za wodą i jeżdżą po złej stronie ulicy

 
Szwajcaria

• neutralność i bezpieczeństwo, broń pod łóżkiem a za oknem góry
• jedno z centrów finansowych świata
• obywatelskie społeczeństwo
• autonomia - własna waluta, "nie" dla meczetów i UE
• bardziej przyda się tam niemiecki (którego nie znam) niż angielski

Podsumowując szybkie skojarzenia - oba kraje wyglądają fajnie, ale Szwajcaria bardziej, tyle że asymilacja jest zapewne trudniejsza/niemożliwa.
 
Oczywiście, wyboru nie podejmuje się na podstawie danych tak marnej jakości. ;) Zacząłem się więc zastanawiać, jakimi kryteriami posłużyć się przy bardziej szczegółowej analizie - o ile zdarzyło by się, że faktycznie stanę przed takim dylematem.

Wymyśliłem na razie następujące:

1. obecny stan i prognozowany rozwój (demografia, gospodarka)
2. bezpieczeństwo geopolityczne
3. bezpieczeństwo fizyczne
4. system podatkowy
5. czystość środowiska
6. zamożność społeczeństwa, liczność i realny wpływ warstw domagających się tzw. socjału
7. zarobki minimalne, średnie i średnie zarobki w IT
8. realne koszty pobytu i życia (żywność, komunikacja, rozrywki)
9. ceny nieruchomości i ceny najmu, dostępność
10. kultura społeczeństwa
11. łatwość i koszt podróżowania między Polską a danym krajem

Coś jeszcze? W tzw. wolnej chwili może jeszcze do tego wrócę.

Dyktat Business Case

Przeczytałem niedawno artykuł Zasada skautów. Nie jestem programistą, ale obserwuję takowych oraz całą otoczkę związaną z wprowadzaniem zmian w systemach. Artykuł proponuje, aby programiści stosowali zasadę zawsze zostawiaj kod czystszym niż go zastałeś. Udoskonalenia mogą być drobne, ale tak jak skumulowane przez lata drobne niedoskonałości doprowadzają do erozji kodu, tak skumulowane przez lata drobne usprawnienia mogą wydźwignąć kod z bagna.

Do umieszczenia tego wpisu zainspirowały mnie komentarze pod artykułem, że tego typu podejście w realnym świecie bywa niemożliwe do zastosowania. Zupełnie się z tym zgadzam albowiem obserwuję zjawisko, które nazwałem roboczo dyktatem business case'u (BC).

W firmach skupionych na działalności biznesowej, dla których IT pełni rolę służebną, nie dewelopuje się dla przyjemności, tylko do zaspokojenia określonych potrzeb biznesowych organizacji. Decyzja o wykonaniu lub nie określonej zmiany podejmowana jest po analizie BC przez zarządzających, bywa że najwyższego szczebla (zależnie od budżetu). Na tym poziomie nikt nie wnika, czy kod jest ładny. Na słupku w arkuszu kalkulacyjnym widzimy, że wydamy kwotę X i uzyskamy z tego tytułu przychody albo oszczędności na kwotę Y w horyzoncie k-letnim - to jest coś, co przemawia.

Problem jest taki, że istnieją rzeczy, które inżynier uważa za stosowne by je wykonać, ale bardzo trudno biznesowo uzasadnić związane z tym koszty. Dokumentacja, refaktoryzacja pewnych części, przeprojektowanie API, lepsze walidacje, większa uniwersalność, lepsza integracja z systemem operacyjnym, czytelniejsze logi, itd. - z punktu widzenia użytkownika biznesowego to mogą być rzeczy "mało ważne", "ryzykowne dla harmonogramu", "możliwe do realizacji w terminie późniejszym", "na inny projekt".

I rzeczywiście jest tak, że nie powstają rozwiązania dobre, tylko wystarczająco dobre. Nie obsługują niektórych specyficznych przypadków i trzeba dane poprawiać ręcznie (tańsze to niż poprawka aplikacji). Wymagają restartu co noc (akceptowalne, w nocy nie pracujemy). Mają SQL injection (ale używają ją tylko zaufani pracownicy, którzy prawdopodobnie tego nigdy nie odkryją). Działa przy zbyt dużych uprawnieniach (ale działa, a mogłaby nie działać). Ma bardzo niestandardowe skrypty uruchamiające (uczulimy administratorów). Loguje pełno śmieci i rzuca wyjątkami na lewo i prawo (dyski są tanie). Konsumuje duże zasoby (RAM jest tani). Ale za to było połowę tańsze, dzięki czemu BC w ogóle się spiął. Z punktu widzenia klienta biznesowego to może być wręcz pełny sukces.

Te drobiazgi kumulują się w czasie, a niesmak z pracy z kodem rośnie. Rośnie również kulka hacków i workaroundów, ale póki to jakoś istotnie finansowo nie uderzy w organizację (system stanie się krwiobiegiem organizacji i zacznie być blokerem jej rozwoju ze względu na trudność wprowadzania zmian), wszyscy będą z tym żyli pchając całość do przodu. Może to trwać wiele, wiele lat...

Update - w pewien sposób ilustracja tego o czym piszę ;) Brytyjski rząd: Internet Explorer 6 jest wystarczająco bezpieczny.

Ile może kosztować prosty skrypt powłoki?

Wyobraźmy sobie, że mamy sieć rozległą, złożoną z wielu elementów aktywnych IP. Elementy oraz łącza podkładowe ulegają czasem awarii. Postanawiamy stworzyć proste narzędzie monitorujące - skrypt powłoki:

• pobierający z bazy danych wykaz urządzeń,
• testujący pingiem ich dostępność,
• wysyłający e-mail do administratorów w przypadku, gdy któreś urządzenie jest nieosiągalne.

Zaniedbajmy fakt, że jest to klasyczne wynajdywanie koła. Ile może kosztować napisanie czegoś takiego?

Sprytna odpowiedź brzmi: to zależy. ;)

Zwinny administrator, posługujący się biegle powłoką i językami skryptowymi, popełni w tzw. międzyczasie jednolinijkowca. Jest to bezkosztowe lub bardzo tanie - powiedzmy 0,1 tys. PLN.

Jeśli zrobi to pracownik zewnętrzny, dojdzie jeszcze prowizja handlowca, krótka dokumentacja dla klienta, prezentacja "jak to działa" - powiedzmy że do 2 tys. PLN.

Co jednak, gdy rzecz dzieje się w środowisku objętym zarządzaniem zmianami? Warsztaty wymagań z użytkownikami, dokument analizy, kodowanie, dokumentacja i testy odbiorcze. Całkowity koszt może wynieść bez problemu 10 tys. PLN.

A gdyby to nie było w kraju PLN-ów lecz w którymś zamożnych krajów Europy Zachodniej... ;-)


Do czego zmierzam? Czy zarządzanie zmianami to źródło zła? Odpowiem: to zależy! ;)

Można wysnuć z tego różne wnioski:

1. Rzeczy, które są proste i tanie w realiach małej firmy, niekoniecznie są takie w realiach dużej firmy.
2. Uwzględniając powyższe, w realiach dużej firmy zakup bardzo drogiego, ale gotowego oprogramowania może być i tak tańszy, niż wdrażanie i wsparcie (TCO) dla oprogramowania darmowego.
3. Narzut wprowadzany przez różne standardy i metodyki może podnieść koszty rozwiązania np. o 2 rzędy wielkości, nie zawsze poprawiając jakość rozwiązania.
4. W realiach dużej firmy te podwyższone koszty mogą być wciąż zaniedbywalne, a bardziej zwinne firmy zyskują dzięki temu szansę zarobkowania (brutalnie rzecz umując, pasożytują na bezwładnej korporacji sprzedając jej prosty software za wielkie pieniądze).
5. Mnóstwo pieniędzy może zostać zmarnotrawionych na wszelkie formy zarządzania i pośrednictwa, a nie na samo rozwiązanie - jest to więc dobre miejsce na szukanie oszczędności.

Gorzej, ale czasem szybciej

Natknąłem się niedawno na ciekawy, a do tego świeży (czerwiec 2010) artykuł "You're Doing It Wrong", który popełnił znany z asertywnych wypowiedzi deweloper FreeBSD i Varnisha, Poul-Henning Kamp.

Autor daje do pieca tekstami w rodzaju: my mind wandered, and it struck me that Knuth might be terribly misleading on the performance of the binary heap, possibly even by an order of magnitude.

Trąci "Faktem", niemniej PHK ilustruje istotny problem: programiści czasem zapominają, że algorytmy o niższej złożoności obliczeniowej mogą się zachowywać gorzej niż algorytmy o wyższej złożoności obliczeniowej, dlatego projektując rozwiązanie należy uwzględnić specyfikę architektury sprzętowej i rozmiar danych wejściowych. Teoretycznie gorszy algorytm może działać szybciej dla danych wejściowych o bardzo dużym rozmiarze (wystarczającym w projektowanym zastosowaniu) ze względu na unikanie np. kosztowego stronicowania.


Jako że mamy sezon ogórkowy, podlinkuję: - You are doing it wrong! - Says who? ;)

Jak hartowała się wirtualizacja

Popełniłem ostatnio kilka bardziej technicznych wpisów, a miały być przecież wynurzenia. ;-)

Jednym ze słów-kluczy, które padły we wpisie o meetBSD, jest wirtualizacja. Ta wspaniała wirtualizacja, dzięki której możemy skonsolidować wiele mielących wiatrakami powietrze serwerów w jedną fizyczną maszynę i uratować zasoby planety; dzięki której możemy powoływać i niszczyć środowiska systemowe (np. do testów) kilkoma kliknięciami myszki.

Pamiętam, że dawno dawno był taki numer PCkuriera, w którym po raz pierwszy ujrzałem VMware, jaskółkę zwiastującą ofensywę wirtualizacji. Przeczesałem dziś metry żółtych okładek na półkach i znalazłem: numer 18/99 z 2-go września 1999 r.

Strona 30, w kategorii Oprogramowanie/Emulatory czai się recenzja Artura Wyrzykowskiego "VMware 1.0. Windows pod Linuksem". Znamienne, że produkt był właśnie w wersji dla Linuksa - "dla Windows NT 4.0 i 2000 VMware przygotowało analogiczny emulator (obecnie jeszcze w wersji beta)". Było to de facto obecne Workstation i kosztowało 299 USD. Autor przeprowadził testy SYSmarkiem, środowisko bez wirtualizacji było o 70-100% szybsze. Zastosowania? Bardzo niszowe. :) Dla kogoś, kto z jakiegoś powodu pracuje tylko pod Linuksem, a musi uruchomić jednocześnie np. MS Windows dla jakiejś specyficznej aplikacji np. Płatnika...

Dziś do zabawy w wirtualizację na desktopie mamy za darmo choćby VMware Player czy Oracle Virtualbox. Prawdziwy biznes robi się na wirtualizacji datacenter, choć i tam coraz więcej można dostać w gratisie.

Dla oddania kontekstu historycznego, kilka smaczków z tego numeru:

• str. 6 - "koszt rejestracji nazwy w domenie .PL to obecnie 300 zł (...) co roku"
• str. 12 - "Usługi katalogowe dziś i jutro", czyli NDS vs. AD - dziś już chyba nie ma wątpliwości, kto wygrał ;)
• str. 18 - "Linux od Corela", pokaz przedpremierowy ś.p. Corel Linuksa oraz Inprise ;) Delphi 5, do tego "Amerykański Departament Handlu poszukuje technologii szyfrujących, z których wybierze jedną jako oficjalny standard AES"
• str. 37 - "TCH Components wprowadził do sprzedaży (...) dyski o pojemności 18GB"
• str. 38 - "Linia komputerów ZETAN, produkowanych przez grupę ZETO (...) wzbogaciła się o komputer wyposażony w procesor Pentium III 600MHz. Zastosowano w nim płytę główną z chipsetem BX, dysk o pojemności 8,4GB oraz 128MB RAM"
• str. 57 - test monitora LCD IBM T55A o przekątnej 15'', cena? jedyne 5700 zł + VAT
• str. 58-59 - zestawienie cen modemów i faksmodemów, ceny rzędu 300-500 zł, ale pojawiają się winmodemy za 149 zł ;)
• str. 60 - informacja o ICQ99b, "w tej chwili baza użytkowników tego pakietu (...) przekracza 40 mln"
• str. 68 - "Bankructwo Iridium. Kosmiczne długi", "Linux na giełdzie. Cena akcji RedHat (...) wzrosła pierwszego dnia notowań o 370%"

Pamiętam... że dawno dawno dawno temu był tak numer C&A, w którym był test emulatora PC na Amigę... ale nie, ta szafa jest zbyt zakurzona.

Open Source Day 2010

Kilka dni temu miałem sposobność uczestniczyć w konferencji Open Source Day 2010. Tego typu imprezy służą oczywiście głównie promowaniu firm je organizujących. Liczba słuchaczy była całkiem duża (na pewno przekraczała 500), co może świadczyć o magnetyzmie:

• darmowego obiadu,
• osoby premiera Pawlaka, lub
• rozwiązań open source dla biznesu.

Niewątpliwie w czasach kryzysu i napiętych budżetów rozwiązania open source zyskały więcej uwagi. Jesteśmy świadkami zderzenia dwóch odmiennych koncepcji biznesowych: gigantów wyrosłych na kosztownych, zamkniętych aplikacjach i podgryzających coraz śmielej ich kostki agresorów uzbrojonych w niskokosztowe, zwinne rozwiązania i wsparcie społeczności. Nie jest to zderzenie widowiskowe, przypomina raczej ruchy górotwórcze. Czas i procent składany robią jednak swoje. Jeszcze kilkanaście lat temu instalując hobbystycznie mego pierwszego Linuksa (Red Hat 3.0.3) dziwiłem się, że nie ma w tym systemie ograniczenia liczby jednocześnie pracujących użytkowników...

Po latach sukcesy na polu systemów operacyjnych są szczególnie widoczne. Jestem bardzo ciekaw, czy i jak szybko podobne sukcesy pojawią się w obszarze relacyjnych baz danych klasy enterprise. Jak sam stwierdził przedstawiciel EnterpriseDB, na tym polu jeszcze wiele do zrobienia. (Ale nazwę mają już dobrą;)).

Jak zauważył przedstawiciel Red Hata, firmy oferujące wsparcie dla rozwiązań open source mają silną motywację by dbać o jakość, bo koszt wyjścia jest w ich przypadku bardzo niski. (Wystarczy nie kupować komercyjnego wsparcia i korzystać z edycji wspieranych przez społeczność, np. CentOS).

Chciałbym zwrócić uwagę na jeszcze jeden aspekt wzrostu popularności wolnodostępnego oprogramowania: tworzenie oprogramowania często traci sens i podstawy ekonomiczne. Jeśli chcesz napisać jakąś aplikację, sprawdź najpierw, czy ktoś już nie zrobił tego wcześniej i nie wrzucił na sourceforge'a. ;) Spróbuj zrobić program do słuchania mp3, przeglądania obrazków, serwer WWW, klienta poczty albo edytor tekstu i go z sukcesem sprzedać. Wiem, że można. Ale kiedyś można było bardziej - bo nie było dobrej alternatywy. Dziś na moim komputerze osobistym nie ma ani jednej płatnej aplikacji (poza samym systemem). Antywirus, firewall, archiwizer, program do nagrywania płyt, pakiet biurowy, przeglądarka zdjęć, szyfrator dysku i klienty popularnych usług internetowych - wszystko za darmo, część w modelu open source.