1. Jeżeli mężczyzna zaczyna wyrażać uwagi w rodzaju "żyjemy w epoce informacji", to znaczy, że chce kupić komputer.
2. Jeżeli mężczyzna o tym nie wspomina, to znaczy, że już go kupił.

1. W czym problem? Nic nie widzę. Zostaw mnie w spokoju.
2. Lubię grzebać w problemach nie do rozwiązania.
3. Który problem? Nie, nie rozwiązałem go, był dla mnie zbyt nużący. Zostaw mnie w spokoju.

1. Mężczyźni kochają komputery, ponieważ komputery wykonują to, co się im poleci. I jest im obojętne, czy jest to zgodne z tym, czego naprawdę chcieli.
2. Zaimkiem "on" jest określany zarówno mężczyzna, jak i komputer.

1. Czas, który maniak komputerowy zyska dzięki automatyzacji zadań, jest odwrotnie proporcjonalny do czasu programowania. Zyskany czas Z można określić następującym wzorem: Z=1/1+(P*H)
   gdzie P - czas potrzebny na programowanie, H - częstotliwość występowania zadania. W najlepszym przypadku nie zyskuje nic.
2. Czas samodzielnej pracy komputera maniak komputerowy wykorzysta do tego, by nieruchomo obserwować sprawność jego działania.

3.2 Programista

• Założenie podstawowe:
  - Żaden program nigdy nie będzie funkcjonował całkowicie poprawnie.
• Wniosek pierwszy:
  - Przekleństwa są jedynym językiem, który programiści opanowują perfekcyjnie.
• Wniosek końcowy:
  - Komputer wykona to, co zaprogramujesz, a nie to, czego od niego oczekujesz.
• Przypadek programistów-hobbystów:
  - Oczywiste błędy zauważysz dopiero przy pierwszej publicznej prezentacji własnego programu.
• Diagnoza Axela:
  - Nic tak korzystnie nie wpływa na program, jak brak procedur kontrolnych.
• Wniosek Axela:
  - Jeżeli nie wiesz, co czynisz, rób to w sposób elegancki.
• Pierwsze Prawo Specjalizacji Informatycznej:
  - Każdy programista przybywający z innego miasta jest fachowcem.
• Drugie Prawo Specjalizacji Informatycznej:
  - Idealny fachowiec wie absolutnie wszystko o niczym.
• Cykl rozwojowy programu według Clark'a:
  1. To jest niemożliwe - nie będę przecież marnotrawił mojego czasu.
  2. To jest możliwe, ale nieopłacalne.
  3. Przecież od początku mówię, że moja idea jest genialna.
  4. Czy ktoś może mi wyjaśnić, dlaczego idea ta jest ogólnie znana?
• Aksjomat Mexner'a o pamięci operacyjnej:
  - Każdy kod programowy dąży do kompletnego wypełnienia całej, wolnej przestrzeni pamięci operacyjnej.
• Rozszerzenie Cerbera:
  - Jeżeli wykasujesz wszystkie komentarze i napiszesz pogmatwane procedury na nowo - krócej i efektywniej, to na koniec otrzymasz program dłuższy, wymagający więcej pamięci, przerastający możliwości kompilatora, a ponadto niefunkcjonujący.
• Prawa pracowni:
  1. Wszystkie powierzchnie horyzontalne zostaną w krótkim czasie pokryte rupieciami.
  2. Dyskietki leżą "pod spodem"
  3. Pilnie potrzebny projekt programu znajduje się "niewiadomogdzie"
  4. Popiół z papierosów i kawa znajdują się gdzieś "pomiędzy"
• Ochrona przed katastrofą:
  - Kto wykazuje zadowolenie, gdy program zawodzi, ten zna kogoś, na kogo można przerzucić odpowiedzialność.
• Osiem Praw Szanownego Klienta:
  1. Klientowi nigdy nie przyjdzie na myśl, ile kosztuje projekt, ale ile można na nim zaoszczędzić.
  2. Jeżeli udało Ci się wprowadzić w programie wymagane przez klienta poprawki, wtedy on z nich rezygnuje.
  3. Żaden klient nie wie, czego właściwie chce.
  4. Każdy klient wie dokładnie, czego nie chce.
  5. Żaden klient nie chce tego, co już masz gotowe.
  6. Nie wie także, co chciałby mieć zamiast tego.
  7. Klient, który najmniej płaci, marudzi majwięcej.
  8. Klient żąda większych zmian dokładnie wtedy, kiedy produkt jest już gotowy.
• Uwagi o opóźnionym błędzie:
  1. Decydujący błąd odkryjesz dopiero wtedy, kiedy program działa 6 miesięcy bez zastrzeżeń.
  2. Błąd ten zafałszuje albo zniszczy dokładnie te dane, które nie są w żaden sposób do odtworzenia i które są najistotniejsze dla funkcjonowania systemu.
  3. Kod źródłowy zniknął w międzyczasie i jest nie do odnalezienia.
• Prawo Peter'a:
  - Program rozwija się do czasu przekroczenia możliwości programisty, który ma go nadal rozwijać.
• Rozszerzenie prawa Peter'a:
  - Prace wstępne przeprowadzane są zawsze przez osoby osiągające szczyty swoich niemożności.
• Przesłanka o niezmiennym stresie:
  - wysiłek * czas = constans
• Rozszerzenie 1:
  - Jeżeli masz dużo czasu, pracujesz niewiele.
• Rozszerzenie 2:
  - Wraz ze zbliżaniem się terminu pracy, wysiłek zmierza do nieskończoności.
• Rozszerzenie 3:
  - W "ostatniej minucie" rozwiązujesz najistotniejsze problemy.
• Ogólne prawa koncepcyjne:
  1. Nigdy nie masz czasu na wniesienie poprawek, ale zawsze masz czas napisać program od nowa.
  2. Zmiany w projekcie programu trwają tak długo, że nie ma już czasu na poprawki w samym programie.
• Prawo Ridigera:
  - W każdym programie błędy wykazują skłonność do występowania w tym miejscu, które sprawdzasz jako ostatnie.
• Syndrom jakości:
  - Każdy program, który się dobrze zaczyna, kończy się źle. Program, który zaczyna się źle, kończy się przerażająco.
• Wniosek 1:
  To co wygląda łatwo, jest trudne.
  To, co wygląda trudno, jest niemożliwe.
  To, co wygląda na niemożliwe potrafi rozwiązać nawet Twoja teściowa i to bez pomocy komputera.
• Wniosek 2:
  - Rzeczywistość może być zawsze gorsza od najbardziej pesymistycznych wyobrażeń.
• Lemat o zespole programistów:
  - W zespole programistów każdy ma genialny plan rozwiązania problemu. Wszystkie plany wzajemnie się wykluczają i żaden nie prowadzi do poprawnego rozwiązania.
• Prawa procedur:
  1. Każda procedura, do której może wkraść się błąd, będzie go zawierać.
  2. Także w procedurach, które muszą być bezbłędne, znajdują się błędy.
• Wniosek 1:
  - Każdy błąd umiejscowi się tam, gdzie zostanie najpóźniej odkryty i gdzie wyrządzi maksymalne szkody.
• Wniosek 2:
  - Każdy błąd ujawni się dopiero po przeprowadzonej kontroli programu.
• Wniosek 3:
  - Jeżeli błąd został wcześniej dostrzeżony, to ustalenie jego przyczyny jest niemożliwe.
• Prawo końca:
  - Napisanie programu trwa dwukrotnie dłużej, niż zaplanowano.
• Lemat o adaptacji:
  - Skonfigurowanie programu na innym komputerze powoduje, że nie funkcjonuje on na komputerze, dla którego został pierwotnie napisany. Próba ponownego dostosowania programu do pierwotnego komputera powoduje, że nie funkcjonuje on na żadnym z tych dwóch komputerów.
• Teoria mnożenia:
  - Liczba osób w zespole programistycznym ma tendencje wzrastające niezależnie od ilości pracy.
• Uzupełnienie:
  - Jeżeli uczynisz komuś przysługę, to jesteś od zaraz trwale za to odpowiedzialny.
• Wartość graniczna według Robbins'a:
  - Minimalne wymagania programu są zarazem maksymalnymi dla danego komputera.
• Czynnik niepewności Hartz'a:
  - Niejasność jest wielkością niezmienną.
• Prawo zmaian:
  - Im mniejsza pozornie korekta tym większy nakład pracy przy jej wprowadzaniu.
• Rozszerzenie:
  - Nic nie jest na tyle proste by nie można było tego wykonać źle.
• Reguła przechwytywania:
  - Jeżeli napiszesz procedurę, która zapobiega pojawianiu się błędnych wartości, to zawsze znajdzie się użytkownik, który ją pominie.
• Aksjomat o wyszukiwaniu informacji:
  - Inforamcja, która jest najbardziej potrzebna, jest najmniej dostępna.
• Uwaga o pomysłowości użytkownika:
  - Jeżeli stwierdzono, że istnieją 4 różne możliwości doprowadzenia programu do krachu, i wszystkie 4 się zablokuje, wtedy użytkownik znajdzie piątą metodę.
• Uogólnienie:
  - Nie ma programów całkowicie idiotoodpornych.
• Prawo dokumentacji:
  - Nikt jej nigdy dokładnie nie czyta.
• Aksjomat o relacji pomiędzy podręcznikiem a programem:
  - Jeżeli wytłumaczyłeś coś tak dokładnie, że nie można tego zrobić błędnie, zawsze znajdzie się ktoś, kto to potrafi.
• Dogmat o podstępnym algorytmie:
  1. Niezależnie od tego, co się popsuje, wszystko będzie dobrze wyglądać.
  2. Ci, których poprosisz o pomoc, nic nie zauważą.
  3. Ten, który pojawi się z nieproszon radą, odkryje natychmiast wiele błędów.
  4. Niezależnie od tego, co się psuje, zawsze istnieje ktoś, kto już wcześniej wiedział, że tak będzie.
  5. Nie wierz w cuda. Zdaj się na nie.
• Uogólnienie:
  - Skrót jest najdłuższą drogą pomiędzy dwoma punktami.
• Ogólna teoria algorytmów:
  1. Każda formuła i każda stała muszą być traktowane jako zmienne.
  2. Najważniejsze punkty algorytmu mają największą szansę na to, by zostać pominięte lub zapomniane.
  3. Jeżeli tylko jakiś moduł funkcjonuje perfekcyjnie, to nie potrafi współpracować z innymi modułami.
  4. Nic się nie kończy w sposób zaplanowany.
• Teoretyczne Prawo Kompatybilności Języków Programowania:
  1. Założenie: Nawet, gdyby udało się opracować taki język programowania, który zastąpiłby wszystkie dotychczasowe, to zawsze znajdzie się dostatecznie dużo producentów, którzy będą rozpowszechniać własną wersję specjalną tego jednolitego i uniwersalnego języka.
  2. Dedukcja: Ta własna wersja specjalna nie będzie kompatybilna z niczym innym oprócz samej siebie.
  3. Ograniczenie: Niekompatybilność będzie się oczywiście powiększać wraz z kolejnymi edycjami wersji specjalnej.
• Zastosowanie Praktycznej Kompatybilności Języków Programowania:
  1. Ponieważ nie ma jednolitego języka programowania, panuje totalny rozgardiasz.
  2. Odczuwasz to sam najdotkliwiej.
• Reguła 90-90-10
  1. Na pierwsze 90% programu potrzeba 10% przeznaczonego na jego realizację czasu.
  2. Pozostałe 10% programu wymaga 90% przeznaczonego na jego realizację czasu.
  3. Rozpoczynasz zawsze od pozostałych 10%.
• Reguła Klienta (na bazie 90-90-10)
  - 10% od których rozpoczynasz pracę, stanowią te procedury, które w ostatecznym rozrachunku zostaną usunięte na życzenie klienta.
• Prawo Gray'a:
  - Na realizację n+1 zadań będziesz miał tyle samo czasu, co na realizację n zadań.
• Rozszerzona zasada Epstein'a - Heinsenberga:
  - Z paramertrów czas, pieniądze i zadanie tylko dwa dadzą się określić jednoznacznie w danym momencie:
  1. Jeżeli znane są zadanie i czas, to określenie kosztów całkowitych jest niemożliwe.
  2. Jeżeli znane są czas i wolne moce przerobowe, to nikt nie wie, jaką część zadania należy wykonać.
  3. Jeżeli ktoś potrafi określić wszystkie trzy parametry, to znaczy, że nie zajmuje się tematyką formułowania zadań.
• Postulaty:
  1. Wyjątki są liczniejsze od reguł.
  2. Od wszystkich uznanych wyjątków istnieją wyjątki.
  3. Jeżeli opanowałeś już wyjątki, to nie pamiętasz, jakich reguł one dotyczą.
• Prawo Irytacji
  - Po skasowaniu pliku, co do którego jesteś pewien, że już nigdy i do niczego się nie przyda, okaże się, że jest on w krótce niezbędnie potrzebny.
• Prawo struktury kompilatora:
  - Im więcej poleceń strukturalnych zamieścisz w swoim programie, tym mniej będzie w stanie przetłumaczyć kompilator.
• Uzupełnienie prawa struktury kompilatora:
  - Przetłumaczone zostaną jedynie struktury błędne.
• Prawo Konwersji Znaków:
  1. stan początkowy jest nie do odtworzenia.
  2. prawidłowo napisany tekst pojawi się tylko wtedy, kiedy napiszesz go ręcznie.
• Aksjomat Helt'a:
  - Żadem rozkaz nie jest na tyle krótki, żeby przy jego pisaniu nie pomylić się co najmniej trzykrotnie.
• Spostrzeżenie Programisty Aplikacyjnego:
  Założenie: Użytkownik wykonuje wszystko błędnie.
  1. Na polecenie "NAPISZ TAK lub NIE" wpisuje "TAK lub NIE"
  2. Na polecenie "Wciśnij ENTER" wpisuje "ENTER"
  3. Na polecenie "Naciśnij dowolny klawisz" naciska klawisz SHIFT, albo ESCAPE.
• Spostrzerzenie Mull'a o rejestrach:
  1. Jeżeli zapisujesz coś w jakimś rejestrze, i dokładnie zapamiętujesz, co dana oznacza, to zapominasz, który to był rejestr.
  2. Jeżeli zapamiętasz rejestr, to już go nigdy więcej nie musisz używać.
• Reguła pp (poniedziałek - piątek):
  - Program oddany użytkownikowi w piątek wraca do autora w poniedziałek.
• Dwa kardynalne błędy firm software'owych:
  1. Jeżeli jakiś problem nie istnieje od dawna, to wciąż istnieją ludzie, którzy pracują nad jego rozwiązaniem.
  2. Przydzielenie większej ilości ludzi do realizacji powalającego ogromem projektu opóźnia termin jego zakończenia.

3.3 Użytkownik.

• Prawo logiki statystycznej:
  - Zgodnie z wynikami badań rynku 80 procent użytkowników programów stosuje tylko 20 procent ich funkcji.
• Pierwsza konsekwencja logiczna:
  - 20 procent użytkowników wymaga 80 procent funkcji, których program nie posiada.
• Druga konsekwencja logiczna:
  - Należysz z pewnością do tych 20 procent.
• Wyjaśnienie:
  - Programista jest ostatnią osobą, która chciałaby stosować własny program.
• Uogólnienie:
  - Kiedy już opanujesz dany program, to pojawi się jego nowa wersja, czyniąc poprzednią zupełnie przestarzałą.
• Reguła kupna:
  - Jeżeli po długotrwałych poszukiwaniach kupiłeś już komputer, jego cena w następnym tygodniu będzie o połowę mniejsza. Ewentualnie pojawi się inny model, który za tę samą cenę oferuje podwójną moc obliczeniową.
• Gwarancja:
  1. Zapłacenie rachunku powoduje utratę uprawnień gwarancyjnych.
  2. 180-dniowa gwarancja gwarantuje tylko tyle, że 181-go dnia komputer eksploduje.
• Aksjomat o rozszerzaniu pamięci operacyjnej:
  - Pamięć operacyjna każdego komputera jest niewystarczająca. Jeśli ją jednak rozszerzysz, to pojawi się nowa wersja programu, która wymaga co najmniej 10 kilobajtów pamięci więcej od tej, którą dysponujesz.
• Łatwowierny klient ("Odpowiedzi sprzedawcy na krytyczne pytania klientów"):
  1. "To wczoraj jeszcze działało"
  2. "Oczywiście, że będzie to można później zainstalować"
  3. "Nasz specjalista od tego zagadnienia jest właśnie na urlopie"
  4. "Oczywiście, że prowadzimy serwis gwarancyjny"
  5. "Nie, do tej ceny nie dochodzą już żadne koszta dodatkowe"

Komputerowe prawa Murphy'ego