Po pierwsze wskazane jest, by programista uczestniczył w różnych projektach. To powinno wymuszać zmiany narzędzi w zależności od wymagań poszczególnych projektów. Osiągnięciu tego celu służą również - praktykowane w naszej firmie - tzw. post mortem sessions. Polegają na spotkaniu uczestników projektu, którzy wspólnie debatują o tym, co było złe i co należałoby poprawić w przyszłości. Szczegółowo poruszamy również kwestię doboru narzędzi. Można też, jeszcze przed przystąpieniem do projektu, zebrać technicznych guru z całej firmy, którzy zaopiniują wybór narzędzi potrzebnych do wykonania postawionego zadania. By polemizować z guru, trzeba mieć mocne argumenty.

Wreszcie, można wpisać w plan rozwoju pracownika i jego bieżącej pracy ciągłe doszkalanie oraz poszukiwanie nowych możliwości. Jeśli kierownik zwróci się do pracownika: "Słuchaj, tak przy okazji, przyjrzyj się narzędziu X", to na 99% sugestia szefa nie odniesie skutku. Zadziała wtedy, jeśli nauka nowych narzędzi będzie obowiązkiem wpisanym w ścieżkę kariery i co jest najważniejsze, inżynier dostanie czas (wpisany w jego plan zadań) na realizację swoich zamierzeń. Jedno jest pewne, każde działanie wymaga czasu, czas "zerowy" lub wykonanie zadania "pomiędzy" innymi zadaniami jest utopią.

Na ile odległa jest wizja oprogramowania składanego z kawałków - komponentów wielokrot-nego użytku?

Wydaje mi się, że nadal bardzo odległa. Większość aplikacji jest pisana od początku, bo trudno jest znaleźć - nawet na potrzeby nowoczesnych zastosowań internetowych - komponenty, które byłyby naprawdę przydatne twórcom oprogramowania.

Czy Pan, producent oprogramowania, życzyłby sobie upowszechnienia modelu aplikacji z komponentów?

Oczywiście! Przy tej nieprawdopodobnej skali skomplikowania problemów biznesowych nakreślanych przez klientów powstanie rynku gotowych komponentów byłoby dobrodziejstwem dla wszystkich producentów. Po co kolejny raz wyważać drzwi? Sądzę jednak, że idea komponentów zostanie wprowadzona w życie w pierwszej kolejności wewnątrz wielkich korporacji i minie sporo czasu, zanim się upowszechni.

Czy w Motoroli rozważano zastosowanie extreme programming (XP)?

To modny temat, zwłaszcza wśród studentów. Bardziej pociąga ich "extreme", niż "programming". A tak na poważnie, uważam, że do popularyzacji tej koncepcji przyczyniła się praktyka wielu firm programistycznych, które działają absolutnie bez procedur. W extreme programming widzą środek na uwiarygodnienie swojego bałaganiarskiego modelu - klient siada z programistą, mówi czego potrzebuje, a programista przemienia to w kod. Nie jestem zwolennikiem tak rozumianego extreme programming. Sądzę natomiast, że niektóre elementy XP mogą okazać się przydatne właśnie w takich firmach, jak Motorola, dobrze zorganizowanych i hołdującym najlepszym praktykom inżynierskim. Zaczynamy powoli przyglądać się, co możemy wykorzystać z elementów XP.

W Krakowie Motorola zajmuje się m.in. oprogramowaniem do telefonów komórkowych. Kiedy telefon komórkowy będzie potrafił to, co mój laptop?

Proponuję prosty eksperyment - zestawienie najnowszego laptopa z egzemplarzem sprzed pięciu lat. Owszem, widać zmiany, ale te komputery nadal są do siebie podobne. Proszę natomiast odnaleźć stary telefon i położyć go obok nowego. Gabaryty, pamięć, funkcje, każdy detal... Dzieli je przepaść! Tu się dokonała rewolucja.