Mniej abstrakcji

Prowadziłem pewien projekt, którego celem było utworzenie oprogramowania generującego zbiorczy raport. Dane były pobierane z bazy i dynamicznie, na podstawie wielu uwarunkowań, przedstawiane w syntetycznej formie. Ponieważ raport ten w postaci ostatecznej miał być drukowany według pewnych standardów, osoby odpowiedzialne za akceptację formy i treści musiały okresowo kontrolować przebieg prac. Stąd też dostarczałem im do wglądu wydruk, stosownie do aktualnego zaawansowania prac programistycznych. Szczególnie rozbawiło mnie to, że na każdej wersji kontrolnej decydenci zaznaczali ciągle te same poprawki, podczas gdy ja twierdziłem, że jest dobrze.

Prowadziłem pewien projekt, którego celem było utworzenie oprogramowania generującego zbiorczy raport. Dane były pobierane z bazy i dynamicznie, na podstawie wielu uwarunkowań, przedstawiane w syntetycznej formie. Ponieważ raport ten w postaci ostatecznej miał być drukowany według pewnych standardów, osoby odpowiedzialne za akceptację formy i treści musiały okresowo kontrolować przebieg prac. Stąd też dostarczałem im do wglądu wydruk, stosownie do aktualnego zaawansowania prac programistycznych. Szczególnie rozbawiło mnie to, że na każdej wersji kontrolnej decydenci zaznaczali ciągle te same poprawki, podczas gdy ja twierdziłem, że jest dobrze.

Prace nad tworzeniem raportów zazwyczaj opierają się o ten sam scenariusz - przygotowuje się szablon całości, a następnie udrażnia się poszczególne fragmenty. Najczęściej też prace programistyczne przebiegają w oparciu o testową bazę danych, co nie tyle należy do dobrego tonu, ale jest stosowane ze względów bezpieczeństwa. A w testowej bazie danych najczęściej informacje są składowane wyrywkowo, w zakresie niezbędnym do wykonywanych próbek. Zdarzyć się więc może, że w raporcie nie wszystkie pola będą wypełnione rzetelnymi danymi, zwłaszcza gdy nie są punktem uwagi na bieżącym etapie projektu. Tak też było w moim przypadku. Oddając do kontroli merytorycznej szablon wielostronicowego dokumentu, gdzie batalia rozgrywała się na razie o jakość i zawartość początkowych fragmentów, otrzymywałem zwrot z poprawkami dotyczącymi całości. Gdyby to jednak były uwagi wnoszące cokolwiek do sprawy, ale nie. Chodziło o fikcyjne wartości liczbowe, które pojawiały się na wydruku. Weryfikator za każdym razem przeprawiał moje zera na konkretne liczby. Nie zdziwiło mnie to za pierwszym razem, ale za każdym następnym już tak, zwłaszcza iż wyjaśniłem mu w czym rzecz. Nie na wiele się zdały moje tłumaczenia, w związku z czym wszystko, co wydrukowane, było brane pod uwagę bardzo poważnie i dosłownie. W końcu zacząłem na szablonie zaznaczać jaskrawym mazakiem tylko fragmenty aktualnie testowane, co jednak także nie skutkowało. Kolumny zer zawsze musiały zostać skorygowane.

W końcu więc zlitowałem się nad użytkownikiem i wprowadziłem do testowej bazy danych konkretne wartości - niech człowiek przestanie się wreszcie męczyć z tym poprawianiem zer. Myślicie Państwo, że pomogło? A gdzie tam! Okazało się, że wpisane przeze mnie wartości są zbyt fikcyjne, a więc niezgodne z prawdą oraz wiedzą i przyzwyczajeniami użytkownika. Jak to się mówi: prawda czasu, prawda wydruku.

Wywnioskowałem z tego, że istnieje pewna grupa ludzi, dla których przyswojenie abstrakcyjnej nieco formuły jest drogą nie do przejścia. Różnicowanie elementów stałych od zmiennych, formy od treści, warstwy od podkładu, to w ich przekonaniu zbyt karkołomne i, powiedzieć można, kuglarskie sztuczki umysłowe. Ale nie trzeba popadać w pesymizm. Nawet z takimi ludźmi można się porozumieć, jeśli tylko są chęci i zrozumienie ich opcji pojmowania świata. Jeśli więc ktoś zapyta ile wynosi ten "x" w równaniu "y=ax+b", to nie należy się denerwować, tylko uprzejmie zapytać: "a ile zdaniem szanownego pana miałby wynosić?".

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200