Cieknąca abstrakcja na spotkaniach projektowych

Programiści nie potrafią rozmawiać o projektach.
I Ty pewnie od razu powiesz „Hola hola! Przecież codziennie rozmawiamy o projekcie!”.
Ja wtedy odpowiem „Nie. My codziennie rozmawiamy o kodzie”.

Szybko zapominamy

A jeżeli już mowa o rozmawianiu o kodzie, to jednym z tematów poruszanych wśród programistów jest problem wyciekającej abstrakcji w naszym kodzie. Jeżeli jesteśmy w miarę ogarnięci i zależy nam na jakości, to staramy się tak budować nasz projekt, żeby warstwy wyżej nie musiały wiedzieć i nie wiedziały o szczegółach z warstw niższych. I tą koncepcję raczej większość z nas rozumie. Bo wtedy dużo prościej nam się taki kod czyta i modyfikuje.
W takim razie dlaczego, kiedy dochodzi do jakiegokolwiek spotkania projektowego, to nagle o problemie cieknącej abstrakcji zapominamy? Nie przeszkadza nam, że podczas dyskusji o ficzerze i jego zachowaniach, nagle zaczniemy wspominać, że trzeba będzie zmienić jakąś metodę w kodzie, albo dodać flagę w bazie danych?

Sprowadzamy dyskusję do poziomu 100% technicznego, w dodatku praktycznie zawsze nacechowanego negatywnie, a potem narzekamy, że nie dostaliśmy odpowiedzi stricte technicznej. Mimo, że od początku było wiadomo, że po drugiej stronie naszym rozmówcą jest osoba, która skupiona jest na wartości biznesowej, analizie funkcjonalnej i użytkownikach.

Mentalna implementacja

Wchodząc, podczas rozmowy związanej z wymaganiami, w szczegóły techniczne, nie dość, że wnosimy niepotrzebne informacje, to w dodatku utrudniamy dojście do poprawnego rozwiązania i niepotrzebnie zabieramy czas na coś co w tym momencie nic nie wniesie. Od razu w trakcie rozmowy zaczynamy mentalną implementację, mimo, że być może ostateczną konkluzją rozmowy byłoby zupełnie inne, nowe rozwiązanie, albo rozmówcy zaproponują pośrednie rozwiązanie, które można będzie bardzo prosto zaimplementować. W ten sposób wprowadzamy kolejny poziom skomplikowania do tematu. Tak jakbyśmy w trakcie rozmowy o strukturze API jednocześnie w kółko pytali czy metoda do zapisu encji powinna być wyżej czy niżej w pliku i czy ma się nazywać A czy B. To nie jest temat na teraz. Mówimy na innym poziomie i tam zostańmy.

Szczerze mówiąc sam mam czasami ochotę powiedzieć, że może już wystarczy, kiedy kolejny raz spotkanie biznesowo-techniczne przeradza się w tyradę o konieczności refactoringu, ilości zmian w kodzie i bibliotekach, które trzeba będzie użyć albo zmienić.
A miejscem na takie dyskusje będzie spotkanie wewnątrz zespołu programistów, albo czat wewnętrzny, albo komentarze pod zadaniem, albo tej dyskusji w ogóle nie będzie, bo na koniec dowiemy się o jakimś szczególne, który upraszcza sprawę.

Bliżej problemu

Nie zmieniam swojego zdania, że programiści powinni być bliżej biznesu, bliżej wymagań i bliżej wiedzy domenowej. Przynajmniej ci, którzy jakkolwiek mogą się wypowiadać na temat struktury projektu (szkoda, że nie zawsze jest to cały zespół). Zrozumienie podstawowych założeń co do aplikacji, pozwala nam dostarczać rozwiązania, które te założenia spełniają.
Tylko właśnie – dostarczać rozwiązania i rozumieć założenia. Przed tym bronimy się bardzo mocno. Jeżeli założenia, wymagania i problem biznesowy nie pasują do tego co już napisaliśmy w kodzie, albo co wymyśliliśmy w trakcie spotkania, to odrzucamy ich zasadność i zaczynamy natychmiast komfortową i bezpieczną dla nas dyskusję techniczną, która ma chyba wywołać w rozmówcach poczucie, że próbuje zrobić coś praktycznie niemożliwego.

A ścieżka powinna, moim zdaniem, wyglądać tak, że spotykamy się z osobami od domeny, słuchamy czego potrzebują, dowiadujemy się szczegółów, np. kiedy coś ma się zadziać, czy taka akcja ma być możliwa, jakie mamy ograniczenia, np. co do czasu odpowiedzi, lub co powinno się stać jeśli pojawi się dany problem. Odpowiadamy na pytania, które się pojawią i sami zadajemy kolejne, żeby lepiej zrozumieć temat. Mówimy, że wrócimy z wyceną, albo dodatkowymi pytaniami, omawiamy techniczne aspekty wewnętrznie i wracamy z odpowiedzią kiedy to może być gotowe, albo jakie kompromisy proponujemy, bo np. dany element będzie bardzo złożony, a wydaje nam się drugorzędny w tym momencie.
Bo teraz przypomnij sobie jakiekolwiek spotkanie, gdzie omawialiście tematy projektowe, a nagle strona „biznesowa” zaczęła sobie dyskusje na temat tego jak potem będą musieli z tej waszej aplikacji coś wyciągać, przenosić do innego programu, a na koniec jest taki Janek, który to musi zawieźć do urzędu i trzeba mu przypominać, żeby faktury za bilet autobusowy brał. Było to, albo byłoby to męczące, prawda? To tak samo to wygląda jeśli zaczynamy rozmowę o implementacji na tym samym spotkaniu.

W dodatku prawda jest taka, że jeżeli jakiekolwiek wymaganie biznesowe jest zbyt złożone technicznie, albo ciężkie w implementacji, to nierzadko znaczy, że zespół techniczny zawiódł i zabetonował kod, albo zespół techniczny jest niedopasowany do problemu, który jest rozwiązywany.

Zadanie domowe

Jeżeli masz ten komfort, że możesz bezpośrednio uczestniczyć w spotkaniach związanych z omawianiem funkcjonalności i są tam osoby niezwiązane z pisaniem kodu, to mam dla Ciebie zadanie:
Spróbuj przez całe spotkanie nie zrobić żadnego odniesienia do kodu i implementacji. Przynajmniej dopóki nikt o to wprost nie zapyta. Nawet jeżeli będzie Cię skręcało w środku, żeby wspomnieć jakąś klasę, w której trzeba dodać metodę i tabelkę, która wymaga zmiany. Zamiast tego ogranicz się do stwierdzeń, że będzie to rozszerzenie istniejącej implementacji, albo budowa całkowicie nowego modułu. Niech to będzie maksymalnie niski poziom, na jaki zejdziesz.
A potem zapytaj sam siebie, czy spotkanie przebiegło sprawnie i czy faktycznie niewspomnienie o szczegółach implementacji przeszkodziło w dojściu do wartościowych konkluzji.

Bo może się okazać, że spotkanie przebiegło ostatecznie dużo sprawniej, spokojniej i równie wartościowo pod względem końcowych wniosków względem tego, jakbyśmy zalali je wyciekającą abstrakcją.