Znane są przypadki, gdzie dosyć złożone projekty programistyczne, wykonywane początkowo z dużą pieczołowitością, z zachowaniem przynajmniej jakichś pozorów inżynierii programowania, z czasem przeistaczają się niemal we wzorzec złej roboty. Pola danych zaczynają pełnić rolę uniwersalnych kontenerów, gdzie w zależności od potrzeb (i od klienta) wpycha się różne rodzaje informacji, na bazie których buduje się następnie jakieś raporty. Po jakimś czasie zapomina się o tym, znajdując nowe zastosowanie dla tych pól. Wszystko byłoby dobrze, ale wraz z pojawieniem się tej nowej interpretacji, rozjeżdżają się starsze raporty.

Czy to naprawdę jest możliwe, aby tego rodzaju bałagan pojawiał się w produktach, które oferowane są na rynku? Niestety, tak. Geneza takiego stanu rzeczy, której wytłumaczenia nie należy utożsamiać z rozgrzeszeniem, wynika z pośpiechu. Autorzy starając się zaspokoić wychodzące ponad standard żądania kolejnego klienta wyczyniają czasami takie właśnie "cuda". Nie chcąc zmieniać trzonu systemu, robią swojego rodzaju "obejścia" dla konkretnego zastosowania. Najczęściej przyświeca temu celowi zachowanie ujednoliconej struktury danych pośród wszystkich implementacji danego systemu. Pomimo że w początkowym stadium praktyka taka wygląda na tanią i skuteczną, w dłuższej perspektywie okazuje się droga i tragiczna w skutkach. Co gorsza, jest to sytuacja trudno odwracalna.

Nieco lżejszą odmianą takiego bałaganu w inżynierii oprogramowania jest stosowanie nazw pól bazy danych nieodpowiadających ich rzeczywistej roli. To raczej wynika już z niedostatków w fazie analityczno-projektowej i, pomimo że jest mylące, nie wnosi tak dużego prawdopodobieństwa zniekształceń wartości informacyjnej. Niemniej jest uciążliwe podczas tworzenia kodu, a zwłaszcza wtedy, gdy nazwa pola oznacza negację jego właściwej zawartości, co ma nieraz miejsce przy prezentacji wartości logicznych.