Proč stáří softwarové chyby nerozhoduje
Dnes jsem se začetl do příspěvku Davida Barona, jednoho z hlavních vývojářů renderovacího jádra Gecko, na téma stáří softwarových chyb vs. jejich řešení. Asi bych to nepopsal lépe. Základní kámen úrazu je totiž u mnohých uživatelů v tom, že si myslí, že dle stáří softwarové chyby se odvíjí pořadí řešení. U otevřených systémů na správu chyb tak není nouze o komentáře typu “x let stará chyba. Jaktože není vyřešena? To je ostuda!” či “Produkt xyz to již má. Proto to musíme mít také!”.
Problém je v tom, že mnohým uživatelům nic neříká slovo priorita a rozsah. Když to hodně zjednoduším, tak řeknu, že čím více uživatelů něco chce, čím více uživatelů ovlivňuje konkrétní chyba či čím více si vývojáři myslí, že nová funkce bude pro uživatel přínos, tím více má oprava chyby/implementace novinky vyšší prioritu a tím dříve se řeší. Velkou roli zde hraje i již zmíněný rozsah, protože oprava jedné chyby může vzít více času než oprava druhé a to i řádově.
David jako hezký příklad uvádí Bugzillu projektu Mozilla (systém na správu chyba a žádostí o novinky). Projekt Mozilla funguje již více jak 10 let a jedná se o jeden z nejvíce sledovaných otevřených projektů. V Bugzille tak naleznete řadu evidovaných chyb/návrhů na vylepšení starých i několik let. Znamená to, že snad projekt Mozilla neřeší chyby? Kdepak, jen je neřeší dle času zadání, ale dle priority. Jak už to tak bývá, vyřešit nelze vše, na to jednoduše žádný projekt nemá kapacity. Obdobně návrh na novou funkcionalitu, která je pro jednoho důležitá, není zase důležitá pro jiného. Není nouze ani o protichůdné návrhy. Vývojáři jsou pak ti uprostřed, kteří nemohou vyhovět všem. Ostatně kdyby vyhověli, máme možná dnes ve Firefoxu renderování Wordovských dokumentů.
