Słowa mają ogromne znaczenie. To, w jaki sposób dobieramy je, opisując problem, tak naprawdę wpływa na sposób rozumienia problemu. Dziś na warsztat trafiają dwa pojęcia. Złożony i skomplikowany. Wiele osób używa ich zamiennie przy opisie np. systemów czy zadań. I nie jest to do końca poprawne. Dlaczego? Trochę winy ponoszą autorzy Słownika Języka Polskiego. I o tym za chwilę.

Złożony – Complex

SJP podaje następującą definicję słowa złożony:

  1. składający się z kilku lub z wielu części;
  2. trudny do zrozumienia; zawiły, skomplikowany;
  3. przenośnie o człowieku lub jego charakterze: trudny do poznania, określenia; skomplikowany

Druga część definicji odnosi się do złożonego w wyniku czynności np. złożona kartka i nie jest to dla nas interesujące.

Pierwsze znaczenie słowa złożony odnosi się do czegoś zbudowanego z wielu elementów. Jednak drugie i trzecie jako synonim podaje słowo „skomplikowany”. Tym pojęciem zajmiemy się za chwilę. Niestety taka definicja strasznie miesza…

Kiedy system jest złożony?

Wtedy kiedy ma wiele elementów, które wchodzą ze sobą w interakcje. Myk polega na tym, że w takim systemie możemy prześledzić, jak działanie jednego elementu wpływa na inne. Co więcej, można wyznaczyć pewne granice oddziaływania. Dobrze zaprojektowany, złożony system będzie składał się z elementów, podsystemów, które w jasny sposób wpływają na inne elementy. Nie będzie sytuacji, gdzie zmiana w procesie X, niespodziewanie wywali nam proces Y.

Skomplikowany – Complicated

Znowuż, zacznijmy od definicji słowa skomplikowany:

  1. trudny do rozwiązania, rozwikłania
  2. o charakterze człowieka: trudny do zrozumienia, określenia
  3. o czyimś życiu: pełen kłopotów, trudności

Pierwsze znaczenie jest tym, które nas interesuje.

Kiedy system jest skomplikowany?

System możemy nazwać skomplikowanym, gdy nie ma jasnych zależności pomiędzy jego elementami. Prześledzenie, w jaki sposób dana czynność wpływa na stan systemu, jest niemożliwe. Nie mamy jasnych granic pomiędzy elementami systemu, a podjęcie jakiejś czynności może spowodować nieoczekiwane konsekwencje w innym, zdawać by się mogło niepowiązanym miejscu systemu.

I co z tego?

Chcesz robić systemy złożone, ale nie skomplikowane. Serio. Systemy, w których masz wiele elementów, ale jasne zasady działania. Do tego służy cała zabawa z projektowym BDSM, w stylu DDD, µSerwisów, architektury heksagonalnej i innego mycia kodu, by był czysty. Reguły są proste. Jak nie masz nieoczekiwanych wybuchów w wyniku zmian, to system może być dowolnie złożony, ale nie będzie skomplikowany. To jest bardzo trudne.

Gorzej, jak urodzisz skomplikowanego potworka. Wtedy wprowadzenie dowolnej zmiany, będzie ryzykowne. Dodanie nowej funkcjonalności może wysadzić coś zupełnie niezwiązanego z tą zmianą. Usunięcie jakiegoś elementu może okazać się niemożliwe. Po prostu zależności są na tyle pojebane, że Puszka Pandory brzmi przy tym, jak niewinna zabawa dwójki licealistów.

Ograniczenia

Można przyjąć, że w czasie, każdy system będzie ulegać degeneracji. Nie jest to nic niezwykłego. Złożoność zazwyczaj rośnie szybciej niż możliwości kognitywne ludzi, którzy ją wprowadzają. W dodatku, w czasie projektowania musimy iść na kompromisy, co powoduje, że pojawiają się niespójności. Niespójności powodują, że trzeba „hakierować”. Takie haczenie, zazwyczaj wprowadza niejawne zależności pomiędzy elementami. Nawet po udokumentowaniu, nie są one jasne, z czasem znika wiedza o motywacji. Efekt jest taki, że system zaczyna się komplikować. Aż któregoś dnia, dochodzicie do wniosku, że warto to zaorać i napisać od nowa. Czego sobie i wam życzę. W końcu tym razem się uda, prawda?