Teoria „Worse is Better”
Teoria „Worse is Better” w programowaniu podkreśla, że podejście „właśnie teraz” jest istotniejsze od „właściwego sposobu”. Zasady te odzwierciedlają praktyki, które już od dawna są stosowane w branży. Wiele tradycyjnych metod okazało się nieefektywnych, podczas gdy systemy tworzone z pominięciem zasad często osiągają sukcesy przewyższające oczekiwania.
Zasady „Worse is Better”
- Prostota implementacji: Ważniejsza niż prostota interfejsu. Ułatwienia w implementacji mogą przyspieszyć proces tworzenia systemu i zredukować błędy.
- Poprawność vs. prostota: Można zaakceptować pewne niedoskonałości, jeśli system działa w większości przypadków.
- Spójność: Nie jest kluczowa; trudności w jej utrzymaniu mogą przewyższać korzyści.
- Kompletność: Nie jest priorytetem, jeśli szkodzi prostocie. System powinien koncentrować się na typowych przypadkach.
- Otwartość: Umożliwia ją stosowanie prostych, tekstowych zbiorów konfiguracyjnych, co pozwala na elastyczność.
Przykłady sukcesu „Worse is Better”
- Unix: Prosty w implementacji, skoncentrowany na typowych przypadkach, z licznymi dodatkami od różnych grup programistów.
- Języki programowania: Języki takie jak C, C++ i Perl, które ewoluowały w odpowiedzi na potrzeby, odniosły większy sukces niż bardziej zaprojektowane języki, jak Ada.
- Wikipedią vs. Nupedia: Wikipedia, pisana przez każdych użytkowników, ma znacznie więcej wartościowych artykułów niż Nupedia, która była tworzona przez specjalistów.
- DOS: Zwycięstwo DOS na PC mimo lepszych systemów konkurencji, takich jak Amiga czy Atari ST.
Ograniczenia zasady
Stosowanie zasady „Worse is Better” bezrefleksyjnie może prowadzić do niepowodzeń, zwłaszcza w dziedzinach takich jak informatyka przemysłowa czy medyczna. Kluczowe jest odpowiednie zdefiniowanie celów oraz warunków, w jakich są tworzone systemy.
