W 1968 r. informatyk
Melvin Conway (z wykształcenia fizyk i matematyk) opublikował artykuł
How Do Committees Invent?
, którego główną tezą było stwierdzenie:
Organizations which design systems (in the broad sense) are constrained to produce designs which are copies of the communication structures of these organizations.
czyli struktura projektowanego systemu odzwierciedla strukturę organizacji, która ten system projektuje. Brzmi dość zabawnie i zaskakująco, bo znaczy to przecież mniej więcej, że jeśli za system zabiorą się trzy grupy inżynierów, to architektura tego systemu będzie się składała z trzech głównych modułów; co więcej, sposób i jakość komunikacji tych modułów będzie odzwierciedlać sposób i jakość komunikacji grup projektowych.
Przykłady
Prawo Conweya podobno całkiem nieźle daje się obserwować na przykładzie studentów wykonujących projekty grupowe. Przykład z ostatniego semestru: robiłam kurs
Software architecture, gdzie w kilkuosobowych grupach projektuje się architekturę jakiegoś systemu; jednym z etapów przygotowania dokumentacji jest wykonanie kilku
widoków danego systemu; wykładowca stwierdził, że wyraźnie daje się zaobserwować zależność między ilością takich widoków a ilością studentów w grupie i podziałem ról.
Także wszelkie niezgodności, uprzedzenia i problemy komunikacyjne między członkami zespołów mogą się manifestować w projektowanym systemie.
Z innej beczki: mamy gotowy jakiś element (klasę, moduł...), do kórego należy wprowadzić zmiany. Jeśli wykonanie tych zmian zostanie zlecone osobie, która stworzyła ten element, to najprawdopodobniej zmodyfikuje ona oryginalny kod. Jeśli natomiast zmiany ma wykonać osoba, która wcześniej nie pracowała nad tym elementem, to większe prawdopodobieństwo, że stworzy ona np. nową klasę, która odziedziczy własności poprzedniej, a którą rozszerzy o pożądane własności.
Prawo Conweya ma też dalsze implikacje, przydatne menadżerom w zarządzaniu projektami. Jeśli zespół pracuje nie nad nowym systemem, ale już istniejącym, który należy zmodyfikować, dobrze jest upewnić się, że struktura tego zospołu odpowiada architekturze systemu, bo w przeciwnym razie mogą być kłopoty.
W sieci
Dla bardziej zainteresowanych polecam:
A dlaczego mnie to w ogóle interesuje?
Weryfikacja tego właśnie prawa - poprzez analizę wzorców komunikacyjnych deweloperów i porównanie z architekturą systemów, nad którymi pracują - stanowiła jedną z propozycji projektów do zrobienia w ramach pracy magisterskiej. I wymyśliłam sobie, że to coś w sam raz dla mnie: jest teoria i jest praktyka; trzeba trochę poczytać, pogrzebać w dokumentacji i standardach, ale też napisać coś praktycznego (prawdopodbnie bawiąc się w dobranie odpowiedniego algorytmu ewolucyjnego tudzież czegoś podobnego), żeby przekopać się przez dostępne dane i doszukać się schematów; na dodatek temat trochę z pogranicza, zahacza o socjologię.
Tyle tylko, że już zajęty...
Może w następnym odcinku napiszę, na czym ostatecznie stanęło.