TheTarPit

Pair Programming - good intention gone bad

Pair Programming — jedna z podstawowych i jednocześnie najbardziej kontrowersyjnych praktyk stosowanych w XP. Mam wrażenie, że w przeważającej większości znanych mi przypadków to po prostu nie zadziała. Nie twierdzę, że to pomysł do niczego — Pair Programming może działać i może być wydajną techniką (może nie od razu 1+1=3, ale przynajmniej 1+1>2). Jednak równocześnie istnieje mnóstwo powodów, dla których może się okazać absolutną klęską.

Sam pomysł istnienia programistów pracujących w duecie nad jednym kawałkiem kodu oczywiście nie jest niczym nowym. Od dawna głosi się, że four eyes are better than two, np. w kontekście inspekcji oprogramowania. Jednak pomysł taki pociąga za sobą najróżniejsze problemy i myślę, że XP wcale się od nich nie uwalnia. Co więcej, robiąc z programowania w parach sztandarową niemal zasadę, dodatkowo te problemy wyolbrzymia.

Wspomniane kiedyś dwa pierwsze składniki prawdziwej zabawy w software development to polityka i ludzie. Polityka decyduje o tym kto z kim, dlaczego i kiedy współpracuje. Natomiast jak to się odbywa w praktyce i czy w ogóle współpraca ma sens, zależy wyłącznie od ludzi. Ludzie zmuszeni do pracy w parach przez określoną ilość godzin dziennie po prostu tego nie zrobią — muszą sami zechcieć. Tymczasem programiści to artyści (a przynajmniej rzemieślnicy) i jako tacy wytwarzają wokół siebie taki warsztat jaki im pasuje — spędzają w nim przecież długie godziny, niejednokrotnie trudno rozróżnić czy na ciężkiej pracy czy dla przyjemności. Lubią mieć swoje własne kubki, do których nikt im nie zagląda, swoje własne karteczki zapisane niekoniecznie publicznymi notatkami oraz swoje małe przyzwyczajenia i najróżniejsze aktywności dodatkowe, z których nikomu nie chcą i nie muszą się spowiadać. Sam komputer programisty (czy informatyka w ogólności) jest zdecydowanie bardziej narzędziem osobistym niż sprzętem firmowym. Dlatego raczej rzadko pasuje im spędzanie całego dnia pracy ramię w ramię z kimś innym, zwłaszcza jeśli robią to tylko dlatego, że ktoś im kazał.

Co oczywiście nie znaczy, że jestem zwolennikiem separacji poszczególnych członków zespołu. Właśnie dlatego, że są i mają być Zespołem. Jeżeli programista umie pracować wyłącznie wtedy, gdy przez cały dzień nie odezwie się do nikogo, to dla mnie nie jest to dobry pracownik, bez względu na jego faktyczną wydajność. Zresztą wydajność ta staje wtedy pod dużym znakiem zapytania. Nie ma ludzi bez problemów, a inteligentny człowiek zawsze ma jakieś wątpliwości. Jeżeli jakiś zawodnik nigdy niczego z nikim nie konsultuje to wcale nie znaczy, że jest genialny — po prostu podejmuje wiele trudnych decyzji na własne ryzyko, wielokrotnie wydaje mu się, że "tak pewnie będzie dobrze" i wielokrotnie po prostu robi głupoty. Programiści muszą rozmawiać zarówno między sobą jak i z projektantem czy analitykiem, i muszą mieć możliwość to robić w każdym dowolnym momencie, a nie np. na specjalnych cotygodniowych spotkaniach. Dlatego uważam za normalny i zdrowy objaw sytuacje, w których dwie, trzy osoby dyskutują nad jakimś problemem czy choćby gapią się na kawałek kodu na ekranie. Czy to trwa pięć minut czy dwie godziny — nie ważne. Ważne żeby rozwiązać problem, a niejednokrotnie najłatwiej to zrobić wspólnie. Przy okazji jedna osoba czegoś się od drugiej nauczy, a wiedza o danym problemie/kodzie/module się rozprasza i ugruntowuje. Słowem — taka lokalna burza mózgów ma wszelkie zalety PP, ale w przeciwieństwie do zaleceń XP nie jest odgórnie założona, nakazana i nie jest ograniczona czasowo z żadnej strony — jest spontaniczna. I zdecydowanie łatwiej akceptowalna.

Podobne argumenty powtarzają się dosyć czesto, więc można chyba założyć, że nie jestem w tym sposobie myślenia odosobniony. Jeżeli w danym zespole Pair Programming zgodnie z przykazaniami XP działa i jest akceptowaną codzienną techniką, to świetnie. Ale jeżeli nie działa, to nie dlatego, że ktoś, coś lub sama idea jest do kitu, tylko .... po prostu nie tym razem, nie w tym miejscu^[1]. Z powodzeniem można próbować podobnie, a jednak jakoś inaczej...

Komentarze