Używanie UML jest jak patrzenie na swoje stopy podczas chodzenia. To świadome i wyraźne tworzenie czegoś, co zwykle można zrobić nieświadomie. Początkujący muszą dokładnie przemyśleć to, co robią, ale profesjonalny programista już wie, co robią. W większości przypadków samo pisanie kodu jest szybsze i bardziej efektywne niż pisanie o kodzie, ponieważ intuicja programistyczna jest dostosowana do zadania.
Nie chodzi jednak tylko o to, co robisz. A co z nowym pracownikiem, który pojawi się za sześć miesięcy i musi szybko wprowadzić kod? A co za pięć lat, kiedy wszyscy pracujący nad projektem znikną?
Niezwykle pomocne jest posiadanie podstawowej, aktualnej dokumentacji dostępnej dla każdego, kto później dołączy do projektu. Nie opowiadam się za pełnoprawnymi diagramami UML z nazwami metod i parametrami (o wiele za trudne w utrzymaniu), ale uważam, że podstawowy diagram komponentów w systemie wraz z ich relacjami i podstawowym zachowaniem jest nieoceniony. O ile projekt systemu nie zmieni się drastycznie, informacje te nie powinny się zbytnio zmieniać, nawet gdy implementacja jest modyfikowana.
Odkryłem, że kluczem do dokumentacji jest umiar. Nikt nie przeczyta 50 stron pełnowymiarowych diagramów UML z dokumentacją projektową bez zasypiania kilku stron. Z drugiej strony, większość ludzi chciałaby otrzymać 5-10 stron prostych diagramów klas z podstawowymi opisami tego, jak system jest złożony.
Innym przypadkiem, w którym okazało się, że UML jest przydatny, jest sytuacja, gdy starszy programista jest odpowiedzialny za zaprojektowanie komponentu, ale następnie przekazuje projekt młodszemu programistowi do wdrożenia.