Przejdź do głównej zawartości

Tylko Wykonywałem Polecenia


Jest rok 2006. Zarząd Volkswagena wie, że ich silnik diesla nie spełni amerykańskich standardów emisji. Więc poprosili inżynierów o rozwiązanie nie wymagające przeprojektowania silnika.
Wyobraź sobie scenę spotkania w salce konferencyjnej. Co było powiedziane? Na co się zgodzili? Możemy nigdy nie poznać wszystkich szczegółów; ale jasne jest to, że zarząd poprosił inżynierów o znalezienie sposobu oszukania testów emisji.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Teraz pomyśl o tych inżynierach. Jaki fajny mieli problem do rozwiązania. No, naprawdę! Wyobraź sobie ile zabawy, może być w wymyśleniu jakiegoś sprytnego sposobu oszukania testów emisji. Jak byś to zrobił? Czy zrobiłbyś to w sprzęcie? Czy zrobiłbyś to w oprogramowaniu? Jak byś wykrył, że jesteś na stanowisku testowym?
"Czekajcie!" - powiedział jeden z geeków. Rozejrzał się po pokoju, upewniając się, że wszystkie oczy patrzą na niego, wykorzystując chwilę ciszy do perfekcji. "Na stanowisku testowym, ... koła się kręcą, ... ale samochód się nie porusza."
"O, WOW!" - mówi inny inżynier. "Czy nie moglibyśmy użyć GPS-a do sprawdzenia czy samochód się porusza"?


Wyobraź sobie tę burzę mózgów, te "dobre" pomysły. Te fajne uczucie, kiedy wiesz, że jest naprawdę sprytne rozwiązanie tego problemu.
Wyobraź sobie, jak zadowolony był zarząd z tym naprawdę fajnym rozwiązaniem inżynieryjnym. Wyobraź sobie, jak dumni byli inżynierowie.
...
I teraz, jeden z nich, James Liang, idzie do więzienia. Będą inni, którzy za nim pójdą. Linią ich obrony było, oczywiście, to, że oni tylko wykonywali polecenia. Oni tylko chcieli utrzymać swoje miejsca pracy - chcieli być pewni, że mogą zapewnić utrzymanie swoim rodzinom. Ale ta linia obrony nie zadziałała. Zostali wtrąceni do więzienia. Wiele lat w kiciu:
"Ten 40-miesięczny wyrok więzienia był [] najwyższym możliwym pięcioletnim okresem za tego typu przestępstwa. Prawnik Liang'a prosił o zamianę wyroku więzienia na okres aresztu domowego tłumacząc, że jego klient tylko wykonywał rozkazy w duchu 'źle pojętej lojalności dla swojego pracodawcy.'"
No i grzywna. Spora grzywna za spore partactwo.
"Mimo, że prokuratorzy federalni żądali tylko 20'000$ grzywny, sędzia stanu Michigan Sean Cox zdecydował uczynić przykład z tego komputerowca i nakazał zapłatę 10 razy większą, jako przestrogę dla innych inżynierów i zarządzających z branży motoryzacyjnej."
Inżynierowie, zapiszcie sobie, proszę: Wasz pracodawca Was nie obroni. Wykonywanie swoich obowiązków nie oznacza ślepego podążania za poleceniami. Sądy będą wymagać od Was wysokich standardów etycznych, nawet gdy pracodawca nie będzie ich od Was wymagał.



Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Komentarze

  1. Ale ten wyrok nie wynika z faktu, że pracodawca nie broni, ale z faktu, że według prawa odpowiada ten kto daną rzecz zrobił.
    Dlatego też Liang nawet nie musiał nawet wiedzieć co dokładnie programuje i tak by popełnił przestępstwo.

    OdpowiedzUsuń
  2. Uważam, że Ty, ja i większość w tej branży jest na tylko inteligentna, że zawsze wie co robi. Wydaję mi się, że Wujek Bob używa argumentu o pracodawcy po to, by przekonać nieprzekonanych, że w dłuższej perspektywie nie opłaca się robienie rzeczy złych.

    OdpowiedzUsuń
    Odpowiedzi
    1. Ale dlaczego koniecznie złych? Ile razy otrzymując specyfikację jakiejś funkcjonalności zastanawiasz się czy zaimplementowanie tego jest zgodne z prawem?
      Powiem więcej w wielu przypadkach musimy zaufać, że nasz pracodawca nie wpuszcza nas na tego rodzaju minę, bo nie jesteśmy specjalistami w zakresie takiego czy innego prawa.

      Usuń

Prześlij komentarz

Popularne posty z tego bloga

Kursy IT na Pluralsight. Dlaczego warto?

Bardzo sobie cenię kursy na Pluralsight. Mam wrażenie, że każdy kurs, który przeszedłem na tej platformie, w dużym stopniu podniósł moje zdolności. Wiem, dostęp do tej platformy nie jest tani, ale w mojej ocenie warty swojej ceny. To nie jest reklama, ale forma entuzjazmu jaki mam do tej formy samodoskonalenia. O to kilka punktów pokazujących ofertę tego serwisu i dlaczego warto skorzystać: Pluralsight to kursy z Javascript, C#, Java, Angular, Python, MySQL i wielu innych technologii i umiejętności. Kursy na Pluralsight w większości mają wyższą jakość niż te, które możemy znaleźć na przykład na YouTube. Są wyselekcjonowane, mają wysoką jakość dźwięku i obrazu. Często wgryzają się głęboko w dany problem daleko poza standardowe „Hello World” danej technologii. Twórcy Pluralsight to często osoby znane ze świata IT i konferencji branżowych, jak: Scott Hanselman, Microsoft John Somnez, SimpleProgrammer.com John Skeet, Google Pluralsight udostępnia funkcjonalność ścieżek – paths.

Algorytm Dijkstry

Byłem jednego dnia na SCNA , i ktoś zagadnął mnie o TDD i algorytm Dijkstry . Zastanawiał się, czy można znaleźć sekwencję testów, która zaprowadzi do tego algorytmu. To wyglądało mi na fajne, krótkie ćwiczenie, więc zdecydowałem się spróbować. Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony: https://blog.cleancoder.com/uncle-bob/2016/10/26/DijkstrasAlg.html Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta. Zacząłem tak, jak zwykle; przez odpalenie ograniczonego przypadku testowego. public class MinPathTest { @Test public void nothing() throws Exception { } } Algorytm Dijkstry jest prostym sposobem znajdowania najkrótszej drogi w grafie o krawędziach mających konkretną długość. Podając węzeł startowy i końcowy, algorytm wskaże, jaka jest najkrótsza ścieżka i jaka jest jej długość. A więc już od samego początku są ciekawe decyzje do podjęcia. W jaki sposób p

Podstawy Programowania Funkcyjnego Epizod 3

Czy wszystkie Zasady Się Zmieniają? Kiedy tylko zaczynamy używać nowego paradygmatu , porównujemy z nim nasze dotychczasowe zasady i nawyki. Pytamy siebie czy te wszystkie zasady i nawyki są poprawne w kontekście tego nowego paradygmatu. Rozważ, dla przykładu: Test Driven Development . Czy nadal jest poprawne w Programowaniu Funkcyjnym? Jeżeli tak, to jak się do tego zabierzesz? Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina z dnia 07 stycznia 2013 ze strony: https://blog.cleancoder.com/uncle-bob/2013/01/07/FPBE3-Do-the-rules-change.html Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta. Aby odpowiedzieć sobie na to pytanie spróbujmy napisać prosty funkcyjny program: Word Wrap (zawijanie tekstu). Wymagania są proste. Mając napis złożony ze słów, oddzielonych pojedynczymi spacjami