Przyszłość testowania oprogramowania

Wkrótce w czasopiśmie "Professional Tester" ukaże się artykuł Bogdana Berezy pod tytułem "The Futurology of Software Testing".

 

Prenumerata jest darmowa, więc warto mieć dostęp do tego najstarszego w Europie pisma dotyczącego testowania oprogramowania.

A jaka to będzie przyszłość, zdaniem autora artykułu?

The Futurology of Software Testing [fragmenty]

[...]

So, let the show begin! I have chosen four crystal balls, each looking into a different possible future.

[...]

It happens to me that I teach an [...] ISTQB course  from Monday to Wednesday, and a BPM or BPMN course on Thursday and Friday. Then an abyss of realisation opens in front of me – why, for God’s sake, neither ISTQB nor PRINCE 2, nor PMI, nor ITIL, uses BPMN diagrams to describe their “fundamental(istic) processeses”, but relies on logorrhea instead? [...]

[...]

Testing has developed and grown very, very much indeed during the last 20 years, but alas the development has gone in the direction of what I called test hacking rather than in the direction of quality thinking on all levels. Testing as profession has become the domain of nimble-fingered test execution tools’ programmers, with really great ability to automate anything. However, testing as a general approach, [...] has not developed at all. On business analysis level, and on requirements engineering level, testing is still in its infancy, with naïve, stone age gut-feeling approach dominant.

[...]
Sometimes, while explaining the intricacies of 2-switch coverage in state transition testing to some poor victims of HR departments’ ISTQB obsession, I get a very good question: “how does the choice between 1-switch and 2-switch coverage translate into customer satisfaction?”.
Needless to say, my answer is “it depends” [...].

[...]
When everything changes, nothing changes

In the summer of 1628, the captain responsible for supervising construction of the ship, Söfring Hansson, arranged for the ship's stability to be demonstrated […]. Thirty men ran back and forth across the upper deck to start the ship rolling, but the admiral stopped the test after they had made only three trips, as he feared the ship would capsize. […] Fleming remarked that he wished the king – who had been sending a steady stream of letters insisting that the ship put to sea as soon as possible - were at home.

 

Newsletter 2/2016

Link do Newsletter'a

Zapisy na semestr jesienny wrzesień - grudzień 2016 już ruszyły.     W polskiej branży IT nagminnie mylone są ze sobą zawody i zadania informatyka, programisty, technika instalatora, inżyniera oprogramowania, projektanta systemów, a nawet specjalisty w dziedzinie, dla której tworzone jest dane oprogramowanie. To jakby mieszać kompetencje sprzedawcy samochodów z umiejętnościami budowniczego, który zbudował sklep z samochodami >> więcej Według The Standish Group Chaos Report 2015, główną przyczyną niepowodzeń projektów IT są niedostatki analizy biznesowej, inżynierii wymagań oraz organizacji i współpracy. Od wielu lat, w Szwecji funkcjonuje system yrkeshögskolor, czyli "zawodowych szkół wyższych". Programy nauczania w yrkeshögskolor tworzone są w ścisłej współpracy z przedstawicielami gospodarki, zgodnie z rzeczywistymi potrzebami firm, na czym korzystają oczywiście firmy, ale najbardziej absolwenci, których ponad 85% otrzymuje pracę zaraz po ukończeniu szkoły. >> więcej Czy wobec tego trzeba koniecznie zatrudniać nowych pracowników? Jak wiadomo, koszty rekrutacji, a zwłaszcza koszty nieudanej rekrutacji, są ogromne... >> więcej Jesteśmy dla Ciebie, jeśli albo pracujesz już od wielu lat, albo właśnie skończyłeś studia, albo szkołę średnią... i dowiedziałeś się, że w Twojej dziedzinie nie ma pracy. >> więcej

Potrzebni są technicy i administratorzy

W polskiej branży IT nagminnie mylone są ze sobą zawody i zadania informatyka, programisty, technika instalatora, inżyniera oprogramowania, projektanta systemów, a nawet specjalisty w dziedzinie, dla której tworzone jest dane oprogramowanie. To jakby mieszać kompetencje sprzedawcy samochodów z umiejętnościami budowniczego, który zbudował sklep z samochodami, architekta samochodowych salonów sprzedaży, a nawet kierowcy – bo przecież wszyscy „mają coś wspólnego z motoryzacją”.

Skutki tych nieporozumień widać gołym okiem. W większości ogłoszeń o pracy dla informatyków wymaga się od kandydatów – zupełnie bez potrzeby – wyższego wykształcenia. Programista aplikacji mobilnych, znający język programowania Java oraz system operacyjny Android, ma z tytułu inżyniera albo magistra inżyniera tyle korzyści, ile murarz zbrojarz z dyplomu inżyniera budownictwa, czyli zero.

Nie potrzeba tytułu magistra, aby być administratorem systemów, budować witryny www czy wykonywać standardowe prace przy obsłudze i budowaniu systemów IT. Powierzanie osobom po cztero- lub pięcioletnich studiach zadań, do których wystarczy nauka roczna czy dwuletnia, to ogromne marnotrawstwo.

Wśród informatyków, którzy naprawdę mają ambicje pracy w charakterze informatyków inżynierów, a nie techników, rodzi to frustracje. „Czy po to uczyłem się przez cztery lata informatyki, żebym teraz miał pisać trochę kodu w Phytonie albo budować witryny w WordPress?” – narzekają absolwenci wyższych studiów.

 

MeHow89 • 

Bardzo trafne spostrzeżenia. Większa rzesza pracodawców jak i układających plany edukacji w Polsce powinna się z tym artykułem zapoznać. Dzięki za ten artykuł!

Co powinni umieć fachowcy IT?

Pracodawcy nie bardzo wiedzą, czego naprawdę potrzebują, więc na wszelki wypadek domagają się od pracowników zarówno ogólnego, wyższego wykształcenia informatycznego, jak i szczegółowych, drobiazgowych umiejętności technicznych. To powoduje, że przedmioty informatyczne lub z zakresu inżynierii oprogramowania nie są wśród studentów zbyt popularne. Zgodnie z preferencjami pracodawców, cenione są bardziej kursy modnych i szeroko stosowanych technologii niż wiedza ogólna i teoretyczna.

Trzeba jednak pamiętać, że IT nie jest tym samym co informatyka. IT to przede wszystkim umiejętność zastosowania rozwiązań informatycznych w biznesie, dziedzina interdyscyplinarna.

Tak naprawdę fachowcom IT potrzebne są dwa rodzaje umiejętności: te czysto techniczne oraz szersze, obejmujące jak największy zakres inżynierii oprogramowania. Z punktu widzenia potrzeb przemysłu IT to są odmienne rodzaje wiedzy, inne umiejętności, tak jak w budownictwie potrzebni są architekci, projektanci, inżynierowie różnych typów, technicy, fachowi robotnicy.

Technicy IT nie potrzebują wyższych studiów – to przesąd z czasów, kiedy informatyka nie była jeszcze masowym przemysłem IT. Na razie nasi pracodawcy tego nie wiedzą i dlatego studenci muszą pozyskiwać te detaliczne, modne w danej chwili certyfikaty, „łapać” popularne technologie, bo inaczej nie dostaną pierwszej pracy.

Technicy IT zwiększają wydajność firm

Odczuwany i deklarowany przez branżę IT brak fachowców można znacznie złagodzić, zatrudniając do wielu prac techników IT, z jedno- dwuletnim wykształceniem policealnym, zamiast magistrów po cztero- pięcioletnich studiach. Pozwoliłoby to także uzyskać skok jakości i wydajności w wielu obszarach IT, bo inżynierowie oprogramowania, zamiast programować, konfigurować systemy albo robić kopie zapasowe, zajęliby się udoskonalaniem procedur, projektowaniem architektury, inżynierią wymagań czy najlepszymi sposobami zapewnienia jakości.

Skąd brać techników IT?

W Polsce, jeśli chodzi o kształcenie techników IT, oferta szkól policealnych jest uboga i mało konkretna. Zawód zwany przez wiele szkół policealnych obiecująco „technikiem informatykiem” daje wiedzę szeroką, ale zbyt powierzchowną. Poza tym jest trochę kursów z zakresu grafiki komputerowej i tworzenia witryn www, ale przecież to jedynie maleńka cząstka tego, co naprawdę potrzebne jest w przemyśle IT.

Brać przykład ze Szwecji

Obecnie gospodarka szwedzka jest bardziej intensywna technologicznie i bardziej zorientowana na eksport niż polska. Obserwując jej dzisiejsze potrzeby, można z dużym prawdopodobieństwem przewidzieć, jakie za kilka lat będą potrzeby naszej gospodarki.

Przełożenie potrzeb szwedzkiej gospodarki na funkcjonowanie systemu edukacji mogłem obserwować osobiście. Kilkakrotnie w latach 2011–2014 brałem udział w tworzeniu i realizowaniu programów dla szwedzkich szkół policealnych. W szkole „Nackademin” (nackademin.se ) współrealizowałem półtoraroczny kurs dla testerów oprogramowania oraz dwuletni kurs dla inżynierów wymagań (analityków). W Polsce ten ostatni kierunek uwzględnia program studiów magisterskich tylko jednej uczelni (!). 

 Dlatego u nas, z konieczności, wymaganiami zajmują się – lepiej lub gorzej (zwykle gorzej) – kierownicy projektów, analitycy biznesowi, programiści, a niekiedy nawet… testerzy. A w Szwecji – dwuletnie studia policealne! I trzeba dodać, ze w zeszłym roku 85% absolwentów tego kierunku znalazło zatrudnienie jeszcze w czasie trwania nauki. Czyli szwedzki przemysł IT czekał na nich z otwartymi ramionami.

Z kolei w nowo powstałej szkole „Agile Academy” (agileacademy.se), uczestniczyłem w tworzeniu pierwszego w Europie systemu rocznych kursów dla osób – nie programistów – mających w projektach prowadzonych metodykami agile pełnić role testerów, właścicieli produktów i scrum masterów.

Więcej na ten temat: http://uniwersytet-otwarty.edu.pl/szwecja.html

O poziomie edukacji techników z zakresu IT w Szwecji można się przekonać, korzystając z wyszukiwarki kursów IT w szkołach policealnych (www.yhguiden.se). W samym tylko rejonie sztokholmskim znajdziemy 43 (tak, czterdzieści trzy!) specjalności. Dzięki temu młodzi ludzie znajdują pracę w IT, nie będąc zmuszani do inwestowania w kosztowne i długotrwałe studia magisterskie (mogą je wybrać później), a przemysł IT dostaje szybko pracowników, których potrzebuje. Wysokie wymagania jakościowe wobec szkół zmniejszają ryzyko, że takimi szkoleniami zajmą się osoby i firmy niekompetentne.

Na marginesie: IT tworzyli geniusze

W początkach IT – mam na myśli lata 40. i 50. zeszłego wieku – tworzenie programów było rodzajem rzemiosła, tyle że z powodu swego zawiłego i matematycznego charakteru oraz ekskluzywności branży rzemieślnikami byli wybitni matematycy, fizycy, inżynierowie. Inteligencja i wysokie kwalifikacje ogólne tych rzemieślników gwarantowały, że radzili sobie dobrze nawet wtedy, gdy brakowało im metod i procedur. Umieli je stwarzać sobie na bieżąco, w miarę potrzeby.
Informatyka zmieniła się od tego czasu z dyscypliny akademickiej oraz rozrywki nielicznych geniuszy matematycznych w powszechny przemysł informatyczny, którego wielomilionowa armia pracowników tworzy i współtworzy produkty wykorzystywane przez wielomiliardową populację mieszkańców Ziemi.

Tylu geniuszy nie ma na świecie, więc programy muszą pisać, konfigurować, utrzymywać i budować zwykli śmiertelnicy. Muszą, co jeszcze trudniejsze, robić to i szybko, i skutecznie, i niezawodnie. Nawet geniusze współczesnego IT nie są już geniuszami informatyki ani matematyki, lecz wzornictwa (np. Steve Jobs), świetnego marketingu niezbyt oryginalnych pomysłów (np. Zuckerberg) albo projektowania pod kątem potrzeb klienta (twórcy Google).

Mapa świata Uniwersytetu Otwartego

Historia sukcesu - Agile Academy!

Idea Uniwersytetu Otwartego powstała w dużym stopniu z inspiracji szwedzkiej Agile Academy, z którą blisko współpracowaliśmy przez ponad dwa lata.

Zobaczmy, jak miewają się dzisiaj jej absolwenci z lat 2013-2015! Gdzie pracują, w jakich rolach?

(więcej informacji na: https://www.linkedin.com/edu/alumni?name=Agile+Academy)

Jeśli chcesz z nimi porozmawiać, zapytać o doświadczenia i co sądzą na temat idei "Agile Academy" - możesz to zrobić przez LinkedIn!

Najprościej to zrobić wprost na naszej stronie: http://uniwersytet-otwarty.edu.pl/szwecja.html

Powodzenia! Za trrzy dni uruchomimy zapisy :)

Programowanie w świecie nowych technologii

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 samo 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 świadomego wyboru metod zwinnych, „agile” lub podejścia "DevOps". Wówczas programiści muszą dobrze rozumieć dziedzinę, 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, a upodabnia do zmian mody – są niezwykle szybkie i nagłe.

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 nie oznacza zwykle, ż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ć 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, niestety nieżyjącego, 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.