Na wielu konferencjach IT poruszany jest temat nowych technologii, paradygmatów wytwarzania oprogramowania, kwestii zapewnienia jakości czy skalowalności budowanych systemów. Dług techniczny często kojarzony jest wyłącznie z systemami legacy, niskim pokryciem testami jednostkowymi i starą wersją Javy. W swojej prezentacji postaram się rzucić nowe światło na pojęcie długu technicznego i uzmysłowić Wam jak głęboko wdziera on się w każdą organizację korzystającą w jakimkolwiek stopniu ze współczesnych technologii.

1. Dług techniczny
czyli skryty oprawca organizacji (nie tylko technologicznych)
Mateusz Gajewski • @wendigo • JDD Kraków 2017
1

2. Kim jestem
• Ostatnie 8 lat spędziłem w Allegro,
• W karierze przyjmowałem różne role: programisty, architekta, lidera i mentora,
• Aktualnie pomagam organizacjom na różnym etapie rozwoju (w tym startupom)
w pozbywaniu się długu technicznego i skalowaniu ich biznesu,
• @wendigo na Twitterze, GitHubie, Keybase i Speakerdeck
2

3. 3

4. Metafora długu technicznego
Ward Cunningham, 1992
4

5. Dług techniczny
1. suma pieniędzy, którą ktoś pożyczył i musi zwrócić,
2. obowiązek dłużnika do spełnienia określonego świadczenia,
3. zobowiązanie moralne wobec kogoś
źródło: https://sjp.pwn.pl/slowniki/dług.html
5

6. Dług techniczny
Technika to usystematyzowane wykorzystywanie reguł naukowych i wiedzy praktycznej do
wytwarzania określonego produktu (wyrobu). Składa się z:
1. Zespołu reguł i praw naukowych,
2. Określonej grupy zastosowań,
3. Określonego zestawu produktów wytwarzanych przy użyciu określonych urządzeń,
4. Specjalistycznej wiedzy, wyrażonej zbiorem technologii (metod) wykorzystywanych w
pracach badawczych, pomiarach i praktycznych zastosowaniach techniki,
5. Doświadczenia praktycznego,
6. Organizacji, wyrażonej strukturą i systemami.
źródło: „The Management of Technology, Perception and Opportunities”, Paul Lowe, 1995
6

7. Jako IT dostarczamy „biznesowi”
oprogramowanie, aplikacje, architekturę, procesy,
technologie, urządzenia, kompetencje, organizację pracy
które pozwalają nam świadczyć usługi mające określoną
funkcjonalność
(fit for purpose)
użyteczność
(fit for use)
7

8. Systemy muszą mieć odpowiednie -ości
Wymagania pozafunkcjonalne normy ISO 9216
niezawodność wydajność dokładność integralność
łatwość odporność rzetelność dostępność
czytelność pojemność skalowalność dojrzałość
jakość stosowalność zgodność odtwarzalność
odzyskiwalność analizowalność operowalność utrzymywalność
zmienialność testowalność zamienialność rozwijalność
efektywność interoperacyjność bezpieczność niezawodność
przenośność plastyczność adaptowalność instalowalność
bezawaryjność konfigurowalność zastępowalność powtarzalność
8

9. Dług techniczny przejawia się
brakiem wymaganej użyteczności
9

10. Przejawem długu technicznego
nie jest brak funkcjonalności
10

11. Jak i dlaczego powstaje
dług techniczny?
11

12. Kompromis: „A” lub „B”
12

13. „Designing a perfect solution is a
destructive endeavor and is elusive to
even the most capable software
craftsman.”
Chris Sterling - Principal Product Manager Spring Cloud
13

14. Wpływ środowiska
Ograniczone zasoby:
1. presja czasu,
2. brak odpowiednich danych,
3. finansowania,
4. brak odpowiednich ludzi,
5. brak kompetencji i doświadczenia,
6. brak dostępu do narzędzi, technologii i wiedzy.
14

15. Klasyfikacja źródeł długu technicznego
Żródło: M. Fowler - Technical Debt Quadrant
15

16. Dług techniczny wynika z
każdej świadomie lub nieświadomie
podjętej decyzji, której rosnący w czasie
koszt zostanie nieuchronnie poniesiony w
przyszłości
16

17. Zaciąganie długu technicznego pozwala
nam szybciej dostarczać, zbierać
informacje zwrotne, uczyć się i
dochodzić do poprawnych rozwiązań
17

18. Ewolucja systemów
wg Lehmana
18

19. Ewolucja systemów klasy „E”
1. Ciągła zmienność (continuing change),
2. Wzrastająca złożoność (increasing complexity),
3. Samoregulacja (self regulation),
4. Organizacyjna stabilność (conservation of organisational stability),
5. Zachowanie znajomości (conservation of familiarity),
6. Ciągły wzrost (continuing growth),
7. Degradacja jakości (declining quality),
8. Sprzężenie zwrotne (feedback system).
Żródło: Prawa Lehmana ewolucji oprogramowania
19

20. Prawo I: „Ciągła zmienność”
„continuing change”
20

21. Prawo II: „Wzrastająca złożoność”
„increasing complexity”
21

22. Prawo VI: „Ciągły wzrost”
„continuing growth”
22

23. Prawo VII: „Degradacja jakości”
„declining quality”
23

24. „If you are not improving, entropy guarantees
that you are actually getting worse.”
Gene Kim - The Phoenix Project
24

25. Ryzyka związane z długiem
technicznym
25

26. 26

27. 27

28. http://blog.hasmanythrough.com/2009/9/3/circle-of-death
28

29. Niespłacanie długu technicznego
1. Nie dostarczanie na czas nowych funkcjonalności,
2. Wzrost ryzyka biznesowego,
3. Zatrzymanie rozwoju firmy,
4. Odpowiedzialność karna,
5. Problem z otrzymaniem kolejnej rundy finansowania (due diligence),
6. Niezadowolenie i odpływ klientów (zła funkcjonalność, niska używalność),
7. Utrata kapitału firmy,
8. Upadek :(
29

30. Spektakularne przypadki
1. 2009: Nasza Klasa - Pan Gąbka i ciągłe awarie systemu,
2. 2012: Knight Capital Group - strata 440 mln $ w 40 minut,
3. 2013: Toyota - błąd w kodzie ECM powoduje śmierć kierowcy,
4. 2017: GitLab - usunięcie danych i problem z ich przywróceniem,
5. 2017: AWS - 11h niedostępność regionu S3.
30

31. Indykatory długu
technicznego
31

32. 32

33. Wewnętrzna jakość
1. Czy stosowane są wzorce clean code?
2. Czy kod jest testowany? W jaki sposób?
3. W jaki sposób mierzona jest jakość kodu?
4. Jak często kod jest refaktoryzowany?
5. Jak duża jest duplikacja kodu?
33

34. Struktura komponentów
1. W jaki sposób aplikacja podzielona jest na komponenty? Ile można ich wydzielić?
2. Jak komponenty integrują się ze sobą?
3. Jak silnie powiązane są ze sobą komponenty?
4. Jak łatwo zidentyfikować można komponenty w których należy dokonać zmianę
biznesową?
5. Jak łatwo wymienialne są poszczególne komponenty?
34

35. Architektura
1. Czy architektura posiada strukturę i jest spójna?
2. Czy architektura odpowiednio wspiera cele biznesowe?
3. Czy architektura wprowadza porządek, integralność i bezpieczeństwo do systemu?
4. W jaki sposób architektura jest udokumentowana i czy jest jednakowo rozumiana?
5. W jaki sposób komponenty integrują się ze sobą na poziomie architektury?
35

36. Procesy
1. Jaki jest lead time (LT) wprowadzania nowych zmian?
2. Jakie zespoły są zaangażowane w proces dostarczania wartości?
3. Jak długo trwa integracja zmian przed wdrożeniem?
4. W jaki sposób testowane są zmiany przed wdrożeniem?
5. Jakie są artefakty procesu wytwarzania oprogramowania?
36

37. Organizacja
1. W jaki sposób nabywana i wprowadzana jest nowa wiedza w organizacji?
2. Jak dobrze pracownicy rozumieją i wspierają cele organizacji?
3. Czy istnieją role lub kompetencje które trudno jest zastąpić (silosy)?
4. Jak łatwe/trudne jest pozyskanie nowych pracowników z odpowiednimi kompetencjami?
5. Ile trwa wdrożenie nowego pracownika w jego obowiązki?
37

38. Produkt
1. Proporcjonalnie ile czasu poświęcane jest na rozwój nowych funkcjonalności?
2. Czy istnieje dedykowany zespół utrzymaniowy?
3. Kto podejmuje decyzje o wdrożeniu produktu?
4. Jak często wdrażane są nowe funkcjonalności?
5. Jak wiele jest defektów i awarii po wdrożeniu?
38

39. Jak postępować z długiem
technicznym?
39

40. Nie ukrywajmy długu technicznego
przed biznesem
40

41. Obsługa długu
1. Dług powinien być zarządzany tak samo jak zarządzamy produktem, który rozwijamy,
2. Dług powinien być priorytetyzowany ze względu na:
1. Koszt (ile będzie kosztować jego spłacenie),
2. Łatwość (jak trudne technicznie jest pozbycie się go),
3. Wpływ (jak możemy ucierpieć żyjąc z nim),
4. Prawdopodobieństwo (jak bardzo prawdopodobny jest negatywny wpływ długu),
3. Powinniśmy szukać globalnych rozwiązań lokalnych problemów.
41

42. Taksonomie długu technicznego
1. Niezamierzony (niska jakość) - wymaga stałych przeglądów i refaktoryzacji,
2. Zamierzony (reaktywny, taktyczny):
1. Skoncentrowany krótkoterminowy - zadania trafiają do backlogu do wykonania po releasie,
2. Nieskoncentrowany krótkoterminowy - spłacany w trakcie bieżącej pracy (refaktoryzacja),
3. Długoterminowy (proaktywny, strategiczny) - zarządzany jak projekt, z odpowiednim
budżetowaniem
Steve McConnell, “Technical Debt”
42

43. Podsumowując…
43

44. Dług techniczny jest w każdej organizacji.
Nie jest on tylko i wyłącznie problemem IT.
44

45. Dług techniczny może być strategiczną
decyzją podjęta w celu zebrania
odpowiedniego doświadczenia
45

46. Dług techniczny może być także
wynikiem niekompetencji, głupoty i
niekontrolowanego działania entropii
46

47. Nie bój się zaciągać długu technicznego.
Rób to świadomie. Spłacaj go konsekwentnie.
47

48. „Ciągłe skupienie na technicznej doskonałości i dobrym
projektowaniu zwiększa zwinność.”
Agile Manifesto
48

49. Thanks!
contact@serafin.tech
Q&A?
49