Zauważyłem wiele razy, że często w projektach informatycznych (ale nie tylko ;-)) jest tak, że ludzie mówią jak ma być (czasem nawet wiedzą jak ma być ;-)), czasem jeszcze wiedzą jak jest (choć to już nie tak często), ale jakoś w ogóle nie myślą o tym co będzie po drodze.
Nie patrzą na problem jak na proces, który będzie trwać przez jakiś czas, w którym są różne zależności, które są może poza kontrolą, po prostu chcą tej ostatecznej idealnej wersji.
Będąc w Waszyngtonie odwiedziłem Smithsonian National Air and Space Museum i tam jest taka plansza pokazująca kroki w programie lotu na Księżyc.
Widać tam, że od momentu jak już wiedzieli w NASA, że lecą na Księżyc bo Kennedy wskazał ten cel, a nawet już wcześniej, cały program był nastawiony na lot na Księżyc.
Poszczególne misje już w programie Gemini miały na celu testowanie rozwiązań, które miały być użyte w programie Apollo.
Podobnie w rozwiązaniach software'owych trzeba o tym myśleć, a często się nie myśli.
Dla wielu devów ważny jest ficzer, czy ticket nad którym pracują i nie patrzą jak on się wpisuje w całokształt systemu.
Znów wielu architektów z lekkim obrzydzeniem patrzy na materializację idei ;-) i chce rozwiązań doskonałych i nie patrzy na co się dzieje po drodze.
Np. jedna z podstawowych zasad to to by nie budować czegoś na przyszłość, albo nie budować czegoś co nie będzie używane przez jakiś czas bo będzie czekało na inny komponent.
Wiele razy widziałem zrzucanie ficzera na następny kwartał bo "X nie dostarcza funkcjonalności", chociaż wystarczyło ją samemu napisać... nie była to rzecz krytyczna. Ale napisanie jej nie pasowało do wizji.
Jeden z większych błędów w jednym z projektów nad którym pracowałem wynikał z tego, że jeden z teamów dostał informację, że nie wolno im napisać pewnego komponentu UI i muszą czekać, aż zostanie dostarczony przez autorów frameworku, w międzyczasie zaś UX musiał hackować przy pomocy komponentów które istniały z ich ograniczeniami... a później genialnie ktoś inny wpadł na pomysł, że ponieważ UI jest złożony to trzeba wprowadzić specjalny framework do budowania interfejsu aplikacji przez kilka zespołów... nigdy to dobrze nie działało, zmniejszyło wydajność wszystkich zespołów... a wszystko przez to, że w idealnym świecie osób zarządzających projektem to framework miał dostarczyć funkcjonalności... nie dostarczył więc w końcu sproduktyzowano hacka ;-)
Nie pomyślano o tym co robić w międzyczasie, w różnych product boardach i roadmapach coś było przewidziane kiedyś w przyszłości i do tego momentu należało czekać.
W innym projekcie widziałem zdziwienie developmentu, że można ruszyć na PROD bez jednego z komponentów, bo od niemal początku planowany był awaryjny workaround, który miał mieć możliwość przejęcia funkcji tego serwisu jakby serwis nie zdążył...
Co najlepsze dostali to jako bibliotekę, ale uznali, że sami sobie to napiszą i napisali nie dostrzegając, że sposób generowania nowych IDików jest stabilny.
A tworzenie softu to jest zawsze proces :-) od początku trzeba budować wszystko tak by można było podmieniać klocki i zaczynać od trywialnej implementacji, która pozwoli uruchomić całą resztę układanki. Nawet jak w którymś momencie będzie implementacja, która coś hardcode'uje.
Co zabawne czasem takie tymczasowe rusztowania mogą zostać na zawsze w produkcji, co dowodzi tego, że bardziej fancy rozwiązania wcale nie były potrzebne ;-)
Podobne postybeta
Kosmiczne klocki :-)
2 wymiarowa teoria kariery w IT ;-)
Wkurzają mnie obłudni i źli hipokryci mizogini.
Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)
Czemu filmowe AI jest prawie zawsze tak bardzo tępe?
Brak komentarzy:
Prześlij komentarz