1. Możliwe, że przesadziłem z wyceną
Wycofanie się programisty z wyceny, którą zrobił może oznaczać kilka rzeczy, a każda z nich jest zła… Po pierwsze możliwe, że programista jest leniwy i ją zawyżył. Druga opcja, to niestaranne jej przygotowanie. Trzecia wreszcie to, że programiście takiemu brak odwagi cywilnej i woli skłamać, niż powiedzieć gorzką prawdę.
2. Lepiej tego nie ruszajmy
Powyższe zdanie sygnalizuje przede wszystkim zły stan projektu. Jakaś jego część jest tak krucha, że strach ją zmieniać. Jednak jest to również symptom kiepskiej jakości programisty, bo osoba doświadczona powiedziałaby raczej – modyfikacja tego fragmentu projektu jest ryzykowna – po czym spróbowała sytuację naprawić.
3. To 10 minut roboty
Niewinne, ale jednak łgarstwo. Nawet niewielkie zmiany w kodzie, przy złożoności technologii i narzędzi, jakich używamy w rozwoju oprogramowania nie zajmują 10 minut. Jeśli programista obiecuje takie dziesięciominutowe rozwiązania, to najpewniej składa również inne obiecanki-cacanki.
4. Czysty kod to kwestia gustu
Znany z innych obszarów życia relatywizm – nie ma brzydoty, bo komuś coś się podoba. Cóż – czysty kod jest jak czyste miasto. Kiedy widzimy wybite szyby i opadające tynki; kiedy widzimy bełkotliwe nazwy zmiennych i rozwlekłe metody – wiemy, że jesteśmy w mieście, wiemy, że jesteśmy w kodzie brudnym, upadłym, gnijącym. Nie ma tu miejsca na relatywizm. I nie można bronić swojego niechlujstwa relatywizowaniem.
5. To tak było od zawsze
Konserwatyzm jest może dobry w pewnych dziedzinach życia, ale na pewno nie w rozwoju oprogramowania. Nasza branża premiuje dynamiczne zmiany i jeśli ktoś trzyma się starych rozwiązań bez rzeczowego uzasadnienia, a tylko na podstawie tego, że są stare – nie jest dobrym reprezentantem naszego zawodu.
6. Jest bałagan, ale nie mamy czasu na refaktor
O ile są zawody i branże wymagające działania tu i teraz, jak na przykład bycie strażakiem, o tyle – za wyjątkiem “gaszenia pożarów” na produkcji – rozwój oprogramowania nie jest tą branżą, a programowanie tym zawodem. Jeśli jest bałagan, to znaczy, że struktura kodu, projektu przeszkadza nam w pracy. Jeśli programista doprowadza do takiego stanu, to już jest sygnał alarmowy. Jeśli w dodatku tego stanu nie umie zakończyć – rozmawiając z biznesem, wygospodarowując czas, poświęcając wysiłek na uporządkowanie chaosu – to już oznacza, że jest po prostu bałaganiarzem szukającym wymówek, a nie efektywnym profesjonalistą.
7. Nie było czasu na testy
Jeśli nie było czasu na testy, to po co był czas na pisanie kodu? Kod bez testów jest gorszy niż brak kodu w ogóle, bo działanie szkodliwe jest gorsze od zaniechania działania. Co więcej – jeśli nie było czasu na testy, to najwidoczniej nie został on przez programistę uwzględniony na etapie planowania albo też pojawiły się problemy, które podczas implementacji przemilczał, podejmując bez wiedzy biznesu decyzję o obniżeniu jakości.