Oprogramowanie można parametryzować na wiele sposobów i jak świat światem nigdy nie znajdzie się taki mądry, który wskaże, jak robić to najlepiej i jednocześnie uniwersalnie. Każdy projektant ustanawia własne reguły, decydując subiektywnie, co może podlegać ingerencji użytkownika, a co powinno być przed nim ukryte. Osobiście jestem zwolennikiem pewnego pluralizmu w tym względzie, oddając w ręce użytkowników panowanie nad tymi składnikami ustawień systemu, na których manipulacja nie odbije się na jakości funkcjonalnej, a szczególnie na wydajności.

Zezwalam więc np. na zmianę kolorystyki pulpitu, bo przecież gusta w tym względzie są odmienne i moje wstępne ustawienia nie muszą komukolwiek odpowiadać. Daję też dostęp do wszelkich tabel o charakterze słownikowym, zawężając co najwyżej uprawnienia do pewnej grupy użytkowników uprzywilejowanych. W żadnym razie nie udostępniam parametrów technicznych związanych z regułami przetwarzania, bo cóż operatorzy systemu mogą o tym wiedzieć. Co najwyżej mogliby tylko nabroić. Tak więc parametry, takie jak czas oczekiwania na zwolnienie zablokowanych zasobów przez inną transakcję lub liczbę powtórzeń akcji po wystąpieniu błędu zaszywam w zmiennych, do których dostęp jest tylko na poziomie kodu źródłowego.

Są jednak ortodoksi wśród programistów, którzy gros treści parametrycznej ukrywają głęboko, czyniąc ją niedostępną dla użytkownika. Wychodzą chyba z założenia, że klient może regulować przepływ wody w kranie lub gotówki na koncie, a nie ustawienia oprogramowania. Żeby to jednak tylko o ustawienia chodziło. Zdarza się, że nie ma dostępu do tabel, w których przechowywane są dane definicyjne. Aby dodać nowy dział w firmie lub nowy symbol "czegoś tam", trzeba dłubać w tabelach bez pośrednictwa jakiegokolwiek interfejsu. Oczywiście, taka struktura oprogramowania nie wynika z ortodoksyjności ich twórców, jak to wcześniej nazwałem, ale ze zwyczajnego lenistwa, brakoróbstwa, niedojrzałości informatycznej (i chyba wszelkiej innej). Podejrzewam też, że kryje się za tym coś jeszcze, a mianowicie chęć stałego uzależnienia klienta od autora rozwiązania, który wie, co i jak zmienić, gdy trzeba dodać nowy dział, symbol czy cokolwiek innego. Dobrze, że chociaż pozostałe dane można wprowadzać bez niczyjej pomocy, ale tego rzeczywiście inaczej nie da się zrobić.

Aż wierzyć się nie chce, że w dzisiejszych czasach, kiedy to technologia informatyczna powinna być dobrze znana wszystkim decydentom, znaleźć można sporą grupę klientów "jeleni", którzy dają się nabrać. Tanie chwyty, w tym ładna szata graficzna, ciągle robią wrażenie i dają się na tę wędkę złapać ci, którzy zakup oprogramowania utożsamiają z handlem pietruszką, gdzie wnikliwość obserwacji kończy się na powłoce. Potem jest tylko płacz i zgrzytanie zębów, bo zbyt często trzeba płacić autorowi za błahe zmiany danych definicyjnych.

Nie zaglądam nikomu do portfela, ale taki sposób naciągania wzbudza we mnie szczególną odrazę. Myślę, że stosowanie zasady "klient głupi, to kupi" ma także pewne granice przyzwoitości. Niewiedza klienta nie może być wykorzystywana bezgranicznie, podobnie jak nie powinno się w celu uzyskania przewagi bezwzględnie nadużywać innych ludzkich ułomności. Zważywszy na aspekt etyczny całej sprawy, jak również na podstawowe kryteria jakości tego rodzaju oprogramowania, osobiście uważam, że jego twórcy są niegodni zaliczania ich do grona informatyków.