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 
  – Teleinfo nr 22/2000, z 29 maja 2000 r.

Programowanie komputerów
Żargon informatyczny