Martin Lechowicz

Programiści to piękni ludzie

Jako zawodowy programista chciałbym użalić się nad tymi biedakami, co tworzyli system do liczenia głosów w ostatnich wyborach.

Była to firma Nabino, która miała na to 3 miesiące i pół miliona złotych.

Hugo z radia Kontestacja opowiada, że zrobienie takiego systemu w 3 miesiące jest nierealne. E tam, pierdoły gada. Dla niego pewnie nierealne, bo taki z niego programista jak z koziej dupy trąba. Jak się ma pół miliona złotych, to nie trzeba robić wszystkiego samemu, a system rozległy ale generalnie prosty: ma dodawać, wysyłać i zapisać.

Nie, to nie jest kwestia złego programowania. To jest kwestia złej organizacji.

Się rypło? Widać musiało. Ale to nie programistów wina. To wina organizatorów, kierowników, a przede wszystkim - zleceniodawców.

Wiecie jaki jest największy problem programisty, który robi coś na zlecenie?

Że za mało czasu? Brak narzędzi? Brak wiedzy? Nie ma ludzi do pracy?

E tam. To wszystko jest ważne, ale największy problem jest taki, że zleceniodawca nie wie czego chce. I to prawie zawsze, niestety.

Są różne odmiany tego niewiedzeniaczegochcenia. Są na przykład tacy, co twierdzą, że wiedzą dokładnie o co im chodzi, ale kiedy pokażesz im pierwszy prototyp programu zmieniają nagle zdanie i okazuje się, że im chodziło o kompletnie co innego. Bardzo popularne zjawisko. Irytujące niewiarygodnie. I stąd, zamiast zrobić program w 2 miesiące, robi się go w 2 lata.

Jak sobie z tym poradziła firma Nabino? No chyba całkiem nieźle, skoro system w ogóle działał.

Trzy miesiące na zrobienie systemu oznacza, że robi się go w miesiąc, a dwa miesiące testuje. Żadnych wodotrysków, bo nie ma na to czasu. Działające podstawy trzeba uruchomić jak najszybciej, a resztę dobudowywać w trakcie testowania.

Robiłem często projekty, gdzie musiało być szybko i miało działać. Niestety nie miałem pół miliona złotych ani ludzi do pomocy. Myśli się wtedy inaczej niż przy "porządnych projektach". Z konieczności.

Jak się ma 3 miesiące to trzeba wykorzystywać najprostsze, uniwersalne narzędzia. I przy projektowaniu kluczowe znaczenie ma zarządzanie błędami. To znaczy, trzeba wyznaczyć priorytety: zdecydować z jakimi błędami możemy żyć, a jakie są niedopuszczalne.

Inaczej mówiąc chodzi o realizm życiowy: skoro wiemy, że błędów wszystkich nie poprawimy, to skupmy się tylko na tym, żeby ich nie było w krytycznych miejscach. Żeby w razie awarii (która na pewno będzie, to jest tylko kwestia czasu) nie było paraliżu i dało się szybko reagować.

Niestety paraliż był.

Z czego wnoszę, że ktoś z firmy Nabino był optymistą. Tak, "optymista" to wyzwisko. Optymistów (opisałem to kiedyś w powieści "Teoria Portali") uważam za szczególnie irytujących kretynów, którzy są na dłuższą metę groźniejsi dla otoczenia niż terroryści.

Jeżeli coś w Polsce nie działa, to zwykle dlatego, że ktoś gdzieś był optymistą. Poobserwuj. Zobaczysz, że tak jest.

Więc to nie kwestia złego programowania. Programistom to wy dajcie spokój. Nie byli wcale tacy źli, biorąc pod uwagę zadanie jakie przed nimi postawiono. Gdzie na świecie programista pracuje w takich warunkach? Zleceniodawca, który nie wie zupełnie czego chce, unieważniane przetargi, żadnej wizji całości, czterdziestu szefów na raz i ani jednego odpowiedzialnego, przepisy, które uniemożliwiają zrobienie czegokolwiek sprawnie i wszystko na ostatnią chwilę - w szkołach nie uczą jak pracować w takich warunkach.

Szkoły. Tam jest największy problem. Szkoły to wylęgarnia optymizmu.
No nic.
Jakoś to będzie.
Przeżyjemy.
Jak zawsze.

comments powered by Disqus

Zobacz też:

Sklepik

Wejdź do sklepiku i kup sobie coś fajnego do czytania! A jak już masz to kup drugie. Na prezent.

A próbowałeś kartkować Kindle? 37

A próbowałeś kartkować Kindle?

Tak napisał ktoś pod ostatnim wpisem w odpowiedzi na moją sugestię, że istnieją dziś lepsze narzędzia do nauki niż papier i pióro.

Opowiadam:

Nie, nie próbowałem kartkować Kindle.
Ale za to próbowałem wyszukiwać w zeszycie.

© Martin Lechowicz 2016. Wszystkie prawa i tak dalej.