Worse is Better

Worse is Better – teoria, według której w programowaniu „right now” (właśnie teraz) jest znacznie ważniejsze od „right way” (właściwy sposób).

Teoria ta jedynie kodyfikuje zasady stosowane od dawna w praktyce. Tradycyjne sposoby tworzenia systemów informatycznych w zderzeniu z rzeczywistością okazały się nieraz porażką, z kolei bardzo często systemy tworzone całkowicie „wbrew zasadom” kończą się pełnym sukcesem, przerastającym czasem najśmielsze oczekiwania.

Zasady Worse is Better

• Prostota implementacji jest ważniejsza niż prostota interfejsu. Nie jest ważne, że korzystanie z systemu będzie trochę trudniejsze, jeśli znacznie uprości to system. Dzięki temu system powstanie szybciej, będzie zawierał mniej błędów i będzie łatwiejszy do rozszerzenia w przyszłości.
• Można poświęcić stuprocentową poprawność na rzecz prostoty. Jeśli coś działa prawie zawsze, a zawodzi jedynie w przypadkach, które nie są specjalnie ważne, nie warto komplikować kodu wyjątkami.
• Spójność jest mało istotna. W praktyce trudność ze stworzeniem, a przede wszystkim z zachowaniem spójności systemu, przewyższa znacznie korzyści, jakie odnosi się ze spójności.
• Kompletność nie jest specjalnie ważna, jeśli miałaby uderzyć w prostotę. System powinien skupić się na typowych przypadkach.
• Otwartość systemu uzyskuje się, po pierwsze, poprzez proste, tekstowe zbiory konfiguracyjne. Pozwalają na szybką reakcję w wypadkach nietypowych, a nie wymagają kawałków programu typu setup.

Przykłady sukcesu Worse is Better

• Unix to archetyp Worse is Better – tak prosty w implementacji jak tylko się da. Posiadał początkowo interfejs stworzony wyłącznie z myślą o łatwym i wydajnym implementowaniu. Zawiera wiele wyjątków od zasady pełnej poprawności (np. EINTR) i spójności. Wiele różnych grup programistów stworzyło przez lata setki dodatków. System zajmował się wyłącznie typowymi przypadkami zostawiając wszystko co mniej typowe programiście i użytkownikowi. Inne systemy operacyjne tamtych czasów – VMS, ITS, różne lispowe systemy operacyjne – próbowały robić jak najwięcej wewnątrz systemu operacyjnego i przedstawić programiście i użytkownikowi interfejs jak najwyższego poziomu. Są one dziś praktycznie zapomniane, a wszystkie nowe systemy (z DOS-em i Microsoft Windows włącznie) są w mniejszym lub większym stopniu wzorowane na Uniksie.
• Języki programowania – języki, które zmieniały się zależnie od aktualnych potrzeb, takie jak C, C++ czy Perl, osiągnęły nieporównywalnie większą popularność i nieporównywalnie większe sukcesy w praktyce niż języki zaprojektowane takie jak Ada.
• Sukces Wikipedii przy porażce Nupedii. Pisane wyłącznie przez specjalistów artykuły Nupedii były przynajmniej dobre, dla odmiany na Wikipedii pisać może każdy chętny niezależnie od tego, czy coś wie i czy ma do tego kompetencje. Powoduje to nie najlepszą jakość wielu pierwszych wersji artykułów. Jednak liczba bardzo dobrych artykułów Wikipedii jest o parę rzędów większa niż liczba bardzo dobrych artykułów Nupedii.
• DOS na komputerach PC wygrał z Amigami, Atari ST itp., które miały lepsze procesory i bardziej dopracowane systemy operacyjne. Miały też lepsze systemy plików i obsługę urządzeń. Podobnie MS Windows na PC ma ogromną przewagę ilościową nad Mac OS-em na procesorach Motoroli, który jest uważany za znacznie bardziej elegancki i dopracowany.

Ograniczenia zasady

Zasada Worse is Better stosowana mechanicznie lub jako uzasadnienie dla braku analizy własnej pracy (projektu) może jednak doprowadzić do fiaska. Istnieją dziedziny, także w informatyce, zwłaszcza przemysłowej czy medycznej, gdzie pomimo swojej pozornej atrakcyjności biznesowej stosowanie zasady Worse is Better jest kompletną pomyłką.

Można przyjąć, że stosowanie tej zasady zależy w istotny sposób od właściwego zdefiniowania celów i warunków w jakich powstają systemy.

Zobacz też

• KISS (reguła)

Linki zewnętrzne

• Informatyczne prawo Kopernika. teleinfo.com.pl. [zarchiwizowane z tego adresu (2007-02-22)]. – Teleinfo nr 22/2000, z 29 maja 2000 r.