Jawa i rowery: spotkanie w Petersburgu

Czym od strony technicznej różni się proces tworzenia własnego produktu od projektów outsourcingowych? Kiedy warto inwestować w rozwój od podstaw, a kiedy lepiej sięgnąć po gotowe rozwiązanie?

W tworzeniu oprogramowania pisanie własnych rowerów traktowane jest jako romans pracy. Programiści z dumą dzielą się swoimi rowerami i publikują je na Githubie. Według prelegenta są to projekty typu „Hello World”, których celem jest nauczenie się czegoś, albo bzdury na poziomie „Nie pamiętamy, po co wymyśliliśmy kulę bilardową, z której wyrastają włosy, ale było to piekielnie trudne”.

W swoim wystąpieniu prelegent poruszy pytania, jakie powinien sobie zadać „kolarz” lub lider zespołu „kolarza” przed wyjazdem na Tour De France. Poda przykłady bibliotek i frameworków, których pojawienie się było uzasadnione i podyktowane podejściem pragmatycznym, a także przykłady tworów, których pojawienie się nie jest możliwe ze względów pragmatycznych.

Wymyślanie „rowerów” to świetna technika nauczania! Aspirujący artyści najczęściej kopiują obrazy mistrzów, więc dlaczego syndrom NIH jest uważany za zły w IT? Przecież żeby zrozumieć jak działa biblioteka czy framework, najlepiej spróbować rozwiązać problem rozwiązywany przez nie samodzielnie, zazwyczaj pisząc coś podobnego.

Odkąd przeszliśmy do modelu ciągłego, permanentnego uczenia się (właściwie nauka i praca stały się jednym, jednolitym procesem), „budowa roweru” doskonale nas w tym wspiera, będąc w istocie praktyką w nauce: czytamy tutoriale, artykuły, oglądamy przemówień na konferencjach i spróbować wypróbować niektóre z nich w naszych projektach bojowych, znajdując w ten sposób najkrótszą drogę na „krzywej wejścia” do nowej technologii.

Często nie jest to jednak najkrótszy, najtańszy i najbezpieczniejszy sposób rozwiązania problemów biznesowych klienta, dlatego rzadko zdarza się, aby klient się na to zgodził. Dokąd w takiej sytuacji powinien udać się „biedny deweloper” – o tym będzie mowa w raporcie Wiaczesława.