5 powodów przez które odechciewa się zgłaszania bugów

W swojej pracy programisty często korzystam z produktów innych osób, te jak każde inne oprogramowanie może zawierać błędy. Jako że z reguły używany kod ma współpracować z moim własnym, dla chęci dopięcia wszystkiego na ostatni guzik i niesienia pomocy innym staram się zgłaszać zauważone usterki.

Niestety jak to często w życiu bywa nic nie jest takie proste na jakie wygląda, a czynnik ludzki potrafi czasami wywołać większy ból pewnej części ciała niż pierwotny robak w kodzie źródłowym. Dlatego chciałem się z Wami podzielić swoją osobistą listą top 5 powodów przez które po pewnym czasie odechciewa mi się zgłaszania czegokolwiek.

1. Support guy

Czyli człowiek od wszystkiego, pierwszy na linii frontu niesienia pomocy zdesperowanym użytkownikom. Po opisaniu napotkanego problemu pierwszy mail jaki dostaje to cytat z dokumentacji, FAQ czy inna bezsensowna odpowiedź z reguły nie mająca związku z tematem.

O ile takie zachowanie jest jeszcze zrozumiałe w przypadku np.: Allegro, to w sytuacji w której mamy do czynienia z produktem stricte programistycznym jest to żenujące. Zwykle po wymianie kilku listów pada prośba o przekazanie zgłoszenia "wyżej", do kogoś znającego się na rzeczy.

2. U mnie działa

Zgłaszając buga do systemów służących do śledzenia błędów (jak np.: Trac) mamy to szczęście że czytają to osoby piszące kod (przynajmniej taką mam nadzieję). Niestety i tutaj zdarzają się przypadki że czytający nasze żale traktuje wszystkich z góry i mimo dobrego opisu odtworzenia błędu nie bardzo chce mu się zgłębiać szczegóły, bo przecież u niego działa.

Po części jestem w stanie zrozumieć takie nastawienie, jeśli taka osoba musi dziennie przebrnąć/pozamykać dziesiątki ticketów od osób które wykorzystują system do nie tego co trzeba.

3. It's not a bug, it's a feature

Przechodzimy do grubszego kalibru, o ile wcześniejsze przypadki to ogólnie rzecz biorąc problemy na linii komunikacji między ludzkiej, o tyle teraz mamy do czynienia z twierdzeniem że białe jest czarne - cytując pewnego polityka. Sytuacja w której autor produktu traktuje błąd jako coś czym on nie jest jest beznadziejna, a zwłaszcza gdy od tego zależy kondycja naszego tworu.

4. Jest to na naszej liście TODO

W luźnym tłumaczeniu oznacza to nie mniej nie więcej co: "wiemy że to jest błąd ale występuje tak rzadko (albo tylko u ciebie) że nie chce nam się tracić na to czasu". Spychologia w najczystszej formie oprawiona w ładny, poprawny politycznie język.

5. Spokojnie, nie pali się

Nie oczekuje od nikogo że będzie moim prywatnym niewolnikiem i odpowiadał na zgłoszenia 24/7, jednak czas oczekiwania sięgający 5‑7 dni potrafi poirytować, zwłaszcza gdy odpowiedź jest nierzeczowa lub wymijająca. Wówczas taka wymiana myśli może trwać i miesiącami zanim dojdziemy do konsensusu.

Przykłady z mojego podwórka

A. W serwisie Play24 mamy do czynienia z dwustopniowym uwierzytelnianiem w przypadku wykonywania operacji takich jak zmiana taryfy, aktywacja pakietu, itp - słusznie, grunt to bezpieczeństwo. Jednocześnie numer na który otrzymujemy hasła jednorazowe może być inny niż ten którego dotyczy konto (przydatne gdy mamy dużo numerów). Problem tylko w tym że do zmiany numeru dla haseł SMS nie wymagane jest potwierdzenie na aktualnie zdefiniowany numer. Czyli całe zabezpieczenie nie jest nic warte. Liczę tylko na to że po śmiesznej odpowiedzi jaką dostałem na zgłoszenie w/w usterki poszło to gdzieś dalej i finalnie zostanie/zostało załatane.

B. WC Brands - płatne rozszerzenie do wtyczki WooCommerce dla WordPressa. Błąd dotyczył nieprawidłowego zamknięcia output bufferingu w PHP, który powodował psucie stosu ob jeśli motyw też go stosował. Istna batalia z supportem w której usilnie starano mi udowodnić że jest dobrze i że to ja robię coś źle. Po kilku miesiącach/releasach w końcu naprawili co trzeba. Można? można. Analogiczny błąd zgłaszałem jeszcze w samym WordPressie oraz innym pluginie i tutaj z uśmiechem na ustach przyjęli zgłoszenie.

C. Jeszcze z podwórka WordPressowego, kolejne płatne rozszerzenie o nazwie Visual Composer, chwalące się możliwością integracji z motywem. Zgłoszona spora lista usterek, po roku czasu wracam do kodu, nowa wersja, 90% jak było tak jest i doszły nowe, kolejne zgłoszenie. Najpierw flirt z support guy, potem mieszanie się w zeznaniach a na koniec "mamy to w TODO". Obiecali coś poprawić na nowy rok, ale chyba już nie wierzę w świętego mikołaja.

D. Na koniec pozytywny przykład z 7‑zipem. W którejś alphie występował błąd z nieprawidłową obsługą mechanizmu pakowania z różnych dysków z zachowaniem pełnej ścieżki pliku w archiwum (to wszystko z wiersza poleceń ;)). Ogółem błąd był tak rzadki, że wątpię by ktokolwiek inny z tej funkcjonalności korzystał. Było to parę lat temu i od tego czasu nie było jeszcze stabilnego wydania, ale jeśli się go doczekamy to wiem że wspominany błąd czeka już na mnie naprawiony :).

Podsumowanie

Oczywiście w większości przypadków z sukcesem udaje mi się zgłosić błąd i doczekać jego naprawienia. Nie mniej, od jakiegoś czasu gdy mam to robić odczuwam już dziwny strach pomieszany z niechęcią.

Najzabawniejsze w tym wszystkim jest to, że złe doświadczenia mam większości z produktami które są płatne, gdzie zasadnym jest aby znaleziony błąd był naprawiony - zwłaszcza że nierzadko podaje rozwiązanie na tacy z numerami linii kodu.

A Wam jak często zdarza się zgłaszać błędy w używanym oprogramowaniu? I co finalnie z tego wynika?