Gdzieś między Polską a Niemcami, a szczególnie w NRD

Twit Programmers of the Year

Tytuł notki zainspirowany jest notką Boniego - "Twit of the Year". A co do meritum:

Jako - było nie było - fachowiec od inżynierii oprogramowania, z za chwilę trzydziestoletnim doświadczeniem, ze zgrozą obserwuję poziom wykonania programów wszędzie dookoła. Tak w zasadzie to tworzenie oprogramowania jest stosunkowo proste. Są do tego dość jasno określone zasady, cała kupa darmowych narzędzi pomocniczych, mnóstwo książek, nieprawdopodobne ilości porad do znalezienia w sieci, ... Co prawda w dowolnej innej branży też są dość jasne zasady, narzędzia, książki, tyle że przy programowaniu jest łatwiej - bardzo dużo można sobie po prostu wypróbować i poćwiczyć w domu, praktycznie za darmo. A na przykład w takim budownictwie to jakoś tak nie bardzo da radę.

Tymczasem w realnym świecie trudno o kawałek programu, który nie jest spieprzony i to najczęściej w sposób który powinien być łatwy do uniknięcia. Jaki-taki poziom mają najczęściej programy z okolic Free Software pisane w Javie, ale też wcale nie wszystkie. Dlaczego tak jest? To jest proste: Oni tam stosują się do ogólnie znanych reguł - używają development patternów, robią module testy, konsekwentnie robią komentarze w Javadocu z których potem powstaje dokumentacja, testy wykonują automatycznie w jakimś serwerze CI w rodzaju Jenkinsa, ... W sumie nic skomplikowanego, tyle że inni tego nie robią, albo robią to źle.

Ja rozumiem że bardzo duża część programów które można zdownloadować w systemowym sklepie jak Google Play czy Windows Store to produkcje półamatorskie i ich autorzy nie mają większego pojęcia o tym, co robią. Ale w produkcjach profesjonalnych, zwłaszcza w branżach które nie zajmują się tylko czystym softem nie jest wiele lepiej. Na przykład u mnie, w automotive.

U nas w fabryce, jestem jedyny który ma rzeczywiście pojęcie o inżynierii oprogramowania. Cała reszta to elektronicy, którzy na studiach mieli pobocznie cośtam o programowaniu. Albo i nawet nie i są samoukami. Niektórzy są nawet nieźli, myśleć logicznie potrafią, tyle że podstaw im brakuje. No i potem wygląda to na przykład tak, że w kawałkach w C++ nie jest nawet dobrze określone który header file jest do C, a który do C++ i jak pojawiają się problemy przy includowaniu, to ktoś łata problem takimi sposobami,  że jakbym miał jeszcze dość włosów na głowie, to bym je sobie powyrywał. W innych, zupełnie podstawowych sprawach też nie jest lepiej. A jak jakiś problem trzeba rozwiązać, to niemal każdy szuka podobnego miejsca w innym module i zrzyna rozwiązanie. A ponieważ to rozwiązanie rzadko tylko jest dobre, to złe rozwiązania rozprzestrzeniają się coraz bardziej. Testy modułowe są wymuszane przez klienta - więc robi się je na sam koniec, często już po tym jak program poszedł do na produkcję. Według mnie to zbędna robota, równie dobrze można by wyprodukować oszukany test report, nic by nie zmieniło a roboty mniej. I tak dalej, i tak dalej, ogólnie to cieszcie się że samochody w ogóle są w stanie ruszyć z miejsca.

No ale mimo wszystko programiści z automotive nie zasługują jeszcze na tytuł "Twit Programmers of the Year". Ponieważ samochód podpada pod różne takie tam związane z bezpieczeństwem (znaczy może kogoś zabić), to producenci wymuszają na wykonawcach żeby program nie wieszał się co chwilę, a przynajmniej żeby się potem jakoś znalazł. Na spełnienie tych wymagań idzie niesamowita ilość wysiłku a modus operandi typowego projektu w automotive to eskalacja. Jeszcze nigdy nie słyszałem o projekcie w automotive który by nie wszedł w eskalację. Mi to ręce opadają, bo tego wszystkiego można by uniknąć, gdyby chociaż trochę stosować się do ogólnie znanych zasad.

Ale jest branża w której jest jeszcze gorzej - to consumer electronics. Soft do telewizora jeszcze nigdy nikogo nie zabił, więc nikt nie wymusza w nim zachowania zasad fuctional safety. Ba, jak poklikać trochę w jakiś współczesny telewizor to wychodzi że oni w ogóle nawet podstawowego system testu to raczej jednak nie robią.

Skąd mi się temat wziął? Mój sprzęt audio-video już się mocno historyczny zrobił. Telewizor był jeszcze CRT, od Sony, ale nic bardzo specjalnego. Ciągłe mam video VHS i analogowy zestaw kina domowego z wejściem przez SCART. Najnowszym z urządzeń był dekoder kablowy, też dający sygnał na SCARTa. No i ten dekoder zaczął mieć problemy. Zaczęło się od różnych zakłóceń w obrazie, potem odbierał coraz mniej kanałów, w końcu zostało tylko Russia Today. A potem poszedł z niego dym - sfajczyły się dwa elektrolity. No i po analizie opcji wyszło mi, że najlepiej będzie kupić nowy telewizor, bo tunel kablowy będzie w zestawie, a i nagrywanie na dysk USB przynajmniej częściowo zastąpi video. A w następnej kolejności będzie nowe kino domowe.

Jako warunki brzegowe postawiłem rozmiar 32 cale (wystarczy mi), FullHD (4K to przesada, ale poniżej FullHD w dzisiejszych czasach bez sensu) i żeby był Smart. No i zaraz wybór skurczył mi się do zaledwie kilku modeli. A potem się doczytałem, że są już telewizory z Androidem. Ponieważ moje zdanie o programistach od telewizorów było utrwalone już od dawna, stwierdziłem że wezmę taki - jak nie będą pisać wszystkiego sami tylko wezmą za bazę niezłego Linuxa i jakie-takie API od Googla to okazji do narobienia głupot będą mieli mniej.

Od paru dni mam taki telewizor i jak widzę, prawdziwy Twit Programmer of the Year potrafi spieprzyć nawet taką integrację:

  • To nie jest "telewizor na Androidzie" tylko "telewizor z własnym systemem + Androidem". Miejsca sklejenia widać dość wyraźnie. Ale i tak jest trochę lepiej niż bez Androida.
  • Do telewizora można podłączyć mysz. Wszystko pięknie, tyle że rolka myszy chodzi w różnych menu, ale nie w web browserze. Po prostu nie chodzi i już, do scrollowania strony trzeba klikać w suwak, nawet ciąganie go nie działa.
  • Można sobie utworzyć cztery listy ulubionych kanałów, ale wybrać jakiejś już nie. Znaczy okienko wyboru się pojawia, na liście są utworzone listy, ale listy wszystkich kanałów na niej nie ma. Nie muszę chyba pisać, że niezależnie od tego co wybiorę, po wyjściu z okienka ustawiona jest lista wszystkich kanałów. Zmienić to mogę tylko przy użyciu programu zdalnego sterowania na innym urządzeniu Androidowym. Na telewizorze nie da rady, próbowałem chyba z pół godziny. Proszę sobie darować komentarze że RTFM- w manualu nie ma o tym nawet słowa. Tytuł Twit Programmer of the Year słusznie się należy.
  • Własny program do zdalnego sterowania z innego urządzenia Androidowego od producenta telewizora nie łączy się z telewizorem. Inne, od jakichś amatorów, jakoś się łączą (ale też nie wszystkie). Może ma to związek z tym, że w drugim urządzeniu WiFi chodzi na 2,4GHz, a telewizorowe na 5 GHz, ale amatorzy radzą sobie mimo routera po drodze.
  • Nagrywać na dysk USB można tylko to, co się widzi. To akurat zrozumiałe - tuner jest tylko jeden. Ale nie da się odtwarzać nagranego programu na komputerze (przez DLNA) oglądając co innego.
  • Jak ustawić nagrywanie na powiedzmy za dwa dni, dysk kręci się przez te dwa dni cały czas, nawet przy wyłączonym telewizorze. Naprawdę nie można go obudzić na pięć minut przed nagraniem?
  • Już raz mi się coś powiesiło - oglądać TV można było, ale nie chodziło odtwarzanie nagranego programu i nic z internetem. Pomógł dopiero twardy reset z odłączeniem zasilania. Chyba zwisała część Androidowa.

Oczywiście nie twierdzę, że ten model telewizora przebija dno, z pewnością są gorsze. Ale programiści od consumer electronics rozumianej jako cała branża z pewnością zasługują na tytuł Twit Programmers of the Year

Jeszcze autoreklama, jakby czytał to jakiś decydent z branży: Za odpowiednią opłatą zorganizuję wam to bez porównania lepiej. Tylko poważne propozycje.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: ,

Kategorie:Ciekawostki, Pomyślmy

Sledz donosy: RSS 2.0

Wasz znak: trackback

-----------------------------------------------------------------------------------------------------------------------


36 komentarzy do “Twit Programmers of the Year”

    • cmos cmos pisze:

      Eee tam. Myślisz że na przykład cluster do Bugatti czy RR robią u nas lepiej niż do Skody czy Seata? To ci sami ludzie, oni nie umieją lepiej.

    • cmos cmos pisze:

      @marcin1234
      Czuję, że jeszcze muszę uzupełnić, bo to jest dokładnie przeciwnie niż Ci się wydaje. Jest jednak różnica między softem do Bugatti a softem do VW Polo. Soft do WV Polo jest cały certyfikowany na safety, do Bugatti nie. Bo ten do Polo to we wszystkich wariantach (to jest MQB, więc jest do wielu modeli) jest robiony na miliony rocznie, a do Bugatti na setki w ogóle. Więc do Bugatti nie warto certyfikować, bo koszt certyfikacji jest wyższy niż wartość oczekiwana ewentualnie wypłaconych odszkodowań. Twoje CCC jest po prostu nieprawdziwe.

  1. piotru pisze:

    Generalnie zagadzam sie z toba co do meritum. Podoba mi sie ta uwaga co do naglowkow w C i w C++ , choc pracuje jako programista w C#.
    Niski poziom wynika z wielu czynnikow , po pierwsze zawsze sie jest w niedoczasie ( to chyba z niemieckiego ) , czyli projekt jest zalozny na 5 miesicey a bierze sie za niego miesiac przed terminem oddania . Stad nie ma czasu na testy , testujemy w boju , najwyzej poprawimy , czasami jest tak jak z Samsung Galacy .
    Drugim problem jest brak wiedzy i doswiadczenia. Ja kiedys robilem oprogramowanie dla firmy z top 10 w europie . Najciekawsze bylo , gdy zapytalem czy ma byc dobrze czy ma jakos dzialac , odpowiedz byla prosta – jakos . To byl koniec mojego udzialu w projekcie .
    Na naszym polskim podworku dodalbym , pomyslowych dobromirow , ktorzy wprowadzaja swoje standardy pisania programow .
    W efekcie jest tak jak mowisz , tyle ze fascynuje mnie to ze stacja kosmiczna jest sterowana przez komputer 486 , cos w tym jest . Po porstu wtedy bylo malo RAM’u i trzeba bylo ograniac , a teraz ?

    • cmos cmos pisze:

      @piotru
      @nagłówki w C++
      No właśnie to moje ostatnie facepalmy, bo odkryłem że w jednym z podstawowych modułów człowiek umieścił w .h deklaracje paru typów w namespace, i żeby się kompilowało zainkludowane z C to to namespace zrobił pod #ifdef _cplusplus. Skutek jest taki, że to są różne typy, zależnie czy includuje się z C czy z C++. I teraz co inni ludzie wyczyniają żeby to się wszystko razem kompilowało to głowa mała.

      Niski poziom wynika z wielu czynnikow , po pierwsze zawsze sie jest w niedoczasie

      A ten niedoczas wynika najczęściej z tego, że poprzedni projekt się przeciągnął. A przeciągnął się dlatego, że nigdy nie ma czasu na to żeby zrobić jako-tako porządnie od początku (bo nie ma na to czasu), więc potem trzeba poświęcić trzy razy tyle czasu żeby znaleźć dlaczego że coś nie działa i poprawić przerabiając od podstaw.

      Ja bym to sformułował tak: Każdą oszczędność czasu na początku projektu trzeba spłacić z lichwiarskimi odsetkami na jego końcu.

      Drugim problem jest brak wiedzy i doswiadczenia

      Z moich doświadczeń wynika, że po prostu prawie nikt niczego się z tych projektów nie uczy. Mało gdzie formułuje się patterny do rozwiązywania konkretnych problemów, a bez obowiązujących patternów każdy rozwiązuje te same problemy w inny sposób (poświęcając na to masę czasu), w 99% wypadków rozwiązanie jest złe albo niekompletne. Gdyby pattern był (i obowiązywał), to ludzie by się poprawnych rozwiązań uczyli, a ponieważ go nie ma to wymyślają głupoty albo kopiują złe rozwiązania od innych.
      No ale o tym mógłbym ze trzy książki napisać.

  2. yossarian pisze:

    Jestem programistą na razie z kilkuletnim doświadczeniem, ale mogę coś powiedzieć o swoich obserwacjach z firmy, w której pracuję (zresztą nic odkrywczego):

    – Brak odpowiedniego wyszkolenia nowego pracownika. Nowi pracownicy często mają tylko podstawową wiedzę, sporo muszą się douczać. Ktoś bardziej doświadczony powinien przyjrzeć się temu co robią, trochę ich na początku poprowadzić i pokazać co i jak. Tylko, że ci bardziej doświadczeni przeważnie są tak zawaleni robotą, że nie mają na to czasu.

    – Presja czasu. Ma działać już. Pisze się wtedy byle jak, w stresie byle by zadziałało. To jest bardzo krótkowzroczne podejście i na ogół się mści. Często wiąże się z tym, że przełożony nie był nigdy programistą i tego nie rozumie, albo naciskają na niego z góry.

    – Każdy problem da się rozwiązać nadgodzinami. Co z tego, że jesteś tylko człowiekiem i masz ograniczone możliwości – pracuj od rana do wieczora i dokończ to. Praca w zmęczeniu i stresie na dłuższą metę nie daje dobrych rezultatów. Więcej z tego problemów niż pożytku, ale na to przełożeni przeważnie nie patrzą.

    – Duża rotacja pracowników. Każdy kto coś sensownego umie przenosi się do innych firm. Po co dawać podwyżkę fachowcowi? Lepiej zatrudnić paru studentów na jego miejsce.

    – Nie trzymanie się procedur. Ciągłe powtarzanie tych samych głupich błędów, których można bardzo łatwo uniknąć.

    Te problemy pewnie występują w mniejszym lub większym stopniu wszędzie.

    Część mojego zespołu parę lat temu pracowała nad projektem webowym. Mieli wycieki pamięci, więc zaczynało brakować RAM’u na serwerze. Jak rozwiązali problem? Robili po prostu restart co jakiś czas :) Tak to się kręciło przez rok, czy dwa :)

    Człowiek jest leniwy, to szuka dróg na skróty. Nie ma czasu na planowanie długoterminowe, jakoś to będzie. Dopóki się to kręci, to jest OK. Jak przestaje, to jest panika. Poza tym: done is better than perfect :)

    • cmos cmos pisze:

      @yossarian
      Robili po prostu restart co jakiś czas

      Robiłem kiedyś w niegdysiejszym Start Amadeusie przy middleware (Unix, C++, farma serwerów robiąca za interfejs do mainframe) które robiło sprzedaż biletów na Expo 2000, jakieś marne 100.000 biletów na dobę. Też im pamięć wyciekała i też wymyślili rozwiązanie z restartem co noc. Najęli mnie specjalnie do pozatykania tych wycieków – w tym w sumie niezbyt dużym kawałku programu było tego kilka miejsc. Facet od testowania mówił, że ten co przede mną ten kawałek robił (doktor informatyki) nie mówił mu nawet co zmienił od poprzedniego release, pewnie żeby nie było tak łatwo znaleźć że nadal coś nie tak.

  3. janekr pisze:

    W książce „Mityczny czowiekomiesiąc…” z roku 1975 opisano mechanizm kurczenia się czasu na programowanie. „Skąd bierze się kilkumiesięczne opóźnienie w rocznym projekcie? Po kilka godzin dziennie.”
    Już wtedy był to problem i już wtedy był dobrze wyjaśniony.

    W skodzie *na razie* znalazłem dwa drobne błędy w oprogramowaniu:

    1. Po przełączeniu wyświetlacza na podgląd zużycia paliwa i z powrotem na radio nie zawsze pojawia się ten sam bank przycisków z programami stacji.
    2. Nie działa ikona do kończenia rozmowy – przerwać połączenie może tylko rozmówca. A jeśli rozmówca się nie zgłosi, to tylko bezpośrednio z telefonu. (To może być jakaś subtelna niezgodność mojego telefonu?)

    Z dekoderem telewizji kablowej (UPC) wojuję od dłuższego czasu, ale sprawa jest beznadziejna. Są dwa ważne problemy:

    1. Dekoder może konwertować program nadawany w SD na HD, ale ignoruje flagę dotyczącą proporcji obrazu – zawsze traktuje sygnał SD jako 16:9, mimo że nadawca prawidłowo tę flagę ustawia, a dekoder ja zna.
    2. Nie ma możliwości dokonania dwóch nagrania w tym samym czasie, ale także nie można nagrać dwóch następujących po sobie programów z tego samego kanału.

    Oczywiście wiesza się często, przy czym najczęściej pomaga „włącz/wyłącz”, czasami „przywrócenie ustawień fabrycznych”, a czasem twardy reset…

    GDYBYM miał kod źródłowy i narzędzia, zapewne zdołałbym poprawić wszystkie wspomniane błędy i nawet bym się nie napracował…

    • cmos cmos pisze:

      @janekr & skoda

      Widzisz tylko te problemy, które jakoś się objawiają na wyświetlaczu. Ale jakbyś wziął tester diagnostyczny i odczytał DTC i Exceptions poszczególnych urządzeń, na pewno byś coś jeszcze znalazł.

      @dekoder

      Doskonale potwierdza to moją tezę o wyjątkowości programistów od consumer electronics. Przecież oni nawet podstawowych testów systemu nie mają podefiniowanych, moje podejrzenie jest, że nawet requirementy mają spisane tylko ołówkiem na karteczce.

  4. maciek pisze:

    Jeśli chodzi o dekodery, to jakiś wynalazek który rok temu dostali rodzice wygrywa: nigdy nie wyłącza dysku twardego. Nigdy nigdy.

    Co do Android TV to zawsze myślałem, że zestaw normalny telewizor + android stick jest o tyle lepszy, że Androida można zmienić i zazwyczaj jest bardziej przyjazny dla użytkownika-majsterkowicza.

    A rozwiązanie samochodowe Toyoty jest takie:
    Jest sobie średniej wielkości klikalny wyświetlacz na środku, który steruje radiem, BT, wyświetla kamerę cofania itd. Jak włączamy silnik to najpierw włącza się radio, potem włącza się wyświetlacz (3 sekundy bez podświetlenia, 1 sekunda z podświetleniem bez obrazu, 2 animacja z logo, 1 zgaszenie podświetlenia bo poprzednio był wyłączony) i sekundę po zakończeniu tej sekwencji zaczyna reagować na przycisk do wyłączania radia. A piosenka jak wsiadałem wieczorem była dużo głośniejsze od ostatniej rano…

    Oczywiście jak włączamy silnik i włączamy wsteczny to wyświetlenie logo jest ważniejsze niż obraz z kamerki.

    • cmos cmos pisze:

      Oczywiście jak włączamy silnik i włączamy wsteczny to wyświetlenie logo jest ważniejsze niż obraz z kamerki.

      Tu akurat znam parę usprawiedliwień (zresztą też mam Toyotę z tym wszystkim). Inicjalizacja programu chwilę trwa, przez ten czas i tak nie da się wyświetlić obrazu z kamerki, więc do wyboru jest czarny ekran albo logo. I tak na pewno inicjalizacja tego co potrzeba do wyświetlenia obrazu z kamery do cofania ma priorytet w stosunku do wszystkiego innego, no może oprócz radia. W samochodach przy tych wszystkich kawałkach embedded są bardzo poważne ograniczenia hardwarowe, nie wszystko da się zrobić tak szybko, jak by się chciało. I tak się na pewno nakombinowali żeby się zmieścić w requirementach producenta samochodu dotyczących czasu inicjalizacji.

      • maciek pisze:

        Ja jestem tylko amatorem i nie piszę oprogramowania na safety-critical wyświetlacze do kamerki z certyfikatem ASIL, ale jeśli wyświetla logo (animowane!) to kontroler zdążył się już dogadać z wyświetlaczem, to niech natychmiast dekoduje ten strumień i wyświetla. Jak będę w dobrym nastroju to mogę zaproponować 100 ms na złapanie synchronizacji strumienia, bo nie wiadomo kiedy kamerka zaczęła nadawać itp.

        Tzn. rozumiem że producent chce mieć mniej pracy i dostać sygnał o włączeniu wstecznego jakimś CANem i kamerkę też tak włączać itp., ale jako użytkownika mnie to ani trochę nie interesuje i zamiast dokupić pakiet za x tysięcy złotych kupię od pana Zhang kamerkę z wyświetlaczem za 100 zł w nowoczesnej technologii PAL którą pan Zenek za drugie 100 zł podłączy pod żaróweczkę wstecznego i będzie działała od razu.

        Może producent powinien dać taką kamerkę i przełączać sygnały do wyświetlacza tranzystorami jeśli tak jak robi nie da się szybko?

        • cmos cmos pisze:

          wyświetla logo (animowane!) to kontroler zdążył się już dogadać z wyświetlaczem, to niech natychmiast dekoduje ten strumień i wyświetla

          Niestety to nie jest takie proste. Na przykład taki kontroler ma zazwyczaj ileś mega RAMu ECC i zanim będzie mógł naprawdę z nim pracować to musi zinicjalizować obszar sum kontrolnych ECC, a to nie idzie aż tak szybko. To nie chodzi na gigahercach jak w pececie, tylko na góra paruset mega. To że widzisz obraz na ekranie to jeszcze wcale nie znaczy, że kontroler jest już zinicjalizowany – to, co trzeba zrobić żeby na ekranie pojawił się statyczny obraz jest robione najpierw, potem trzeba poinicjalizować całą kupę innego sprzętu i mnóstwo różnych tasków (to jest full blown multitasking). Dalej to też nie jest tak, że ten moduł HeadUnit z wyświetlaczem ma bezpośrednio podłączoną kamerkę – kamerka to całkiem osobny kawałek hardware z własnym kontrolerem, i trudno powiedzieć ile on potrzebuje na inicjalizację. Dalej jak się już oba moduły zinicjalizują, to muszą nawiązać połączenie po jakiejś magistrali, pewnie MOST, możliwe że po drodze jest jeszcze jakiś gateway (w sieciach jakie mamy w domach zwany routerem). Itd. itd. Mogę się założyć, że wiele szybciej obrazu z kamery do cofania to wyświetlić się już nie da (my tu też mamy podobne problemy z czasami inicjalizacji).

          Może producent powinien dać taką kamerkę i przełączać sygnały do wyświetlacza tranzystorami jeśli tak jak robi nie da się szybko?

          Teoretycznie można, tylko rozwiązanie analogowe na PALu nie spełni wymagań functional safety i potem rodzina przechodnia przejechanego przy cofaniu zaskarży producenta samochodu do sądu, a producent nie będzie miał dupochronu w postaci certyfikatów bezpieczeństwa i będzie musiał zapłacić milionowe odszkodowanie. Więc żaden producent tego nie zrobi – problem nie jest techniczny, tylko prawny.

          • brii pisze:

            Po co producent stosuje w takim razie w instrukcji dupochron w postaci zapisów, że system kamer nie zastępuje lusterek, korzystanie z niego może spowodować niebezpieczeństwo utraty zdrowia i życia? ;)

            Inna sprawa – da się zrobić ten system tak by działał szybko, u mnie w Nissanie próbowałem dzisiaj jak najszybciej się da wrzucić R (natychmiast po naciśnięciu Start) i zdziwiłem się bo logo ledwo mignęło na ekranie, animacja została przerwana obrazem z kamer. Po wrzuceniu na N obraz z kamery zniknął i było widać, że właśnie kończy się inicjalizacja nawigacji.

          • cmos cmos pisze:

            Po co producent stosuje w takim razie w instrukcji dupochron w postaci zapisów, że system kamer nie zastępuje lusterek

            Ten też jest niezbędny i służy odpieraniu całkiem innych zarzutów. Tu chodzi o to, żeby nie było że obietnice są bez pokrycia. Ostatnio nawet Musk się tego nauczył i nie będzie już obiecywał „autopilota”. Parę osób musiał zabić żeby się dowiedzieć, że „klasyczni” producenci samochodów wcale nie są od niego głupsi. A nawet mądrzejsi.

            da się zrobić ten system tak by działał szybko

            Sporo zależy od koncepcji producenta i postawionych wymagań co do czasów inicjalizacji. Jak każe zrobić żeby chodziło szybko, to się coś da zrobić, ale może trochę więcej kosztować.

  5. red1grzeg red1grzeg pisze:

    Nie wiem ile prawdy jest w tym artykule, ale przynajmniej jeden z optymistycznym przekazem, ze jednak można:
    https://www.fastcompany.com/28121/they-write-right-stuff

    • cmos cmos pisze:

      No pewnie że można, problem jest tylko w tym żeby chciało i managerstwo i programiści.

      • krwawykrolik pisze:

        Pytanie ile taki sposob pisania software’u kosztuje.

        • cmos cmos pisze:

          Zrobienie od razu porządnie jest znacznie tańsze niż paniczne szukanie błędów tuż przed końcem projektu bo klient się zdenerwował i chce zerwać kontrakt. U nas umowy są takie, że jak projekt nie wyjdzie, to klient będzie przez rok wkładał do samochodów cluster od droższej wersji, a różnicą w cenie obciąży nas. Przy aktualnym projekcie dla BMW mówimy o stosunkowo niewielkich ilościach rzędu 25.000 rocznie, więc by mocno bolało, ale firma przeżyje. Ale jak by trafiło coś takiego w MQB, to przy pięciu milionach sztuk na rok lepiej sobie tego nawet nie wyobrażać.
          Oczywiście w consumer electronics taka sytuacja nie występuje, bo wszyscy mają jakość tego softu bardzo, ale to bardzo głęboko, a telewizor LCD jeszcze nikogo nie zabił.

          • krwawykrolik pisze:

            „robienie od razu porządnie jest znacznie tańsze niż paniczne szukanie błędów tuż przed końcem projektu bo klient się zdenerwował i chce zerwać kontrakt.”

            W przypadku softu dla NASA oni dobrze wiedza, ze klient poczeka tyle, ile trzeba.

          • cmos cmos pisze:

            W przypadku softu dla NASA oni dobrze wiedza, ze klient poczeka tyle, ile trzeba.

            No nie wiem, dla wielu misji okna czasowe są bardzo sztywne a następne nawet dopiero po kilkudziesięciu latach.

  6. krwawykrolik pisze:

    Bardzo ciekawe. M.in. dlatego odwlekam jak moge kupno „inteligentnego telewizora” czy „inteligentnej lodowki”.

    Od siebie dodam, ze niechlujnie i w nieprzemyslany sposob napisanego oprogramowania nie da sie wyjasnic argumentem „slabo oplacani programisci pod presja czasu”. Pracuje w branzy w ktorej programisci sa *bardzo dobrze* oplacani (pensje rzedu $500k rocznie nie sa czyms niezwyklym). Pracuje w firmie w ktorej dzial IT ma duza niezaleznosc od „produkcji” (czytaj: traderow). Wielokrotnie nasze „feature requests” sa odrzucane z uzasadnieniem „nie mamy czasu, wroccie pozniej albo powiedzcie czego innego mamy nie robic zeby to zrobic”. Czyli wydawaloby sie, ze mamy wlasciwe podejscie do sprawy, bo programisci nie sa przeciazeni, prawda? Oprocz tego stosuja te wszystkie Agile, wierza w unit testing, itd. Wiec efektem koncowym powinno byc wydajne, poprawne, dobrze udokumentowane oprogramowanie. A guzik.

    1. dokumentacja: szef zespolu programistow powiedzial ze szczegolowej dokumentacji nie bedzie bo „programisci nie lubia pisac dokumentacji”
    2. wydajnosc: musielismy sie dlugo bic o to zeby w sofcie do wysylania zlecen na gielde (gdzie naprawde liczy sie kazda mikrosekunda) byl kod do mierzenia wydajnosci, bo „przeciez ja wiem ze moj kod jest zoptymalizowany a jak dodam procedury do mierzenie wydajnosci, to go spowolnie” (serio!)
    3. poprawnosc: przyzwyczailem sie juz do tego, ze dostaje do uzytku soft ktory zostal tylko pobieznie przetestowany, bo przeciez nigdzie sie tak dobrze nie testuje, jak w produkcji, prawda?

    Tak wiec problem tkwi nie tylko w mentalnosci zarzadzajacych programistami. Rowniez w mentalnosci samych programistow. Ta branza jest pelna ludzi o mentalnosci nastolatkow.

    • cmos cmos pisze:

      Mentalność programistów jest pochodną mentalności zarządu. Jak zarząd będzie rozumiał problem, wymagał użycia właściwych metod i starał się je naprawdę wdrożyć, to metody powoli się pojawią i zaczną działać. A jak zarząd chce tylko żeby checklista klienta była we wszystkich punktach zacheckowana, to lista będzie zacheckowana a programiści będą mieli wszystko gdzieś. Proste.

      • krwawykrolik pisze:

        Zgadzam sie, ze przyklad idzie „z gory”. Ale poziom, z jakiego nacisk zarzadu musi podnosic stereotypowa zaloge IT jest duzo nizszy niz w np. inzynierii ladowej. Z roznych powodow. Miedzy innymi z takich, ze w tej branzy od dawna brakuje autentycznego postepu technologicznego, ludzie tylko jada na fali taniejacej pamieci, przyspieszajacych procesorow i zwiekszajacej sie liczby rdzeni. Zwl. w obszarze „inzynierii oprogramowania” fakt, ze biblia nadal pozostaje ksiazka napisana w 1975 roku mowi sam za siebie.

        Powiedz mi, czy w jakiejs innej branzy dorosli ludzie sa gotowi odwalac taka szopke? https://medium.com/@william.liu/daily-plank-meeting-732456e6f7b1#.o6l4n187l Przeciez to jest a) uwlaczajace profesjonalistom, b) dyskryminujace wobec ludzi niepelnosprawnych albo w zlej kondycji fizycznej. To ja juz wole czasy IBM i „It is a syntax error to write FORTRAN while not wearing a blue tie”.

        • cmos cmos pisze:

          Zwl. w obszarze „inzynierii oprogramowania” fakt, ze biblia nadal pozostaje ksiazka napisana w 1975 roku mowi sam za siebie.

          Ale ta książka jest aktualna w prawie dowolnej branży.

          I nie zgadzam się co do braku postępu w „inżynierii oprogramowania”, rzuć może okiem na przykład na różne rzeczy które dzieją się w programach do modelowania i generatorach kodu. W tej chwili możesz mieć już program do modelowania w UML zintegrowany z Eclipse i różnymi generatorami i to za darmo. A jak jest w Eclipsie to integruje się też z mnóstwem innych rzeczy. Co otwiera masę nowych możliwości.

          Powiedz mi, czy w jakiejs innej branzy dorosli ludzie sa gotowi odwalac taka szopke?

          Bankowość? Ubezpieczenia? Marketing mniej lub bardziej bezpośredni?
          O takie rzeczy w IT i tak podejrzewam raczej firmy robiące właśnie w tych branżach, ale handlowcom będą robić to samo.

          • krwawykrolik pisze:

            „I nie zgadzam się co do braku postępu w „inżynierii oprogramowania”, rzuć może okiem na przykład na różne rzeczy które dzieją się w programach do modelowania i generatorach kodu. W tej chwili możesz mieć już program do modelowania w UML zintegrowany z Eclipse i różnymi generatorami i to za darmo.”

            I co on daje? Jak taki generator pomoglby usunac/uniknac bledu przez ktory nie moge wyslac zlecenia na darkpool po cenie „posrodku” poziomow ceny z glownego rynku, bo zaokraglanie liczb do 32-bitowego float powoduje dzielenie przez zero i wykrzaczenie sie algorytmu?

            „Bankowość? Ubezpieczenia? Marketing mniej lub bardziej bezpośredni?”

            Bankowosc odhumanizowuje programistow dlugogodzinnymi zebraniami i mnostwem biurokracji, ale nie takimi szopkami. Tzn. nie wiem jak jest w detalicznej, ale tak to wyglada w inwestycyjnej. Z tym ze im blizej trading floor, tym bardziej kultura zmienia sie na „show me the money”, co jest bardzo odswiezajace.

            „O takie rzeczy w IT i tak podejrzewam raczej firmy robiące właśnie w tych branżach, ale handlowcom będą robić to samo.”

            Nieeee. To startupy. Najbardziej programistow odmozdzaja startupy webowe.

            Zupelnie odrebna kategoria upadku intelektualnego branzy IT sa infiltrujacy ja Social Justice Warriors, ale to juz temat na innego ranta.

          • cmos cmos pisze:

            I co on daje? Jak taki generator pomoglby usunac/uniknac bledu przez ktory nie moge wyslac zlecenia na darkpool po cenie „posrodku” poziomow ceny z glownego rynku, bo zaokraglanie liczb do 32-bitowego float powoduje dzielenie przez zero i wykrzaczenie sie algorytmu?

            No zaraz, to jest tylko narzędzie, żadne narzędzie samo nic nie załatwi. Trzeba go jeszcze porządnie użyć. W przypadku o którym piszesz to jest brak porządnych unit testów – test służący do zacheckowania checklisty to nie jest porządny test. A tak w ogóle to brak obsługi dzielenia przez zero powinien być wykryty już wcześniej przy code review.

            Nieeee. To startupy. Najbardziej programistow odmozdzaja startupy webowe.

            Noale startupy webowe to jest branża marketingowa, czyż nie? (nie mów mi że social media to nie marketing)

    • cmos cmos pisze:

      I jeszcze:
      Oprocz tego stosuja te wszystkie Agile, wierza w unit testing, itd.

      Mylisz zacheckowaną listę z wiarą. U nas też każdy moduł ma module testy. Co najmniej połowa z nich powstaje dopiero po oddaniu softu na produkcję, reszta krótko przed. Bez sensu, zbędna robota, ale klient wymaga – więc dostaje.
      A ja jestem w całej fabryce jedyny, który aktualizuje module testy przed każdym releasem modułu. Ale ASIL jest, certyfikaty na koniec też. Wszystko kłamstwo.

  7. krwawykrolik pisze:

    „Noale startupy webowe to jest branża marketingowa, czyż nie? (nie mów mi że social media to nie marketing)”

    Sa jeszcze startupy od hazardu online, od fintech (w tym roznej masci wydrwigrosze naciagajacy ludzi na „uzyjemy blockchaina i bedzie super zajebiscie i bezpiecznie i tanio”…

    Co mnie tez przeraza: ile w te firemki idzie dotacji UE.

    • cmos cmos pisze:

      Sa jeszcze startupy od hazardu online, od fintech (w tym roznej masci wydrwigrosze naciagajacy ludzi na „uzyjemy blockchaina i bedzie super zajebiscie i bezpiecznie i tanio”…

      Jak dla mnie, to wszystkie te odmiany podpadają pod branżę „marketing”.

  8. krwawykrolik pisze:

    „Jak dla mnie, to wszystkie te odmiany podpadają pod branżę „marketing”.”

    OK, czyli dla Ciebie software dzieli sie na defeat devices z Volkswagena i marketing :D

    • cmos cmos pisze:

      Dla mnie cała działalność dzieli się na tworzenie jakiegoś badziewia i wciskanie tego badziewia (mój syn jak był mały mówił na taką działalność „namuszanie”). Są oczywiście przypadki graniczne, kiedy trudno oddzielić tworzenie od namuszania (jak przy tym hazardzie online albo social media), ale jak namuszamy to jest marketing. Zła definicja?

      • krwawykrolik pisze:

        Zla, bo wpada w nia kazdy korporacyjny produkt w kapitalizmie.

        • cmos cmos pisze:

          Nie każdy, tylko ten który służy do prowadzenia wciskania. Jak robię w clusterach albo – jak kiedyś – w urządzeniach telekomunikacyjnych – to robię w tworzeniu badziewia. Jak robiłem kiedyś przy systemie CRM albo przy systemie sprzedaży biletów to robiłem w marketingu.
          Klucz jest: Czy to co robimy sprzedajemy, czy też używamy tego do sprzedaży czego innego.

          • krwawykrolik pisze:

            Czyli jak robisz wozy dostawcze, to pracujesz w marketingu?

          • cmos cmos pisze:

            Wyraźnie nie łapiesz. Jak robię wozy dostawcze i sprzedaję je, to robię w produkcji. Jak w firmie od badziewiatorów robię specjalne wozy dostawcze które ta firma będzie używała do sprzedawania swoich badziewiatorów na Weihnachtsmarktach, to robię w marketingu.

Skomentuj i Ty

Komentowanie tylko dla zarejestrowanych i zalogowanych użytkowników. Podziękowania proszę kierować do spamerów