Dziś czas na nieco żartobliwe zestawienie czternastu niekoniecznie popularnych, za to bez wyjątku prawdziwych praw rządzących światem projektów komputerowych (i nie tylko).
Wpis jest luźno oparty na tym oto artykule:
https://www.timsommer.be/famous-laws-of-software-development/
Filar #1: Prawo Murphy'ego
Najbardziej chyba znane prawo, które działa nie tylko w kontekście tworzenia oprogramowania, ale również w każdym innym. Mówi ono:
"Jeżeli coś może się nie udać, to na pewno się nie uda."
Do prawa Murphy'ego istnieje kilka praw "satelitarnych", najczęstsze to:
- "Jeżeli coś działa, prawdopodobnie napisał to ktoś inny."
- "Przekleństwa to jedyny język, którym płynnie posługują się wszyscy programiści."
- "Komputer robi to, co mu się każe, a nie to, co chcielibyśmy, żeby robił."
Filar #2: Prawo Brooksa
"Zatrudnianie dodatkowych programistów do projektu, który jest już spóźniony sprawi, że spóźnienie wzrośnie."
Jeżeli projekt dawno już przekroczył swój ostatni deadline, proste dokładanie ludzi prawie na pewno tylko pogorszy sytuację. Zamiast tego lepiej przyjrzeć się efektywności istniejącego zespołu, metodologii tworzenia kodu, architekturze i tak dalej. Jeżeli jednak i to nie pomaga, prawie na pewno zostaliśmy właśnie kopnięci przez…
Filar #3: Prawo Hofstadtera
(chodzi rzecz jasna o Douglasa Hofstadtera, a nie o Leonarda Hofstadtera z The Big Bang Theory)
"To zajmie więcej czasu niż się tego spodziewasz, nawet jeżeli weźmiesz pod uwagę Prawo Hofstadtera"
Ten filar bazuje na doskonale wszystkim programistom znanej trudności z trafnym oszacowaniem czasu wymaganego do ukończenia złożonego projektu. Rekurencja zaś bierze się stąd, że nawet wiedząc o złożoności projektu, i dokładając najlepszych starań, i tak nie damy rady poprawnie wszystkiego zaplanować.
Rozwiązanie?
Zawsze miej bufor bezpieczeństwa na swoje krytyczne projekty.
Filar #4: Prawo Conway'a
"Struktura oprogramowania tworzonego przez organizację odzwierciedla strukturę tej organizacji"
W większości dużych firm istnieje wewnętrzna rywalizacja międzydziałowa (najczęściej chodzi o budżety, ale nie zawsze). W związku z tym poszczególne działy nie dzielą się ze sobą informacjami i w efekcie tworzone przez nie babole komputerowe będą skupiać się na wycinku działalności firmy, a projekty tworzone przez różne działy prawie na pewno nie będą ze sobą kompatybilne.
Filar #5: Prawo Postela
"Wysyłaj konserwatywnie, przyjmuj liberalnie"
Starajmy się nie generować więcej informacji, niż jest to niezbędne, jednak postarajmy się również być tolerancyjni wobec tych, którzy to robią. Zminimalizujemy dzięki temu efekty kaskadowego zalewu chłamem.
Prawo działa zarówno w kontekście wymiany danych między systemami informatycznymi, jak też w życiu codziennym i polityce.
Filar #6: Zasada Pareto
"80% skutków wywołanych jest przez 20% przyczyn"
Takie sformułowanie jest bardzo ogólne, dzięki czemu odnosi się do wielu dziedzin. W krainie projektów IT oznacza ono, że na ogół 80% błędów w kodzie generowanych jest przez 20% tego kodu, a 80% pracy nad projektem wykonuje 20% pracowników.
Filar #7: Zasada Petera
"W hierarchii firmowej każdy dąży do osiągnięcia jak najwyższego poziomu niekompetencji"
Innymi słowy ludzie pną się za wszelką cenę w górę nie zważając na to, że prawie na pewno nie mają odpowiednich zasobów wiedzy i doświadczenia, żeby efektywnie wykonywać swoją pracę "na górze".
Filar #8: Zasada Kerchkhoffa
"W kryptografii, system powinien być bezpieczny nawet jeżeli wszystkie jego elementy z wyjątkiem kluczy prywatnych zostaną upublicznione"
Hołdujemy tu zasadzie nie budowania software-owych "czarnych skrzynek" - architektura systemu powinna być jawna i otwarta; jedyne, co powino być ukryte to klucze prywatne.
Filar #9: Prawo Linusa
"Jeżeli udostępnimy kod źródłowy szerszej publiczności, błędy w tym kodzie zostaną wyłapane i naprawione o wiele szybciej, niż w przypadku kodu zamkniętego"
Tu z kolei mamy słynne porównanie bazaru z katedrą. Na bazarze wszystko widać (niedociągnięcia również). Każdy może przyjść na bazar i oglądać, krytykować i poprawiać. W katedrze natomiast może roić się od problemów, których nikt z wąskiej grupy uprzywilejowanych nie widzi (lub udaje że nie widzi). Niech żyje bazar!
Filar #10: Prawo Moore'a
"Moc obliczeniowa komputerów przy zachowaniu tego samego kosztu jednostkowego podwaja się co 24 miesiące."
Powyżej podałem oryginalne sformułowanie prawa Moore'a, jednak jest też kilka nieznacznie różniących się między sobą popularnych wariantów, na przykład:
"Liczba tranzystorów w układach scalonych będzie podwajać się średnio raz na 18 miesięcy"
Albo:
"Szybkość komputerów podwaja się co dwa lata"
Filar #11: Prawo Wirtha
"Software zwalnia szybciej, niż hardware przyspiesza"
Niklaus Wirth jest twórcą Pascala, który jest całkiem sympatycznym i ciągle popularnym językiem programowania, a także języka MODULA-2, którym wykładowcy torturowali mnie na studiach.
Prawo Wirtha przypisuje się tak naprawdę Martinowi Reiserowi, Wirth je tylko ostatecznie sformułował i spopularyzował (1995). Potem pomysł do prawa ukradł Larry Page (Google, 2009), ale to już osobna historia. Chodzi oczywiście o to, że 20 czy 30 lat temu interfejsy użytkownika i aplikacje działały często lepiej / szybciej, niż teraz, chociaż w międzyczasie moc obliczeniowa domowego peceta poszła w górę o kilka rzędów wielkości. Dzieje się tak głównie za sprawą dodatkowego oprogramowania, które producenci komputerów często dodają domyślnie do standardowego systemu operacyjnego, a także niefrasobliwego "szastania" zasobami komputera, bo skoro jest taki szybki, to po cholerę cokolwiek optymalizować…
Filar #12: Reguła dziewięćdziesiąt - dziewięćdziesiąt
"Napisanie pierwszych 90% kodu zajmuje 90% czasu. Napisanie pozostałych 10% zajmie nam kolejne 90% czasu"
To jest tak boleśnie prawdziwe, że praktycznie nie wymaga komentarza.
Filar #13: Zasada optymalizacji Knutha
"Przedwczesna optymalizacja jest źródłem wszelkiego zła"
Pamiętajmy: najpierw piszemy kod, potem znajdujemy wąskie gardła, potem je optymalizujemy, nie na odwrót!
Filar #14: Prawo Norviga
"Technologia, która spenetruje 50% rynku, nie podwoi się."
Prawo dość oczywiste, a jednak warto o nim pamiętać: jeżeli szczęśliwie uda nam się wymyśleć, opatentować i sprzedać nowy typ turbulgulatora grędnego z przystawką siedem iks, jeżeli kupi go połowa docelowego targetu, nie sprzedamy od tej pory więcej niż to, co już sprzedaliśmy. Rozwiązanie? Powiększyć target albo poszerzyć ofertę. Sprzedawać koszulki z nadrukiem turbulgulatora. Namawiać ludzi do posiadania kilku sztuk. I tak dalej…
Dobre i warte wykopania. Dodałem.
Co do #13:
1. Ta zasada jest źle sformułowana. Mówi o optymizacjach implementacyjnych, natomiast nie mówi o optymizacjach designersko-algorytmicznych. Wybór odpowiedniego algorytmu czy designu całego systemu determinuje późniejsze prace i zmieniać go później nie sposób, bądź wiąże się to z kosztami.
2. Co do jednak słuszności w kwestii optymizacji implementacyjnych, ja swego czasu odkryłem prawo prawdopodobnie pokrewne, które precyzyjniej określa, moim zdaniem, o co tu chodzi:
“Twoja rzeczywista praca nad oprogramowaniem zaczyna się od momentu, gdy napiszesz pierwszą implementację, uruchamialną i wykonującą poprawnie przynajmniej ograniczoną liczbę zadań w optymistycznych scenariuszach. Do tego momentu twoja praca jest warta tyle, co kopanie rowu pod fundament.”
1. Oczywiście. Mierz trzy razy, tnij raz. Byłem świadkiem (a czasem i uczestnikiem) projektów IT, które wystartowały ze złej technologii. Jak się zainwestuje miliony, ciężko potem przyznać się do błędu i zacząć od zera, więc żeby “zachować twarz” inwestuje się kolejne miliony i wmawia użytkownikom, że te okrągłe to są tak naprawdę kwadraty.
2. Odkryte przez Ciebie prawo wpasowuje się całkiem nieźle w filozofię Agile Software Development. Dostarczać coś, co działa, na bieżąco.
P.S. Całkiem zaawansowanego bloga prowadzisz, wrzuciłem w czytnik. Będę zaglądał!
Bardzo konkretne i stety niestety prawdziwe zestawienie. Ze swojej strony dodałbym kilka innych ‘znanych porzekadeł’ w tym zakresie:
Pełną dokumentację mają tylko programy bezużyteczne.
Nie ma programów bezbłędnie dzialających, a są co najwyżej niedostatecznie przetestowane.
oraz Regułę Reguł:
Każdy może ustalić nową regułę.
Pozdrawiam.