W dniach 3-4 października miałem okazję uczestniczyć w Global Software Architecture Summit, którego tegoroczna edycja poświęcona była metrykom.
Jest to wydarzenie, które koncentruje się na szeroko pojętej architekturze oprogramowania. Metryki architektury oprogramowania są trudne do zdefiniowania, a jeszcze trudniejsze do obiektywnej oceny. Dobre metryki mogą zmniejszyć koszty naprawiania błędów, zanim trafią one do produktów.
Dzień 1: zwiedzanie miasta przed konferencją
Razem z Sebastianem Dąbkowskim wylecieliśmy rano z Warszawy i zostawiliśmy za sobą typową polską jesień i pogodę - wiatr, deszcz i ledwie 10 stopni. Po wylądowaniu w Barcelonie pogoda całkowicie nas zaskoczyła - 27 stopni! Dodatkowym plusem było to, że konferencja zaczynała się dopiero następnego dnia, więc mieliśmy prawie cały dzień na zwiedzanie miasta.
Dzień 2: testowanie architektury, metryki i skuteczne przywództwo techniczne
Pobudka, szybkie śniadanie i zaczynamy. Pierwszy dzień konferencji rozpoczął się od wykładu Marka Richardsa na temat testowania architektury. Jeśli możesz to zmierzyć, możesz to zdefiniować. Mark podzielił się swoimi przemyśleniami na temat znaczenia testowania architektury, znaczenia definiowania atrybutów jakości oprogramowania - ponieważ ma to wpływ na sposób jego pomiaru. Mark wprowadził nas w temat Architecture Fitness Functions, dzięki którym architekt może testować charakterystyki operacyjne i integralność strukturalną.
Temat metryk przewijał się przez prezentacje, a w mojej głowie pojawiało się coraz więcej pytań - dlaczego tak niewiele firm z nich korzysta? Alex Zitzewiz z Hello2Morrow pokazał wyliczenie, że "niska jakość oprogramowania kosztowała 2,08 biliona dolarów w 2020 roku".
Sonya Natanzon i Vladik Khononov podzielili się swoją prezentacją na temat pragmatycznego podejścia do metryk architektury. To, co jest mierzone, jest zarządzane - nawet jeśli mierzenie i zarządzanie tym jest bezcelowe, a nawet jeśli szkodzi to celowi organizacji. Nie wszystko, co ważne, można zmierzyć. Nie wszystko, co możemy zmierzyć, ma znaczenie. Pokazali, w jaki sposób można zmierzyć częstotliwość zmian (czas realizacji zmiany, częstotliwość wdrażania) lub skuteczność zmian, wskaźnik niepowodzeń zmian, średni czas do odzyskania) oraz że pragmatycznym sposobem pomiaru jest zdefiniowanie. Wskazali również na prawo Goodharta - kiedy miara staje się celem, przestaje być dobrą miarą.
Głośników wciąż przybywało
Sven Peters podzielił się swoimi przemyśleniami na temat tego, jak być skutecznym architektem i pracować mądrzej, a nie ciężej. Było to bardzo zbieżne z moimi osobistymi odczuciami na ten temat - przywództwo techniczne czyni zespoły efektywnymi. Pokazał na kilku przykładach ze swojego doświadczenia, że sam często pisał kod, który był niepotrzebnie skomplikowany. Ale jak zmierzyć, czy kod jest wystarczająco prosty? Pokaż kod mniej doświadczonemu członkowi zespołu i zobacz, jak go zrozumie. Często zapominamy, że inni ludzie będą czytać kod. Opowiedział również o fajnym pomyśle, który mają w firmie - zespół programistów spędza jeden tydzień co sześć miesięcy, który jest poświęcony innowacjom - nie dostarczają wtedy funkcji.
Dzień zakończyły 4-godzinne warsztaty prowadzone przez Michaela Keelinga i George'a Fairbanksa - Zostań projektantem oprogramowania. Opisali oni działania, formaty, zmiany kulturowe i skandaliczne przeszkody. Warsztaty były świetną mieszanką wykładów, ćwiczeń grupowych, opowiadania historii i niesamowitych dyskusji. Podzielili się ramami IMEO (Idea, Medium, Punkt wejścia, Przeszkody), które są praktycznym planem wprowadzenia ważnego projektu do organizacji.
Dzień 3: modułowość, wskaźnik dojrzałości i opanowanie komunikacji wizualnej w architekturze
Kolejny dzień konferencji miał rozpocząć się od prezentacji Neala Forda, niestety nie mógł on przybyć z powodów zdrowotnych, a sytuację uratował Mark Richards, który przedstawił różnice między modułowością a ziarnistością oprogramowania.
Kolejną świetną prezentacją było wystąpienie dr Caroli Lilienthal - Improve your architecture with the Modularity Maturity Index (MMI). Jak ważna jest wysoka spójność i niskie sprzężenie. Kiedy wiesz, że możesz oddzielić moduł? Jeśli nie możesz znaleźć dla niego nazwy, to nie jest to dobry moduł.
Zwieńczeniem dnia było Mastering Visual Communication prowadzone przez Jacqui Read. Zademonstrowała, jak dokumentować architekturę w modelach C4 (Contextual, Container, Component, Code) i SABSA (Contextual, Conceptual, Logical, Physical, Component) oraz pokazała kilka bardzo interesujących anty-wzorców w diagramowaniu.
Moim faworytem (którego sam używałem) jest Eksplozja Jednorożców aka zbyt wiele kolorów - czasami używamy kolorów do grupowania elementów diagramu według funkcji lub typu, ale nie zwracamy uwagi na to, że negatywnie wpływa to na czytelność diagramu. A co jeśli kolor jest kluczem? Jak taki diagram odczytałaby osoba niewidoma na kolory lub gdybyśmy diagram wydrukowali? Warto zastosować jakiś wzór. Kolejną rzeczą, na którą sam nigdy nie zwróciłem uwagi, ale zapamiętałem i wykorzystam, jest wskazówka, aby tworzyć diagramy od lewej do prawej i myśleć o pierwszym wrażeniu.
Moje końcowe przemyślenia
Merytorycznie konferencja była fantastyczna. W sumie było to, czego oczekiwałem i na co liczyłem jednocześnie. Co mnie pozytywnie zaskoczyło?
Po pierwsze atmosfera sprzyjała rozmowom i wymianie doświadczeń, ale naładowała nas energią i chęcią do działania. Wszystkie prezentacje i prelekcje w przerwach były mega inspirujące.
Brzmi to jak truizm, ale taka jest prawda.
Po drugie, organizacja. Wszystko było zapięte na ostatni guzik, w najwyższym standardzie.
Czy czegoś żałowałem?
Gdybym tylko wziął książki Marka Richardsa, które mam na półce, z pewnością stanąłbym w kolejce po autograf. No i FC Barcelona grała na wyjeździe, ale to już inna historia.
Aby zakończyć na
Nie każdy projekt jest wyjątkowy, wiele zespołów ma podobne problemy i możliwość podzielenia się tą wiedzą jest czymś, dla czego warto uczestniczyć w takich wydarzeniach. Spojrzenie na temat mierzenia oprogramowania, mierzenia sukcesu zespołu, produktu czy procesu jego tworzenia było dla mnie jednym z najlepszych tego typu doświadczeń. Do zobaczenia za rok, prawda?
PS. Dodatkową korzyścią było to, że oprócz nowej wiedzy, energii i kontaktów przywieźliśmy ze sobą piękną pogodę i słońce. Przypadek? Nie sądzę 🙂
Udział w tym wydarzeniu był możliwy dzięki projektowi Go to Brand. Więcej na ten temat można przeczytać tutaj.
