Aby lepiej sprostać potrzebom rynku, musimy dokonać fundamentalnych zmian w sposobie nauczania informatyki.
Informatyka musi być centralnym elementem programu nauczania na kierunkach programistycznych. W przeciwnym przypadku będziemy musieli polegać na doświadczeniu indywidualnych osób i podstawowych zasadach, czego efektem będzie powstawanie mniej niezawodnych i bardziej kosztownych systemów. Doskonalenie jakości usług musi iść w parze ze zmianami w sposobie nauczania.
Problem
W wielu miejscach program informatyki na studiach rozmija się z zapotrzebowaniem rynkowym. Rozważmy poniższą rozmową:
Znany profesor informatyki (z dumą w głosie): My nie uczymy programowania, my uczymy informatyki.
Dyrektor firmy: Oni nie mają zielonego pojęcia o programowaniu.
Pod wieloma względami obaj mają rację i to w głębszym sensie niż się na pierwszy rzut oka wydaje. Zadaniem uniwersytetów nie jest tylko „produkowanie” programistów, a rynek pracy nie jest przeznaczony tylko dla „wyrafinowanych myślicieli” i „naukowców”.
Inny profesor informatyki: Nigdy nie programuję.
Inny dyrektor firmy: Nie zatrudniamy absolwentów informatyki, ponieważ łatwiej jest nauczyć fizyka programować, niż studenta informatyki nauczyć fizyki.
Obaj mają trochę racji, ale w idealnym świecie obaj fundamentalnie by się mylili. Błąd profesora polega na tym, że nie można uczyć tego, czego się samemu nie robi (a w wielu przypadkach jest tak, że uczący nigdy nie zajmował się praktycznie tym, czego uczy), a więc i nie rozumie. Natomiast dyrektor ma rację tylko pod warunkiem, że wymagania dotyczące jakości programów będą tak niskie, że nawet fizyk (lub inna osoba bez przygotowania kierunkowego) poradzi sobie z ich napisaniem. Oczywiście nie mówię tu o fizykach, którzy poświęcili mnóstwo czasu i wysiłku na opanowanie także informatyki — jest to moim zdaniem idealne połączenie umiejętności.
Profesor informatyki (o studencie): Przyjął pracę w firmie.
Inny profesor informatyki: Szkoda, a zapowiadał się obiecująco.
To nieporozumienie jest częstym źródłem problemów i znacznie utrudnia ich rozwiązywanie.
Firmy potrzebują absolwentów informatyki do tworzenia oprogramowania (przynajmniej na początku ich karier). Oprogramowanie te jest często częścią istniejącej już od dawna bazy kodu i używane do budowy systemów wbudowanych lub rozproszonych o wysokich wymaganiach dotyczących niezawodności. Jednak wielu absolwentów ma tylko podstawowe wykształcenie i umiejętności w zakresie programowania, które często nie wykracza poza projekty realizowane w ramach hobby. W szczególności niewiele osób wysila się nad zadaniami z programowania i mało kto zadaje sobie trud, aby spojrzeć na nie z szerszej perspektywy, biorąc pod uwagę testowanie, pisanie dokumentacji i to, czy ich kod będzie nadawał się do użytku przez innych. Co więcej, wielu studentów nie potrafi połączyć ze sobą tego, czego nauczyli się na zajęciach z jednego przedmiotu z tym, czego nauczyli się na innym przedmiocie. Przez to często trafiają się nam studenci mający wysokie oceny z algorytmów, struktur danych i inżynierii oprogramowania, którzy na zajęciach z systemów operacyjnych opracowują rozwiązania kompletnie ignorując struktury danych, algorytmy i zasady inżynierii oprogramowania. W wyniku tego powstają niewydajne i trudne w utrzymaniu programistyczne gnioty.
Dla wielu osób „programowanie” to jakaś dziwaczna kombinacja rozmaitych sztuczek i wywoływania bibliotek napisanych przez kogoś innego (w rzeczywistości mają oni tylko mdłe pojęcie o tym, co tak naprawdę się dzieje). Takie pojęcia jak „utrzymanie kodu„ i „jakość kodu” są zazwyczaj kompletnie pomijane albo słabo rozumiane. Firmy często ubolewają nad tym, że trudno znaleźć absolwentów dobrze rozumiejących działanie „systemów” i „potrafiących projektować oprogramowanie”. Taka niestety jest rzeczywistość.
Ale ostatnio mój komputer nie uległ żadnej awarii
Narzekanie na jakość oprogramowania to popularna rozrywka, mimo iż w ciągu ostatniej dekady, podobnie jak i we wcześniejszych latach, jakość ta znacząco się poprawiła. Niestety do tego potrzeba było ogromnego wysiłku i wielkich kosztów. Nauczyliśmy się tworzyć w miarę niezawodne programy z zawodnych części poprzez nawarstwianie kolejnych testów czasu działania i ogólnie testowanie wszystkiego, co się da. Struktura kodu też czasami ulega zmianie, ale nie zawsze na korzyść. Często ta skomplikowana sieć warstw i powiązań nie pozwala dokładnie zrozumieć działania systemu nawet najbardziej kompetentnemu programiście. To źle wróży na przyszłość: nie rozumiemy najważniejszych elementów naszych systemów i nie potrafimy nawet ich ocenić.
Są oczywiście osoby, które oparły się naciskom, aby pisać rozdęte i słabo rozumiane systemy. Możemy im podziękować za to, że nasze skomputeryzowane samoloty nie rozbijają się o ziemię, a poczta dociera do domów na czas. Dzięki ich wysiłkom programowanie jest dojrzałą i wiarygodną dziedziną o solidnych podstawach oraz posługującą się wartościowymi technikami i narzędziami. Niestety osoby takie stanowią mniejszość. Większość programistów myśli w kategoriach dalszego komplikowania systemów.
Także wśród kadry pedagogicznej można znaleźć osoby, które walczą o oddzielenie teorii od praktyki rynkowej. Im również należą się wyrazy uznania. W zasadzie w każdej instytucji edukacyjnej, jaką znam istnieją programy studiów kładące nacisk na praktykę oraz pracują profesorzy, dla których programy te stanowią priorytet. Jednak z szerszej perspektywy sytuacja nie jest optymistyczna — kilka projektów stażów jest dobrych na początek, ale nie mogą one zastąpić kompletnego i wyważonego programu nauczania. Stosowanie nazwy „informatyka” zamiast „inżynieria oprogramowania” czy „IT” może oznaczać nieco odmienne spojrzenie na problem, ale problemy mają jednak to do siebie, że w nowych warunkach wracają, tylko w nieco odmienionej formie.
Przedstawione przeze mnie opisy „rynku„ i „środowiska akademickiego” graniczą z karykaturą, ale każdy kto ma choć trochę wiedzy w tym temacie zapewne zgodzi się ze mną, że jest w tym dużo prawdy. Swoje rozważania prezentuję z punktu widzenia badacza związanego z rynkiem i dyrektora (24 lata spędzone w AT&T Bell Labs, z których siedem jako kierownik działu), który sześć lat przepracował także w środowisku akademickim (na wydziale informatyki technicznej uczelni). Dużo podróżuję, dzięki czemu mam możliwość rozmawiania z przedstawicielami środowisk technicznych i przemysłowych (głównie z USA). Uważam, że rozbieżność między tym, co dostarczają uniwersytety, a tym, czego potrzebuje rynek stanowi zagrożenie zarówno dla informatyki jak i przemysłu komputerowego.
Wiele organizacji, których działalność bazuje na wykorzystaniu komputerów niebezpiecznie obniżyła poziom technicznych umiejętności pracowników.
Środowisko akademickie a rynek
Co można zrobić? Firmy wolą zatrudniać „programistów„, którzy doskonale znają najnowsze narzędzia i techniki, podczas gdy uniwersytety dążą przede wszystkim do kształcenia jak największej liczby jak najlepszych profesorów. Aby był postęp, te dwa cele muszą stać się zbieżne ze sobą. Absolwenci podejmujący pracę w firmach muszą dobrze znać się na programowaniu, a firmy muszą wypracować lepsze mechanizmy pozwalające na adaptację nowych pomysłów, narzędzi i technik. Zatrudnianie dobrego programisty w otoczeniu nastawionym tylko na to, aby nie pozwolić średnio utalentowanym programistom wyrządzić szkód mija się z celem, ponieważ programista ten nie będzie mógł rozwinąć swych umiejętności, aby wnieść cokolwiek nowego i cokolwiek poprawić.
Warto zaznaczyć, że problem dotyczy też skali. Wiele systemów używanych w firmach składa się z milionów wierszy kodu źródłowego, a student najlepszego uniwersytetu może ukończyć studia informatyczne z wyróżnieniem nigdy nie mając do czynienia z programem zawierającym więcej niż 1000 wierszy kodu. We wszystkich większych projektach przemysłowych bierze udział przynajmniej kilka osób, natomiast studenci informatyki zazwyczaj pracują indywidualnie, a wręcz są zniechęcani do pracy zespołowej. Organizacje, które są tego świadome starają się upraszczać narzędzia, techniki, języki i procedury, aby umiejętności programistów miały jak najmniejsze znaczenie. To prowadzi do marnowania talentów i pracy, ponieważ w ten sposób wszystko sprowadza się do najmniejszego wspólnego mianownika.
Firmy żądają wypróbowanych narzędzi i technik, ale jednocześnie ciągle marzą o „srebrnych pociskach”, „przełomach transformacyjnych”, „zabójczych programach” itp. Chcą zatrudniać uniwersalnych programistów o minimalnych umiejętnościach, którymi mają kierować nieliczni „wizjonerzy”, zbyt boscy, aby przejmować się tak przyziemnymi sprawami, jak jakość kodu. To prowadzi do bardzo konserwatywnego podejścia do kwestii wyboru podstawowych narzędzi (takich jak języki programowania i systemy operacyjne) oraz powstawania monokultur (aby zminimalizować koszty szkoleń i wdrożeń). To z kolei jest bodźcem do wzrostu gigantycznych niezgodnych ze sobą infrastruktur: do tworzenia aplikacji potrzebne jest coś więcej, niż tylko podstawowe narzędzia, a producenci aplikacji i platform ciągle próbują szufladkować programistów mimo powszechnej dostępności podstawowych narzędzi. Systemy nagród faworyzują zarówno ambitne plany korporacyjne, jak i krótkoterminowe wyniki. Koszty tego są oszałamiające, a odsetek nieudanych projektów jest powalający.
W obliczu tej rynkowej rzeczywistości — i innych podobnych zniechęcających czynników — uniwersytety zamykają się w sobie i robią to, co potrafią najlepiej: szczegółowo badają zjawiska, którymi można zajmować się w izolacji w małych grupach podobnie myślących osób, formułują solidne podstawy teoretyczne tych zjawisk oraz opracowują doskonałe projekty i techniki rozwiązywania wyidealizowanych problemów. Firmowe narzędzia skonstruowane do pracy z gigantycznymi bazami kodu napisanego w archaicznym stylu kompletnie nie pasują do tego modelu. Podobnie jak w firmach, w środowisku akademickim również stosowane są systemy nagród. To wszystko doskonale pasuje do stałego polepszania kursów inżynierskich w dobrze skonstruowanych przedmiotach akademickich. Zatem dokonania środowiska akademickiego pasują do potrzeb rynkowych, jak wół do karety, przez co firmy muszą ponosić koszty szkoleń i rozwijania wyspecjalizowanych infrastruktur.
Ktoś zawsze może powiedzieć: „gdyby firmy lepiej płaciły programistom, nie byłoby żadnego problemu”. Jest to jakieś rozwiązanie, choć zaoferowanie większych pieniędzy za taką samą pracę niewiele pomoże. Przede wszystkim firmy potrzebują lepszych programistów. Pomysł tworzenia oprogramowania, jak na linii montażowej przez niedouczonych uniwersalnych pracowników jest z gruntu nieprawidłowy i szkodliwy. Powoduje to, że najlepsi ludzie odchodzą oraz zniechęca do przyjścia studentów. Aby przerwać te błędne koło, uniwersytety muszą lepiej dostosować swoje programy nauczania do potrzeb rynkowych, a firmy muszą adaptować narzędzia, techniki i procesy, które pozwolą studentom wykorzystać zdobyte na uniwersytecie umiejętności.
Marzenia o profesjonalizmie
Samo określenie ”informatyka„ (ang. computer science — nauka o komputerach) jest bardzo mylące. Dziedzina ta bowiem wcale nie stawia na pierwszym miejscu komputerów, a poza tym nie jest dyscypliną naukową. Jest to raczej dyscyplina zajmująca się sposobami wykorzystania komputerów oraz pracą i myśleniem, które wymagają wykonywania obliczeń („myślenie algorytmiczne i ilościowe”). Łączy zatem w sobie elementy nauki, matematyki i inżynierii, często z wykorzystaniem komputerów. Dla prawie wszystkich ludzi działających na tym polu, informatyka jest dziedziną stosowaną — „czysta informatyka”, niezwiązana z praktyką, jest sterylna.
Czym różni się informatyk piszący program od specjalisty z innej dziedziny (np. medycyny lub fizyki) piszącego program? Odpowiedź powinna brzmieć: „znajomością podstaw informatyki”. Czym powinny być te „podstawy”? W znacznej części powinna to być wiedza na tematy obecne w standardowym programie nauczania, tj. o algorytmach, strukturach danych, architekturze komputerów, programowaniu (zasadniczo), trochę matematyki (głównie po to, aby nauczyć studenta rozumowania dowodowego i ilościowego) oraz o systemach (takich jak systemy operacyjne i bazy danych). Aby ugruntować swoje wiadomości i nauczyć się rozwiązywać większe problemy, student musi w czasie studiów wziąć udział w kilku projektach grupowych (można to nazwać podstawami inżynierii oprogramowania). Najważniejsze, aby znaleźć złoty środek między teorią a praktyką, ponieważ fundamentami informatyki są zarówno zasady i twierdzenia, jak i praktyczna umiejętność pisania programów.
Te podstawy są oczywiście znacznie bardziej „komputerowe”, niż sama dziedzina informatyki, jako taka. Dlatego każdy, kto nazywa siebie informatykiem powinien mieć jakąś dodatkową specjalizację w obrębie tej dziedziny (np. grafika, sieć, architektura oprogramowania, interakcje człowieka z komputerem, zabezpieczenia). Samo to jednak nie wystarczy. Informatyka jest z natury dziedziną stosowaną i interdyscyplinarną. Dlatego też każdy informatyk powinien mieć przynajmniej podstawową wiedzę z zakresu jakiejś innej dziedziny (np. fizyki, inżynierii medycznej, historii, księgowości czy literatury francuskiej).
Doświadczony pedagog spostrzeże: „Ależ to jest niemożliwe! Mało który student da rady to wszystko opanować w ciągu czterech lat”. I będzie miał rację: to może się źle skończyć. Dlatego sugeruję, aby pierwszym stopniem uprawniającym do tytułu informatyka był magister — uzyskany w ciągu jednolitych studiów, a nie bakałarz z jednym lub dwoma latami uzupełniającymi. Osoby chcące prowadzić badania powinny podjąć studia doktoranckie.
Zapewne wielu profesorów nie zgodzi się ze mną: „Nie mam czasu na pisanie programów!” Uważam, że profesorowie, którzy mają uczyć studentów profesjonalnego tworzenia programów będą jednak musieli znaleźć trochę czasu na programowanie, a zatrudniające ich jednostki powinny znaleźć środki na dodatkowe wynagrodzenie dla nich za ten wysiłek. Podstawowym celem informatyki jako dziedziny jest podnoszenie jakości systemów. Czy chcielibyśmy, aby ktoś kto od lat nie przyjmuje pacjentów uczył zawodu chirurgów? Czy można sobie wyobrazić nauczyciela gry na fortepianie, który nigdy w życiu nie grał? Studia informatyczne powinny dawać studentom coś więcej niż tylko wiedzę książkową. Absolwent powinien umieć wykorzystać swoje umiejętności do budowy kompletnych systemów i dążyć do pisania jak najlepszego kodu także pod względem estetycznym.
Od czasu do czasu używam słowa „profesjonalny„ w różnych formach. Ma ono wiele znaczeń i implikuje pewne założenia. W przypadku medycyny czy inżynierii założeniem tym jest obowiązek posiadania licencji. Jednak sposoby przyznawania licencji w różnych zawodach bywają kontrowersyjne i wywołują wiele emocji. Mimo to musimy zdać sobie sprawę, że od oprogramowania zależy przyszłość naszej cywilizacji. Czy dobrze jest, że w zasadzie każdy może dokonać zmian w krytycznej części kodu tylko dlatego, że tak mu się podoba albo takie są wymagania firmowe? Jeśli tak, to czy również dobrze będzie za 50 lat? Czy dobrze jest, że programy, z których korzystają miliony ludzi są dopuszczone do użytku bez żadnych gwarancji? Sedno problemu tkwi w tym, że profesjonalizm wymuszony przez konieczność zdobycia licencji zależy od posiadania dużej wspólnej wiedzy i wielu narzędzi oraz znajomości technik. Inżynier mający uprawnienia może zaświadczyć, że dany budynek został zbudowany zgodnie z obowiązującymi przepisami i przy użyciu odpowiednich materiałów. W przypadku informatyki (o czym wspominałem wcześniej) nie ma żadnych wytycznych pozwalających ocenić, czy dany program spełnia jakiekolwiek standardy. Obecnie byłyby nawet trudności z wyłonieniem grona osób, które mogłyby sporządzić test na uprawnienia informatyczne (a raczej zestawy testów dla różnych specjalności, takich jak np. medyczna).
Jak można wypełnić tę lukę? Znacznie trudniej jest sporządzić charakterystykę „rynku” i ”potrzeb rynkowych”, niż mówić o środowisku akademickim. Jakby nie było, standardy akademickie są powszechnie znane i niezmienne, podobnie jak stosowane w tym środowisku środki do osiągania celów. Rynek jest natomiast znacznie bardziej zróżnicowany: są firmy duże i małe, komercyjne i niekomercyjne, stosujące wyszukane rozwiązania i szukające prostszych rozwiązań itd. Dlatego też nie mogę tu podać nawet wstępnych zaleceń, jak poprawić sytuację. Mam jednak jedno spostrzeżenie, które jest bezpośrednio z tym związane: wiele organizacji, których działalność bazuje na wykorzystaniu komputerów niebezpiecznie obniżyła poziom technicznych umiejętności pracowników:
Dyrektor firmy: Wykonywanie zadań wymagających wiedzy technicznej przez pracowników firmy ma kluczowe znaczenie dla przetrwania tej firmy.
Podstawami sukcesu każdej firmy są jej pamięć instytucjonalna oraz wypracowane metody rekrutowania i rozwijania nowych talentów. Dlatego też zacieśnienie współpracy z naukowcami zainteresowanymi programowaniem może być korzystne dla obu stron. Kluczową rolę w tym procesie mogą odgrywać wspólnie przeprowadzane badania i nacisk na długotrwałe kształcenie zamiast przeprowadzania krótkich szkoleń.
Podsumowanie
Musimy bardziej się starać. Dopóki nie weźmiemy się do pracy, nasza infrastruktura będzie skrzypieć, nadymać się i pochłaniać coraz więcej zasobów. W końcu coś się zepsuje i skutki tego mogą być katastrofalne (mam tu na myśli internet, bankowość internetową, systemy głosowania elektronicznego oraz sterowanie siecią elektryczną). Przede wszystkim trzeba zbliżyć do siebie rynek i środowisko akademickie, co wymaga zmian po obu stronach. Moim zdaniem należy sporządzić ramowy program nauczania informatyki oraz wzbogacić go o przedmioty specjalizacyjne i aplikacje, a w dalszej perspektywie dążyć do licencjonowania programów, a także wydawania uprawnień tym, którzy je mają tworzyć. Wszystko to można pogodzić z położeniem nacisku na długotrwałą współpracę środowiska akademickiego z przemysłem w celu wyszkolenia znakomitych fachowców.
Prawa autorskie należą do autora.
Communications of the ACM Vol. 53 No. 1, Pages 40-42 10.1145/1629175.1629192