Studenci i hobbyści lubią pisać kod dla samej zabawy pisania kodu. Stąd różnorodność rozwiązań w każdej niemal kategorii oprogramowania. Dzięki temu klony Uniksa są dziś najbardziej elastycznymi systemami. Sytuacja wygląda jednak nieco inaczej w przypadku oprogramowania komercyjnego.

Każdy chce się pochwalić swoimi umiejętnościami i chętnie napisałby wszystko od zera, ale w odróżnieniu od oprogramowania OpenSource, w komercyjnych rozwiązaniach obowiązują terminy, a głównym czynnikiem napędzającym całą zabawę są pieniądze. Ważne nie jest popisanie się, ale efektywne zgospodarowanie czasu, stąd pisanie własnych rzeczy często jest niepożądane.

Zanim zabierzesz się za pisanie własnego modułu, silnika czy jakiegokolwiek elementu oprogramowania, rozejrzyj się po rynku. Sprawdź czy istnieją gotowe rozwiązania, z których mógłbyś skorzystać i zaoszczędzić czas. Jeśli nie uda ci się znaleźć nic, co pasowałoby do twojego projektu, zainteresuj się tymi, które nie pasują. Sprawdź, jaką mają bazę użytkowników, czy znane są jakieś błędy, z jakimi problemami borykają się ci, którzy im zaufali i czy nie żałują swojej decyzji. Zobacz, czy nie da się ich zaadaptować za pomocą minimalnych zmian.

Pisanie własnego systemu powinno być ostatnim podejmowanym krokiem. Jeśli nie znajdziesz nic, co mogłoby ci zaoszczędzić czasu, to zaoszczędź go sobie sam - przeznacz czas na zaplanowanie swoich działań zanim napiszesz choćby linijkę. Zastanów się nad architekturą, porównaj ją z istniejącymi i skorzystaj z poznanej wcześniej listy problemów. Pisanie oprogramowania, które nie będzie się nadawało do wdrożenia mija się z celem, tak samo jak napisanie od zera kolejnego pakietu o identycznej funkcjonalności.

Pamiętaj, że prawdopodobnie nie będziesz jedyną osobą dbającą o ów kod - zaplanuj go rozwojowo i tak, żeby wprowadzanie zmian nie wymagało przepisywania dużych fragmentów kodu. Przygotuj choćby krótką dokumentację - twoi współpracownicy nie będą mieli czasu na czytanie całości kodu za każdym razem, kiedy potrzebują z niego skorzystać. To jest właśnie największa zaleta korzystania z szeroko stosowanych rozwiązań - problemy za ciebie rozwiązują inni. Ty możesz skupić się kodzie funkcjonalnym, a nie na poprawianiu używanych narzędzi i bibliotek.

Reasumując: w pracy codziennej pisze się masę nowego kodu, ale staramy się ograniczać do tego, którego napisanie jest nieodwołalne. Cała reszta to koszty, które dla pracodawcy nie przynoszą żadnego zysku (poza kodem, o który trzeba dbać, co pochłania dalsze ilości czasu, a w efekcie przekłada się znów na pieniądze).