Absurdalne prawa świata oprogramowania

Czy zastanawiałeś się kiedyś, dlaczego inteligentni ludzie, tacy jak programiści, tak często to schrzanili? Są ludzie, którzy to zrobili. W tym poście sprawdzamy niektóre z niepisanych praw, które opisują zachowanie profesjonalistów informatyki.

Moim pierwszym komputerem był Commodore 64. Prawie 30 kb pamięci RAM było przeznaczone na system, pozostawiając 32 kb na przetwarzanie tekstu, gry, księgowość firm rodzinnych i prawie wszystko, co robię z posiadanym przeze mnie komputerem o pojemności 6 GB. To pozostawia otwarte pytanie Czy dzisiejszy sprzęt odpowiada potrzebom oprogramowania, czy też oprogramowanie zużywa więcej zasobów sprzętowych, ponieważ są one dostępne?

Szczerze mówiąc, gry nie są takie same, grafika nie jest tej samej jakości, a oglądanie filmów i słuchanie muzyki byłoby niemożliwe. Jednak nie można powstrzymać się od myślenia są programy, które publikują wersje i zużywają coraz więcej zasobów, nie wnosząc nic nowego.

Oto przyczyny.

Prawo Zawinsky'ego

Deweloper Netscape, Jamie Zawinsky, argumentował to Każdy program zawiera funkcje, dopóki nie jest w stanie odczytać wiadomości e-mail. Jeśli mu się to nie uda, zostaje zastąpiony przez kogoś, kto jest w stanie to zrobić.

Kiedy to powiedział, żartował, że miał na myśli programy, które pierwotnie nie były przeznaczone jako klienci poczty e-mail. Przestało być zabawne, gdy odkryto, że wiele aplikacji w Google Play prosiło o pozwolenie na dostęp do komponentów telefonu i danych użytkownika, których nie musiały wykonywać swojej pracy.

Niektórzy zinterpretowali to jako część prób szpiegowania użytkowników. Ale prawdopodobnie ludzką naturą jest zrobienie czegoś tylko dlatego, że można to zrobić.

Zasada Petera dotyczyła oprogramowania

Lawrence Peter zasłynął stwierdzeniem, że w hierarchii osoba wznosi się na stanowisko, na które jest rażąco niekompetentna. Ale miał też czas, aby powiedzieć coś o złożonych projektach:

„Złożony projekt stanie się zbyt złożony, aby mógł być zrozumiany nawet przez jego własnych programistów”.

Zasada najmniejszego zdziwienia

Zasada ta, opublikowana w IBM Systems Journal w 1984 roku, stanowi, że:

„Jeśli wymagana funkcja powoduje duże zaskoczenie, może być konieczne przeprojektowanie”.

Innymi słowy jeśli część lub całość oprogramowania bardzo różni się od tego, do czego był przyzwyczajony użytkownik, najlepszym rozwiązaniem jest przeprojektowanie. Najlepiej dążyć do osiągnięcia przyrostowe ulepszenia, które są na tyle duże, że robią wrażenie, ale na tyle małe, że pozostają znajome dla użytkownika.

Szkoda, że ​​Shuttleworth nie wziął tego pod uwagę, uruchamiając Unity.

Prawo entomologii cybernetycznej

Pierwszy błąd w historii komputerów był prawdziwy. Ćma wleciała do jednego z przekaźników w komputerze MARK II, powodując awarię.

Kontynuując metaforę, potwierdza to prawo entomologii cybernetycznej zawsze będzie jeszcze jeden błąd.

To jest coś, co wiedzą wszyscy użytkownicy komputerów. Bez względu na to, jak bardzo system operacyjny jest testowany, zawsze wykryto usterkę, gdy jest już za późno.

Prawo Kernighana

Linux Adictos ma zainstalowaną wtyczkę, która zapewnia, że ​​my, autorzy, piszemy w sposób przyjazny dla wyszukiwarek. Nienawidziłem tego od pierwszego dnia. Każda próba pisania z odrobiną literackiego lotu jest natychmiast piętnowana czerwonym kółkiem. Z biegiem czasu przyzwyczaiłem się do tego i rzadko muszę poprawiać.

To samo dzieje się z programistami, często są oni bardziej zainteresowani zademonstrowaniem swoich umiejętności kodowania niż napisaniem prostszego kodu, który jest łatwiejszy do zrozumienia i utrzymania.

Stąd prawo Kernighana mówi, że:

Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Więc jeśli piszesz kod tak sprytnie, jak to tylko możliwe, z definicji nie jesteś wystarczająco inteligentny, aby go debugować ”.

Zasada 90/90

Każdy, kto w prawdziwym życiu rozpoczął projekt nastawiony na zysk, wie, że każdy projekt będzie trwał dwa razy dłużej i kosztował dwa razy więcej niż przewidziano w budżecie, aby osiągnąć połowę oczekiwanego zysku.

Świat komputerów ma swoje warianty tego prawa. Na przykład jeden z Tomów Cargill powiedział:

„Pierwsze 90 procent kodu stanowi pierwsze 90 procent czasu projektowania. Pozostałe 10 procent kodu stanowi pozostałe 90 procent czasu programowania.

Czy to nie było jasne? Być może prawo Hofstadtera pomoże:

„To zawsze trwa dłużej, niż się spodziewasz, nawet biorąc pod uwagę prawo Hofstadtera”.

Myślę, że programiści Ubuntu i Fedora muszą wiedzieć. A przynajmniej pamiętaj o tym co 6 miesięcy.

Prawo Brooka

Projekty oprogramowania typu open source często mają dwa problemy; finansowanie i brak współpracowników. Chyba że drugi nie stanowi problemu. Według Brook:

„Dodanie pracowników do opóźnionego projektu oprogramowania spowoduje dalsze opóźnienie”.

Zrozumiałe jest, że nie musisz tylko aktualizować nowych koderów. Więcej trzeba będzie udokumentować, potrzeba więcej biurokracji, aby wszyscy byli zsynchronizowani, i prawdopodobnie będą walki.

I oczywiście nie możemy zapomnieć o chorobie przyjaciela Parkinsona i jego twierdzeniu Nie ma znaczenia, od jakiej pustej przestrzeni zaczniesz. Zawsze będziesz potrzebować więcej. Miał na myśli przestrzeń biurową, ale to samo dotyczy pamięci RAM i miejsca na dysku.