Ile płacisz za linię kodu?

Tak, wiem, że “linia kodu” (LoC) to bardzo zła jednostka do mierzenia. Napisano na ten temat setki artykułów i książek. Chciałbym jednak porównać dwa projekty, w których brałem udział w ostatnim czasie i przedyskutować kilka bardzo ciekawych danych.



Projekt nr 1: Tradycyjnie “w jednym biurze”


Pierwszy projekt, w którym brałem udział tworzony był przez grupę programistów w tym samym miejscu. Było ich około 20 (nie liczę managerów, analityków, właścicieli produktów, SCRUM masterów itp.) Projekt dotyczył aukcyjnej strony internetowej z całkiem dużą liczbą odwiedzających (ponad 2 miliony wyświetleń strony na dzień).

W sumie było 200k linii kodu z czego 150k to PHP, 35k to JavaScript, a reszta to CSS, XML i Ruby. Liczę tutaj tylko linie, które nie są puste i nie są komentarzami, użyłem do tego cloc.

Ponieważ projekt był komercyjny, nie mogę podać jego nazwy.



Zespół pracował w jednym biurze w Europie, gdzie wszyscy pracowali “od ósmej do szesnastej”. Mieliśmy zebrania, lunche, pogadanki i mnóstwo innych nieformalnych rozmów. Nad wszystkimi zadaniami panowała JIRA.



Projekt nr 2: Ekstremalnie “rozproszony”


Drugi projekt to open-source’owy produkt Java tworzony przez grupę ok. 15 developerów pracujących w różnych lokalizacjach. W grę nie wchodziły żadne nieformalne pogaduszki. Wszystko omawialiśmy w GitHubie. Codebase był znacznie mniejszy, niż w poprzednim projekcie, bo miał tylko 30k linii kodu, z czego ok. 90% to Java, a raszta XML.




Dojrzałość projektów


Oba projekty były hostowane na Githubie. Oba zespoły tworzyły feature branche nawet do najmniejszych poprawek.

Oba zespoły używały automatyzacji procesu budowania, ciągłej integracji, buildów pre-flight, statycznej analizy kodu i code review. To wskazuje na dojrzałość obu teamów.

Oba projekty spełniły oczekiwania swoich użytkowników. Wspominam o tym, żeby zaznaczyć, że w obu przypadkach powstały wartościowe linie kodu. Zero śmieci i duplikacji.



Pokaż mi pieniądze


W obu projektach pełniłem rolę głównego architekta i miałem wgląd w ich finanse. Oprócz tego miałem też dostęp do repozytoriów Git, więc mogłem prześledzić ile nowych (lub zmienionych) linii wprowadzały oba teamy w okresie, powiedzmy, 3 miesięcy.


A teraz zobaczmy liczby.


Pierwszy projekt płacił dobremu developerowi ok. 50 000 USD rocznie, czyli ok. 5 600 USD miesięcznie, albo 35 USD za godzinę. Drugi projekt (ten tworzony w różnych lokacjach) płacił developerom 20-35 USD za godzinę za wykonane zadania opierając się na jednej z zasad XDSD.

Pierwszy projekt wyprodukował przez trzy miesiące 59k nowych linii kodu i usunął 29k w trakcie zmian w głównej gałęzi, co daje w sumie 88k linii kodu. Do wyprodukowania tego kodu potrzebne było 10 000 godzin ludzkiej pracy (20 programistów, 3 miesiące, 170 godzin pracy w miesiącu) - co równa się około 350k USD. A więc projekt kosztował


3,98 USD za linię kodu


Drugi projekt w takim samym okresie wyprodukował 45k nowych linii kodu, a usunął 9k, co razem daje 54k linii kodu. Aby wykonać tę pracę wydaliśmy tylko 7k USD (średnio 350 godzin pracy na 650 zadań). Zatem projekt kosztował zaledwie


0,13 USD za linię kodu


To oznacza też, że programiści pisali około 150 linii kodu na godzinę i ponad tysiąc dziennie. W książce The Mythical Man-Month mowa jest o 10 liniach na dzień, czyli około 100 razy mniej niż w naszym projekcie.


350k USD vs 7k USD
3,98 USD vs 0,13 USD

Co o tym myślicie?



Jak potwierdzić liczby?


Jeśli jesteście ciekawi, to używam hoc, żeby wyciągnąć liczby z Gita (wszystko wyjaśniam Hits-of-Code Instead of SLoC). Tutaj możesz zweryfikować liczby z drugiego projektu.



Wniosek


Te liczby pokazują, że praca w rozproszonym teamie jest o wiele bardziej efektywna finansowo niż w teamie pracującym w jednym biurze. Pewnie za chwilę powiesz, że linie kodu to nieefektywa metryka. Ale daj spokój, 0,13 USD zamiast 3,98 USD? 30 razy drożej?



Zresztą nie chodzi o metryki, tylko o to, żeby przestać marnować czas pracy i zaoszczędzić mnóstwo pieniędzy.



Możemy to zrobić u siebie?


Oczywiście nie osiągniecie takich samych efektów mówiąc swoim programistom, żeby już nigdy nie przychodzili do biura i pracowali z domu. Nie nie tym polega XDSD. Chodzi raczej o sztywne zasady jakości, których powinien przestrzegać cały team.

Kiedy te zasady zaczną obowiązywać, wydacie 30 razy mniej.


A przy okazji, oto co ludzie mówią o swoich projektach:


Jakie są wasze liczby?