Pracując nad własnym oprogramowaniem lub przystępując do optymalizacji istniejącego kodu, bardzo często stykamy się z jego nadmiarowością. Czasami wynika to z dobrych intencji programisty, który chcąc uczynić oprogramowanie lepszym, rozbudowuje projekt o dodatkowe funkcje, a czasami z niewiedzy, mało optymalnego kodu lub niepotrzebnego kopiowania tego samego kawałka kodu w wielu miejscach.
Im więcej kodu zawiera projekt, tym bardziej z założenia jest on skomplikowany, a każda jego późniejsza rozbudowa jest bardziej czasochłonna. Wpływa to również na wymagania sprzętowe i liczbę potencjalnych błędów w oprogramowaniu (np. strony internetowej). O ile duża ilość kodu wynikająca z wymaganej funkcjonalności oprogramowania i jego specyfikacji jest zrozumiała, o tyle kod, który jest redundantny lub który został napisany ponad określone potrzeby jest już zbędny.
Powielanie kodu jest wygodne i bezpieczne; właśnie dlatego pojawia się w wielu aplikacjach. Jest pozornie wygodne, ponieważ kiedy musimy wykorzystać kawałek kodu z jakiejś funkcji w innym miejscu, po prostu go przeklejamy zamiast odseparować do oddzielnej funkcji, która może być wykorzystana w wielu miejscach. Często też nie chce nam się po prostu szukać czy w kodzie istnieje funkcja, która już realizuje to, czego potrzebujemy, a jeżeli takowa istnieje i została napisana przez kogoś innego, to wychodzimy z założenia, że lepiej jej nie modyfikować, bo jeszcze coś może przestać działać. I tutaj pojawia się pojęcie bezpieczeństwa i obawa, żeby czegoś nie zepsuć.
Zazwyczaj dobrą praktyką jest, aby nie ruszać tego, co działa, o ile nie musimy tego zmodyfikować. Jeżeli przystępujemy tylko do rozbudowy oprogramowania, piszmy kod optymalnie, twórzmy optymalny kod i funkcje, które będzie można później wykorzystać w innych miejscach, ale pod żadnym pozorem nie ruszajmy tego, co działa, choćby nie wiadomo jak nas korciło, żeby to poprawić – nie takie jest nasze zadanie. Jeżeli jednak naszym celem jest optymalizacja lub poprawa jakiegoś błędu w kodzie, który powielono w kilku miejscach, nie powinniśmy korygować tego błędu tyle razy, ile razy został on powielony. Taki kod należy wydzielić do jednej funkcji i dokonać poprawki w jednym miejscu. Wydaje się to oczywiste, ale nie wszyscy tak robią.
Innym czynnikiem wpływającym na nadmiarowość kodu są dobre intencje i ambicje programisty, czyli pisanie funkcji, która nie została uwzględniona nigdzie w specyfikacji. Jest to zazwyczaj domena młodych programistów, którzy chcą się wykazać i wręcz rwą się do pisania kodu, który mógłby się kiedyś przydać lub stanowi furtkę do późniejszego rozwoju oprogramowania. Nie jest on jednak na chwilę tworzenia oprogramowania potrzebny i statystycznie, w większości przypadków prawdopodobnie nie zostanie nigdy wykorzystany. Istnieje powiedzenie, że doświadczonego programistę można odróżnić od swojego mniej doświadczonego kolegi po fachu właśnie po ilości kodu.
