sobota, 25 kwietnia 2015

Awaria "komputera" ;-) w Starbucksie

"Gazeta" pisze: "Prawdopodobnie awaria komputera była przyczyną potężnej awarii...". Tak, piasek dostał się w tryby albo rurka przetarła i płyn chłodniczy wyciekł. Kiedy dziennikarze nauczą się używać określenia "błędnie zaprojektowane oprogramowanie"? Bo "awaria komputera" sugeruje kogoś, kto edukację w dziedzinie IT zaczął i skończył na - skądinąd znakomitym! - tekście Lema "Karkulowsiał zwartusiał, ratuwsianku Bożywsio".

Starbucks potwierdza: " the outage was caused by an internal failure during a daily system refresh".

QA, tak? ;-)

Jakość podnieca!

Będę miał wystąpienie podczas konferencji o fajnej nazwie "Jakość podnieca" (Quality Excites), 30 maja w Gliwicach:


Na temat testowania na podstawie ryzyka. O, tak:


Na codzień, jest tak:


Co jest szczególnym przypadkiem poniższej zasady:

 W detalach, ta zasada wygląda następująco:

Więcej - w GLIWICACH!






środa, 15 kwietnia 2015

70 proc. kontrolowanych przez NIK projektów IT z wadami!

(oryginał przerobionej wiadomości - tutaj)

:-)

"Wady ma 70 proc. oprogramowania, skontrolowanego przez NIK [...] Zaczęła się wiosna i w całym kraju zaroiło się od firm budujących nowe oprogramowanie [...]

Według ustaleń NIK, przystępując do realizacji gigantycznego programu budowy oprogramowania, przemysł IT nie miał przygotowanych procedur, systemu monitorowania jakości robót deweloperskich, ani odpowiednio wyposażonych laboratoriów testowych do badania jakości kodu, wykorzystywanego w pracach tworzenia systemów. W efekcie, do końca 2009 r. nieliczne tylko firmy prowadziły monitoring jakości prac. Nie egzekwowano przekazywania informacji o liczbie i wynikach testów wykonywanych w projektach.

Jaki był efekt tego braku należytego nadzoru nad jakością? Inspektorzy sprawdzili stan 30 spośród 124 inwestycji IT oddanych do użytku od 2008 r. do połowy 2013 r. i ustalili, że "wady i usterki wystąpiły w ponad 70 proc. komponentów sprawdzonych przez NIK". Co gorsza, jedna trzecia tych wad pojawiła się zaraz po wdrożeniu systemu do eksploatacji i trzeba je było natychmiats usuwać. Np. [...] pojawiły się nierówności [...]. Oprogramowania trzeba było rozebrać i ponownie ułożyć. Na [...] dziewięć miesięcy po oddaniu do użytku trzeba było usunąć wierzchnią warstwę interfejsu użytkownika i ułożyć ją na nowo. W aplikacji [...] wady wymagające sfrezowania i ponownego ułożenia wykryto zaś w przeddzień przekazania oprogramowania do użytku."

:-)



niedziela, 12 kwietnia 2015

Dinozaury i piraci, czyli zwinna transformacja

Zapraszam na testy prototypu gry planszonwej "Dinozaury i piraci", pozwalającej na żywo, choć na niby, przeżyć wyzwania ZWINNEJ TRANSFORMACJI.

Wstępne testy prototypu odbędą się w ramach jednej z sesji "Okrągłego stołu" podczas konferencji "RE-Challenge", 15 maja 2015, w Warszawie:


Fabuła gry:

Na wyspie obudził się wulkan! Wkrótce dojdzie do eksplozji! Wyspę zamieszkiwały od milionów lat dinozaury, od niedawna mają tam kryjówkę także piraci, ale swój żaglowiec przycumowali daleko. Piraci i dinozaury rzucają się do ucieczki, najpierw każdy na własną rękę, ale odkrywają, że tylko współpracując ze sobą, mogą dojść do zbawczego okrętu i ewakuować się z wyspy. W jednych miejscach korzystne okazują się waga i wielkość dinozaurów, w innych - zwinność i lekkośc piratów.

Do zobaczenia przy zielonym stoliku, 15 maja!

Po zakończeniu naszych testów, będziemy mogli wysłuchać, jak wymagania do gier zbierają i testują profesjonaliści: opowie nam to kilka godzin później osobiście twórca kultowej gry "Kolejka", Karol Madaj!


piątek, 10 kwietnia 2015

Programowanie w świecie nowych technologii

Trzy podstawowe pytania

Programiści – czy tworzą działające, zgodne z potrzebami klienta aplikacje, czy tylko produkują i kompilują kod źródłowy?

Rozwój technologii – czy to tylko bardziej wypasiona elektronika oraz systemy operacyjne i
języki programowania o coraz dziwaczniejszych nazwach, czy również zmiany metod, procesów, organizacji?

Nowość – dla jednej osoby, dla danej firmy, czy autentyczna nowość?

Co to właściwie jest „programowanie”?


Czy oznacza to tworzenie oprogramowania, a więc złożony proces, obejmujący całą drogę od
analizy wymagań, poprzez projektowanie, pisanie kodu, integrację, testowanie, wdrożenie i
utrzymanie? Czy też programowanie, to samo kodowanie: pisanie kodu źródłowego, kompilowanie, ewentualnie analiza statyczna i testy jednostkowe – czyli to, co zwykle wykonują osoby zwane programistami?

Jeśli programowanie, to pisanie kodu źródłowego na podstawie względnie dokładnej
specyfikacji, wtedy zależność programisty od zmian technologii bywa mniejsza. Wiemy jednak, że w praktyce, na dobre i złe, programiści – chcąc nie chcąc – pełnią wiele funkcji: zbierają wymagania, testują, wdrażają, odpowiadają za utrzymanie. Tak dzieje się czasem z powodu niefrasobliwości kierownictwa, które nie rozumie potrzeby istnienia innych uczestników projektu poza skrzętnymi programistami. Czasem firma i projekt są po prostu bardzo małe. Niekiedy taki stan rzeczy bywa wynikiem źle pojętego wyboru metod zwinnych, „agile”. Wówczas programiści muszą dobrze rozumieć technologię, dla której tworzą kod – jest to niewątpliwe wyzwanie!

Co to właściwie jest „technologia”?


Słysząc słowo „technologia”, zwykle wyobrażamy sobie coś twardego: nową elektronikę, nowe procesory, nowe światłowody, nowe sposoby produkcji tychże, i tak dalej. Jeśli nie elektronika, mechanika ani nie chemia, to ostatecznie nowe aplikacje: systemy operacyjne (np. zaroiło się nam w ostatnich latach od pseudo-nowości w formie plejady androidów, iOS-ów, blackberries’ów, symbianów!), nowe algorytmy, nowe języki programowania. Słowa „technologia” i „technika” są po polsku powszechnie stosowane zamiennie.

Tymczasem angielskie słowo „technology” oznacza coś więcej: także procesy, procedury,
sposoby organizacji. Przy takim rozumieniu technologii, wyzwaniem dla programisty byłyby
również zmiany procesu tworzenia oprogramowania, takie jak, na przykład, przejście od modelu kaskadowego do przyrostowego, wdrożenie RUP, stosowanie formalnych metod modelowania wymagań. Tak, to często bywa dla programistów większym wyzwaniem, niż nowe techniki!

Co znaczy „nowe”?


W jakimś stopniu każde zadanie programisty jest nowe – nie programuje się zwykle ponownie tego, co już działa, lecz realizuje funkcjonalność dotąd nie istniejącą. Po drugie, nowość to pojęcie względne: coś może być nowością dla danej osoby, na przykład język C# dla kogoś znającego Java, albo programowanie aplikacji MacOS dla kogoś, kto wcześniej pracował pod Windows.

Technologia może być nowością w jednej firmie, czy branży, choć gdzie indziej istniała już
wcześniej.

Wreszcie, istnieją też prawdziwe nowości: technologie, które wcześniej nie istniały w ogóle.
Takie technologie są dla programistów największym wyzwaniem: czasem wymagają radykalnej zmiany dawnego podejścia, brak podręczników, brak narzędzi, jest większe ryzyko popełnienia błędów.

Programowanie dla nowych technologii

Nowe technologie biznesu


Większość zmian w oprogramowaniu bierze się z nowych potrzeb biznesowych. To biznes
przychodzi do programistów i prosi „zróbcie to a to, najlepiej na wczoraj”. Stara funkcjonalność na nowych urządzeniach, na przykład mobilnych; nowa funkcjonalność ze starych elementów, na przykład możliwość zeskanowania kodu kreskowego towaru telefonem i sprawdzenie, czy produkt jest naprawdę markowy; wreszcie zupełnie nowa funkcjonalność – na przykład nowe usługi bankowe albo ubezpieczeniowe, dostępne przez Internet.

Tak, realizacja takich nowych technologii biznesowych to główny cel, podstawowe zadanie i
największe wyzwanie dla programistów! Dziś oprogramowanie nie jest, jak 30 lat temu,
dodatkiem do działania firmy czy instytucji, lecz jej motorem! Umiejętność IT, aby szybciej,
skuteczniej i taniej niż konkurencja realizować w niezawodnym, łatwym do modyfikowania
kodzie, zmieniające się jak w kalejdoskopie potrzeby biznesu, jest kluczem do sukcesu firmy, albo… powodem jej klęski, jeśli IT zawiedzie.

Nowe technologie platformy


Pojawienie się nowego procesora, zmiany w systemie operacyjnym, nowe usługi internetowe
(Web services), nowy protokół komunikacyjny, nowy algorytm szyfrowania danych, nowe,
pojemniejsze dyski – czy to wyzwania dla programistów, czy też sprawy dla nich obojętne?

Bywa bardzo różnie! Nowe urządzenie jest wielkim wyzwaniem dla osoby, która pisze sterownik dla tego urządzenia, a sprawą często najzupełniej obojętną dla kogoś, kto tworzy kod wysokiego poziomu. Pod warunkiem…

… pod warunkiem, że oprogramowanie ma dobrą strukturę, realizuje zasady hermetyzacji
(encapsulation), modularyzacji, i ma właściwie zbudowaną hierarchię klas.

Niezależnie od tego, jakiego rodzaju zmiany w technologiach miały, mają i będą miały miejsce, umiejętność radzenia sobie z nimi przez programistów zależy od umiejętności stosowania przez nich dobrego stylu programowania, wyboru właściwych języków i nieulegania pokusie stosowania brzydkich sztuczek (kludge) w pisaniu kodu!

Programowanie jakiego poziomu?


Różne zmiany technologiczne mają różny wpływ na pracę programistów, zależnie od tego, ja
jakim poziomie ich programowanie się odbywa. Programista sterowników sprzętu musi
rozumieć nową technologię i dostosowywać swój kod do jej zmian przy każdej technicznej
nowości, natomiast jest zwykle obojętny na nowe wyzwania biznesowe. Programista aplikacji
WWW być może nie dba (pod warunkiem, wspomnianej w poprzednim akapicie, poprawnie
realizowanej hermetyzacji) o zmiany technologii układów scalonych, dysków i wyświetlaczy, ale za to musi stawić czoła modyfikacjom biznesu, który jego aplikacja realizuje!

Tak więc, podsumowując, rozwój różnych technologii jest – lub nie – trudnym wyzwaniem dla
programistów, zależnie od tego, na jakim poziomie wirtualnej maszyny działają!

Programowanie przy pomocy nowych technologii

Nowe języki programowania


Programista szukający pracy ma czasem wrażenie, że znajomość właściwego języka
programowania jest podstawowym warunkiem powodzenia! Jeśli wśród wymagań wobec
stanowiska, o które programista się ubiega, napisano „znajomość ADA95 | APL | Assembler | AWK | Bash | Basic | C | C# | C++ … Ruby | Smalltalk … Xbase | XHTML”, to nie ma zmiłuj! Bez znajomości tego języka jest się bez szans.

Cóż, wynika to z krótkowzroczności pracodawców, lub wręcz rozpaczliwej ignorancji działów
zajmujących się rekrutacją, nie zdających sobie sprawy z tego, że nowego języka programowania można się doskonale nauczyć w ciągu kilku dni, natomiast opanowanie najlepszych praktyk i zasad inżynierii oprogramowania zajmuje o wiele dłużej! Kiepski programista znający „właściwy” język, będzie wydajniejszy od dobrego programisty, który tego właśnie języka nie zna… przez pierwszy tydzień, a potem role się odwrócą!

Czyli z punktu widzenia interesów własnej kariery, zalecałbym programistom sprostanie
wyzwaniu uczenia się najnowszych, najmodniejszych języków, albo – przeciwnie – opanowaniu jakiegoś archaicznego dialektu, który jest i niemodny, i bardzo potrzebny… jak COBOL w roku 1999!

Natomiast z punktu widzenia faktycznych umiejętności zlecam raczej znajomość kilku języków, co wybitnie ułatwi – w razie potrzeby – szybkie uczenie się kolejnych.

Nie zapominajmy, że języki programowania są dla ludzi, nie dla maszyn – mikroprocesor i tak
dostaje do wykonania sekwencję instrukcji napisanych w kodzie maszyny, a psychologiczne
podstawy, na których opiera się gołosłowne twierdzenia o wyższości jednych języków nad
innymi, są zwykle bardzo wątłe. Nie ma się czym ekscytować!

Nowe paradygmaty programowania


W przeciwieństwie do poszczególnych języków, ważna jest natomiast znajomość różnych
paradygmatów, sposobów podejścia do programowania. O ile przejście między C++, C# i Java nie powinno nastręczać żadnych trudności, o tyle zmiana paradygmatu z asemblera na język strukturalny, z języka strukturalnego na obiektowy, a z każdego z nich – na rekurencyjny, jak Lisp czy Prolog, to już większe wyzwanie. OK – takim wyzwaniom programiści muszą sprostać, tak jak leśniczy nie powinien błądzić w lesie, i nic ponadto. Zresztą, nie wydaje się, aby należało się spodziewać czegoś nowego w tej dziedzinie w najbliższej przyszłości.

Niekiedy, nowa technologia produktu programistycznego pociąga za sobą nowy paradygmat. Na przykład rozszerzająca się technologia tworzenia usług internetowych, wykorzystująca
architekturę SOA, pociąga za sobą pewne nowe sposoby programowania, niezależnie od
używanego języka.

Czy nowe metody to też nowe technologie?


To wprawdzie sprawa do teoretycznej dyskusji (patrz wcześniejszy akapit: Co to właściwie jest „technologia”?), ale nie ulega wątpliwości, że nowości czysto techniczne są dla programistów w praktyce o wiele mniejszymi wyzwaniami, niż stosowanie nowych metod wytwarzania oprogramowania. Dlatego pominięcie tego tematu oznaczałoby zamykanie oczu na to, co najistotniejsze!

Temu wyzwaniu programiści stawiają czoła, ze zmiennym powodzeniem, od ponad 60 lat.
Kiedyś programowanie było zajęciem dla samotnych geniuszy, często lauretaów Nobla z fizyki. Potem stało się zadaniem zespołowym, trochę z pogranicza sztuki, trochę rzemiosła, stopniowo – manufaktury. Rosnąca złożoność przedsięwzięć informatycznych oraz ich efektowne niekiedy niepowodzenia spowodowały, że usiłowano je uporządkować, zbiurokratyzować, uczynić bardziej przewidywalnymi. Z pra-oceanu pra-programowania wyłoniły się nowe, nieznane wcześniej dyscypliny: analiza biznesowa, inżynieria oprogramowania, zarządzanie konfiguracją, zapewnienie jakości, testowanie, utrzymanie. Potem nadeszła kontr-rewolucja „agile”, próba powrotu do pre-biurokratycznych korzeni. Każda z tych zmian wywierała ogromny wpływ na treść i kształt pracy programistów, każdorazowo wyzwaniem było poradzenie sobie w nowej rzeczywistości.

Programowanie, kiedy świat się zmienia

Rozwój technologii oznacza zmiany. Jakim wyzwaniem są dla programistów zmiany?

Jak radzić sobie ze zmiennością


Na pierwszy rzut oka, zmiany, także te wynikające z rozwoju technologii, nie są dla
programistów ani większym, ani mniejszym wyzwaniem, niż dla każdego innego. Zmiany
powodują obawy, poczucie zagrożenia, uaktywniają syndromy „tak robiliśmy zawsze” oraz
„lepiej nie próbować naprawić tego, co nie jest zepsute”. Jednak, zmiany w IT mają też swoją specyfikę, która odróżnia je od zmian w, dajmy na to, hutnictwie. IT ma upodabnie do zmian mody –  niezwykle szybkich i nagłych.

Zmiany oprogramowania, wynikające ze zmiany technologii, łatwo mogą doprowadzić do
chaosu, którego bezwinnymi (czasem, współwinnymi…) ofiarami często stają się programiści i testerzy. Jeśli nie ma dobrze działającego procesu zarządzania zmianami wymagań, programiści o zmianach dowiadują się często chaotycznie i na ostatnią chwilę. Jeśli nie ma dobrego projektu, zmiany wdrażane przez programistów mogą być niespójne. Jeśli nie dokonuje się analizy wpływu (impact analysis), to zdarza się, że realizacja żądanej zmiany wymaga znacznie więcej czasu, niż przewidywano. Tę litanię można by ciągnąć jeszcze długo.

Łatwość modyfikacji

 

Rozwój technologii IT zwykle nie odbywa się skokowo, kwantowym skokiem, lecz drogą
stopniowych, niewielkich zmian. Tak więc wyzwanie dla programistów zwykle nie oznacza, że
wyrzuca się komplet starego oprogramowania i wszystko pisze zupełnie od nowa, lecz że
dokonuje się modyfikacji już istniejących aplikacji i systemów. Dlatego łatwość, na ile
oprogramowanie poddaje się zmianom, tak zwana łatwość utrzymania (maintainability)
decyduje, na ile rozwojowi technologii towarzyszy nieustanna trauma, a na ile może się on
odbywać w miarę bezboleśnie, płynnie.

Niestety, przy projektowaniu systemów i podczas ich realizacji w projektach, ta właściwość pada zbyt często ofiarą krótkowzroczności, chęci osiągnięcia pozornego sukcesu w bieżącym projekcie kosztem… przyszłych pokoleń, jak deficyt budżetowy państwa! W końcu szybciej jest – zacytuję Adama Kolawę, polskiego programistę-miliardera – przyspawać zapasowe koło do osi, niż… mozolnie przykręcać pięć śrub! Zaś kierownik projektu zostanie pochwalony za zakończenie projektu w terminie - nikt nie widzi, że osiągnięce kosztem jakości i łatwości utrzymania. I tak oszczędność wynikająca ze zwykłego niechlujstwa, wynosząca, dajmy na to, 100 K, powoduje wzrost kosztów testowania, wdrożenia i napraw w ostatniej chwili o 1000 K, zaś rozłożone na lata koszty utrzymania mogłyby być może i o 100.000 K mniejsze.

Nie magiczne języki programowania, nie mistyczne – zwinne, ekstremalne – metodyki, nie betonowe normy typu PRINCE-2, ITIL czy COBIT, lecz wyłącznie dobry proces inżynierii oprogramowania, dobre praktyki zapewniają, że programiści będą sobie radzic z wyzwaniami płynącymi z rozwoju technologii bez potrzeby wylewania hektolitrów potu i łez!

RE-Challenge: NOWINY

 

Świetny kurs Pan poprowadził :-)

Dwa miesiące nic nie pisałem na blogu, ojej ;-)

Ale to były intensywne miesiące: przemieszczałem się od krainy wiecznych (niemal) sniegów (Luleå, Szwecja), poprzez krainę wiecznych wiatrów (Göteborg), aż po słoneczny Madryt. Dwa tygodnie spędziłem też we Wrocławiu :-)

Wybaczcie, należę do tzw. starego pokolenia i nie mam ochoty na blogu zamieszczać wszystkich głupotek i mądrości, z któymi się w tym czasie zetknąłem. Ale jedną rzeczą się pochwalę, bo sprawiła mi autnetyczną przyjemność - opinia uczestniczki szkolenia we Wrocławiu:

Świetny kurs Pan poprowadził. Mówi Pan w taki sposób, że chce się słuchać i udaje się nie zasnąć, co w moim przypadku jest nie lada wyczynem :) Szłam na to szkolenie z obawami, że czeka mnie powtórka z rozrywki, czyli coś na kształt "[...] - powrót zombie" czy podobna trauma :(

Jestem bardzo mile zaskoczona i przekonana, że gdyby ktoś z pańską energią, umiejętnością zainteresowania słuchaczy i tłumaczenia prosto rzeczy trudnych prowadził kurs "[...]" to wszyscy bylibyśmy już specjalistami po rozmowie o podwyżkę.

Odczarował Pan trochę testerów w moich oczach, pokazując, że nie muszą być "dziećmi gorszego boga", ale mogą robić rzeczy ważne, potrzebne i ciekawe jak testowanie zabezpieczeń czy rakiet ziemia-powietrze.