Worse is Better

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

Worse is Better (ang. gorsze jest lepsze) to 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[edytuj | edytuj kod]

  • 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[edytuj | edytuj kod]

  • 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 nienajlepszą 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[edytuj | edytuj kod]

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.

Linki zewnętrzne[edytuj | edytuj kod]

Informatyczne prawo Kopernika - Teleinfo nr 22/2000, z 29 maja 2000 r.