Taka złośliwość rzeczy martwych, znana ze zgoła innych okoliczności - gdy wali się jedna sprawa, to jak za dotknięciem jakiejś czarodziejskiej różdżki otwiera się worek z problemami, które jakby tylko przez miesiące czekały na sprzyjający moment, aby dać nam łupnia. Cóż, można mieć pretensje do programistów, że nie poradzili sobie z testami jakości swego produktu, jednak biorąc pod uwagę czasochłonność tych czynności, a więc i koszty, zdawać sobie należy sprawę, dlaczego tak właśnie się stało. Zwłaszcza jeśli system składa się z N baz danych i M aplikacji z nimi współpracujących w heterogenicznym środowisku.

Natomiast z pewnością powinni dostać po głowie autorzy oprogramowania, którzy tak "frywolnie" zaprojektowali struktury danych, że na przykład pole przeznaczone do przechowywania daty urodzenia stało się od pewnego momentu miejscem pamiętania daty podjęcia pierwszej pracy. O tym od kiedy taka niespodziewana zmiana ról danych nastąpiła, pamiętają starsi użytkownicy systemu. Jak również pamiętają mgliście przesłanki takich decyzji: miało być zrobione najtaniej jak to możliwe, a data urodzenia nikomu już nie była wówczas potrzebna. Programiści, niewiele myśląc, zmienili tylko etykietkę na formatce ekranowej i zainkasowali za tę działalność niewielką kwotę, która jaka by nie była i tak była zbyt duża jak na ten pomysł. Bywały to nierzadkie praktyki radzenia sobie z nieprzystawalnością struktur informacyjnych do aktualnych potrzeb i możliwości.

Pracownicy dziedzinowi korzystający z usług takiego systemu zazwyczaj pamiętają, od jakiego okresu zmienia się interpretacja informacji, więc potrafią sobie z tym poradzić. Jednak nie wiedzą już o tym algorytmy przetwarzające, które informację tę mogą traktować tylko w jeden sposób (zakładając, że w rekordach danych nie wprowadzono datowania, co przy tej jakości rozwiązań zakrawałoby na jakiś paradoks). Na pewno nie należy ufać statystykom produkowanym przez taki system, jak również zaleca się podchodzić do jego wiarygodności informacyjnej raczej sceptycznie. Zakrawa to na ironię, aby znaczenie informacji bardziej zależało od interpretacji przez "starszyznę" pracowników niż od rzeczywistego jej znaczenia.

Na pocieszenie należy dodać, że tego rodzaju "sztuka" programistyczna już dawno odeszła w zapomnienie, co nie znaczy, że z takim przypadkiem przemieszania danych nie możemy się spotkać. Przypomnijmy sobie, co może zdarzyć się w momencie scalania danych lub ich konwersji. Wystarczy, żeby od pewnego momentu w jakimś systemie zaczęto przechowywać jedną datę zamiast innej, aby po latach różnych przeróbek, scaleń i migracji gdzieś zagubiła się istota znaczenia starszych informacji. W polu bazy przechowywana jest data, która jednak ma inne znaczenie dla starszych i nowszych zapisów. Dlaczego więc pielęgnuje się te zaszłości i nie zrobi z tym porządku?

"Twórcze" programowanie

Jeśli zorientujemy się, że w systemie zaczyna panować ład trochę jak na tureckim jarmarku, to oznacza, że zorientowaliśmy się za późno. Dane są na ogół tak wymieszane i w takiej ilości, że jedyną nadzieją jest jakaś automatyczna procedura naprawcza. Użytkownicy, licząc na czarodziejskie możliwości algorytmów, z reguły mają duże nadzieje na poprawę sytuacji. Programiści jednak doskonale wiedzą, że chociaż wiara potrafi góry przenosić, to możliwości algorytmu mają z tym niewiele wspólnego. Automatyczne korygowanie danych jest dobre, gdy mamy do czynienia z klarownymi uwarunkowaniami, w przeciwnym zaś przypadku można sobie napytać niezłej biedy.

Korzystając z przytoczonego wcześniej wątku dwóch różnych znaczeniowo dat utrzymywanych w tym samym polu bazy, należałoby stwierdzić, że najlepiej je od siebie odseparować lub też stare daty wyczyścić, aby nie powodowały dwuznaczności. Rozpatrując różne drogi ratowania sytuacji należałoby rozsądzić dwie kwestie.