Legendy informatyki mówią, że w czasach króla Świeczka (tj. gdy dominującymi językami były COBOL, BCPL i Fortran) wydajność programistów mierzono tysiącami linii kodu. Miara ta miała nawet swojską nazwę: KLOC. Ktoś, kto produkował np. 3 KLOC-e dziennie, był trzy razy lepszy od tego, kto produkował 1. Świat był piękny, chciałoby się powiedzieć. Może nawet trochę tęsknię za tymi czasami - pod warunkiem wszakże, że byłbym wówczas menedżerem, a nie programistą.

Dziś jednak rzeczywistość jest dużo bardziej skomplikowana. KLOC przestał być dobrym wyznacznikiem już dawno temu, w szczególności gdy pojawiły się języki deklaratywne i narzędzia typu RAD. Problem jednak pozostał: jak mierzyć wydajność dwóch informatyków siedzących obok siebie. Z książki Peopleware, którą wielokrotnie polecałem na tych łamach, wynika, że wydajności te mogą się różnić o rząd wielkości.

Nadal nie mamy - i pewnie mieć nie będziemy - jednej, prostej miary, która mówiłaby: Kowalski jest 3,6 raza lepszy od Nowaka, nawet jeśli obaj pracują obok siebie, nad podobnymi zadaniami. Proponuję kilka innych miar, które jedni z Państwa mogą potraktować z przymrużeniem oka, a inni - uznać za intelektualną inspirację. Dodam, że dalszy ciąg tego felietonu jest owocem mojej kilkuletniej pracy nad niebanalnymi aplikacjami w roli projektanta, programisty i szefa zespołu informatyków.

Pierwsza miara to KLNC, co jest skrótem od kilo lines not coded. Jest to miara ponownego użycia (reuse). Od pewnego czasu aplikacje w mniejszym stopniu się "pisze", a w większym "komponuje" z gotowych elementów. Swoją karierę zaczynałem od budowy komponentów graficznych dla środowiska Borland C++. Dzisiaj "biłbym po łapach" każdego programistę, który wpadłby na pomysł budowania takich obiektów samemu. Im wyższe KLNC, tym lepszy developer.

Druga miara to BAD, jak bugfixes after deployment, czyli liczba błędów po wdrożeniu rozwiązania. Ta miara nie wymaga chyba szerszego omówienia, bo jest dość oczywista. Wysoki BAD jest bad, jak nietrudno się domyślić. Rozumiem oczywiście, że errare humanum est i jakiś poziom BAD możemy uznać za konsekwencję naszej niedoskonałości. Natomiast nie widzę powodu, dla którego ktokolwiek miałby rezygnować z mierzenia taj wielkości i w imię czego.

Trzecia wielkość to PAC, czyli personal action necessary. Ten parametr to "miara niezastąpioności" programisty. Jeżeli zespół znalazł się w sytuacji, gdy dane zadanie może wykonać dany człowiek i nikt inny, to znaczy, że ta osoba może i dobrze pisze oprogramowanie, ale w ogóle nie dokumentuje, zaś zarządzanie w tym zespole jest pod psem. Im wyższy PAC, tym gorszy menedżer i tym więcej uwagi trzeba poświecić dobrej komunikacji w zespole i wypracowaniu pewnych standardów.

Czwarta wielkość to OSAW, czyli oh shit, another way. Taka miara opisuje sytuację, w której dopiero na etapie programowania okazuje się, że założenia, z którymi przystąpiono do realizacji programu, były kompletnie błędne i w danych realiach technologicznych/czasowych/organizacyjnych (niepotrzebne skreślić) nadają się one wyłącznie do kosza. OSAW większe od jednego dyskwalifikuje przede wszystkim analityka oraz projektanta, o ile była to osoba inna niż programista.

W informatyce znane jest tzw. prawo Gilba, które mówi: Wszystko, co się da zmierzyć, może być zmierzone w sposób lepszy niż niemierzenie tego wcale. Może więc KLNC, BAD, PAC, OSAW czy inne miary nie są akurat tymi, którymi powinni się Państwo posługiwać - ale na pewno są lepsze niż niemierzenie niczego.