Mapowanie narzędzia komputerowego na ludzi i na problem — narzędzie musi być w stanie równie dobrze mapować ludzi jak i sam problem.
W jednym z artykułów poświęconym mechatronice, “Is ‘Engineer Programmer’ An Oxymoron?” (Czy inżynier programista jest pojęciem będącym oksymoronem?), postawiłem pytanie zawarte w tytule, a teraz chciałbym dalej je rozważać. Jestem przekonany, że większość ludzi zgodzi się z tym, iż spora część inżynierów, zarówno młodych jak i starszych, obawia się tradycyjnego kodu — jak C czy Assembly — do takiego stopnia, że przekazują sterowanie komputerem specjaliście od oprogramowania, a bardzo rzadko, jeśli w ogóle, sam program. Z tego wynika, że pojęcie “inżynier programista” jest rzeczywiście oksymoronem! To rodzi pytanie: Co takiego jest w programowaniu komputerowym, co wydaje się być tak nie na miejscu w inżynieryjnym rozwiązywaniu problemu i wprowadzaniu tego rozwiązania, że inżynier woli je zlecić zewnętrznemu programiście komputerowemu, w ogóle nie włączyć go do całego procesu albo nawet zaprojektować skomplikowane rozwiązanie, aby nie musieć tego robić?
Zamiast poszukiwać osób, których można by winić za tę sytuację — a tu trzeba by zacząć przede wszystkim ode mnie samego jako od edukatora w dziedzinie inżynierii — próbowałem dojść do pewnych wniosków i dojść do sedna problemu. Udało mi się porozmawiać z Andy Watchornem, Academic Field Engineer firmy National Instruments w czasie jednej z jego wizyt. On, ja i mój kolega z Marquette, Profesor Phil Voglewede, odbyliśmy na ten temat stymulującą dyskusję. Oto kilka wniosków, które powstały dzięki tej rozmowie.
Inżynierowie rozwiązują problemy, pomagając w ten sposób społeczeństwu. Aby móc rozwiązywać je w sposób skuteczny, inżynierowie wykorzystują narzędzia komputerowe. Człowiek, komputer i dany problem powinni pozostawać w idealnej harmonii w czasie całego procesu rozwiązywania problemu. Idealne narzędzie komputerowe mapuje płynnie topografię obszaru problemowego i doświadczeń zaangażowanych osób. Zarówno doświadczonym, jak i niedoświadczonym inżynierom narzędzie komputerowe oferuje bezcenne poglądy na kwestie umożliwiające rozwiązanie problemu, jeśli jest w stanie jednocześnie i równie dobrze mapować topografię samego problemu oraz sposób, w jaki człowiek rozwiązuje dany problem. A więc, aby narzędzie komputerowe mogło pozostawać równie pożyteczne w czasie całego procesu projektowania, musiałoby tak samo mapować po obu stronach — po stronie problemu i po stronie osoby rozwiązującej ten problem.
Ten prawie bezbłędny proces mapowania jest uniemożliwiony translacją. Przy rozwiązywaniu problemów inżynier rozpoczyna swoja pracę w świecie rzeczywistym, a kończy w świecie fizycznym. Wszelkie translacje, które dokonywane są w tym procesie, mogą sprawić, że ludzie przesuwani są do obszaru znajdującego się daleko od fizycznej/realnej rzeczywistości, w którym większość z nich ma najlepsze intuicje czy poglądy. Na przykład, spłaszczenie problemu fizycznego w słowa tylko dlatego, że końcowy program komputerowy będzie się z nich składał, to właśnie tego typu translacja. Stanowi to niepotrzebne obejście. Przekładanie świata w słowa, lub z jednego języka do innego, zawsze będzie prowadzić do powstania pomyłek i pewnych strat. Minimalizowanie translacyjnych i konceptualnych obejść stanowi rzeczywisty cel. Dlaczego więc kod komputerowy nie może zostać zaprezentowany w sposób graficzny? Graficzne pakiety modelowania, jak np. LabVIEW, Simulink, PSpice i inne, wydają się być bardziej przystępne do celów modelowania i wprowadzania realnych systemów, ponieważ pokazują przepływ energii i informacji wśród prawdziwych komponentów, utrzymując jednocześnie topografię problemu.
Dlaczego więc nie istnieje inżynier programista? Moim zdaniem, wynika to ze sposobu, w jaki takie języki komputerowe mapują (patrz schemat). Chociaż Assembly i C znakomicie mapują w ramach danego problemu, nie są w stanie mapować doświadczeń większości inżynierów, ani młodych ani starych. Biorąc to pod uwagę, inżynier będzie wolał trzymać się z daleka od czegoś, co sprawia, że czuje się niepewnie. Jeśli narzędzie komputerowe może dokładnie zmapować problem dla rozwiązania hardware’owego, a równocześnie umożliwić , aby każda kolejna abstrakcyjna warstwa była usuwana aż do poziomu samego bitu, inżynier będzie w stanie jednocześnie być specjalistą inżynierem i specjalistą od oprogramowania. Jest to narzędzie, które na pewno byłoby używane przez starszego i młodszego inżyniera…… jeśli je znajdziemy.
