Tworzenie oprogramowania jest jak religia

Oryginalny post: Software Development: It's a Religion

Autor: Jeff Atwood

Jest poniedziałek, a Steve Yegge wciąż nienawidzi metodologii Agile. Jak bardzo jej nienawidzi? W przybliżeniu nienawiść ta jest warta 11000 słów. Myślę, iż mógłbym założyć domową wytwórnię poradników opartych na wpisach Steve'a. Oto moja skompresowana wersja ostatniego jego wpisu:

  • Steve nie miał zamiaru promować procesu wytwarzania oprogramowania firmy Google jako tej Jedynej Właściwej Metody. To tylko jedna z możliwych alternatyw metodologii Agile.
  • Metodologia Agile tylko dlatego się sprawdza, ponieważ jakakolwiek metodologia się sprawdza, jeśli posiada się rozsądnie utalentowanych inżynierów, którzy odpowiednio się starają.
  • Nie ma empirycznego czy naukowego sposobu na to, aby udowodnić, że metodologia Agile jest lepsza od jakiejkolwiek innej metodologii wytwarzania oprogramowania. Tak więc, promowanie metodologii Agile jest przesądem.

Kluczowe jest tu kilkukrotne powtarzanie słowa "przesąd". W swoim poprzednim wpisie odniósł się do metodologii Agile jako religii:

Tak więc konsultanci, którzy stracili swoich głównych klientów, byli pewnego dnia w barze i jeden z nich (L. Ron Hubbard) powiedział: "Fuchy opłacane za linie kodu są kiepskie. Wiesz, gdzie leżą prawdziwe pieniądze? Zapoczątkuj swoją własną religię." I tak oto narodziły się Extreme Programming oraz Scjentologia.

Steve przez "religię" rozumie coś złego.

bar code jesus

Ale tworzenie oprogramowania jest i zawsze było religią. Łączymy się w grupy ludzi, którzy wierzą w te same rzeczy, których do końca nie można dowieść. Java kontra .NET. Microsoft kontra Google. Języki typowane statycznie kontra typowane dynamicznie. Możemy oszukiwać siebie, że jesteśmy "informatykami", ale kiedy ostatnio postawiłeś hipotezę i sprawdziłeś ją, aby coś udowodnić? Jesteśmy zbyt zajęci rozwiązywaniem problemów klienta w wybranym narzędziu, niedowiarku!

Podstawowy kulturowy problem z przesądami powstaje wtedy, gdy ludzie nie wiedzą, jak rozróżnić rzetelne źródła weryfikacji od nierzetelnych, więc traktują oni coś nienaukowego jak naukę. Jeśli nie rozpoznają, ani nie przyznają się do bycia przesądnymi, bez skrupułów starają się propagować swoje przekonania względem CIEBIE.

Czy Steve Yegge udowodnił, że metodologia wytwarzania oprogramowania, którą praktykuje Google jest jakkolwiek lepsza od metodologii Agile przez duże A? Nie, ale w głębi duszy wierzy, że tak jest. W tej sprawie można powiedzieć, że jest religijny. Nie ma nic złego w religii, która głosi konkretne zasady inżynierii. Jeśli jesteś fanatykiem metodologii kościoła Google, staniesz się lepszym programistą. Kiedy Steve głosi chwałę metodologii Google w sposób tak wymowny, powoduje, iż inni programiści bardziej entuzjastycznie podchodzą do tego, co robią, co czyni ich lepszymi programistami. Zanim się zorientujesz, cały zespół jest już podniecony, ponieważ wszystko idzie zgodnie ze świetnym planem, w który wszyscy wierzą — niezależnie od tego, czy jest to Agile przez duże A, Google, Scrum, czy cokolwiek innego.

Aby programiści działali efektywnie, muszą wierzyć w to, co robią. To, czy dane przekonanie da się udowodnić naukowo bądź empirycznie jest całkowicie bez znaczenia. Są to podstawy czynnika ludzkiego. Steve tak zapalczywie chce udowodnić własny ateizm metodologiczny, że podważa własną istotę rzeczy. Według Jefa Raskina wszystko jest religią:

Systemy komputerowe wykazują wszelakie zachowania, które sprzyjają powstawaniu przesądów. Próbujesz czegoś i to nie działa, więc próbujesz jeszcze raz — w ten sam sposób — i tym razem działa, albo i nie. Jest to losowe wzmacnianie wiary. Efektywność większości praktyk programowania i zarządzania nie jest zatem mierzalna. Dla przykładu, zasady "extreme programming" są dla mnie rozsądne i używałem ich długo przed tym, jak nabyły tę obecną, absurdalna nazwę. Ludzie, którzy ogłaszają ideę są także tymi, którzy stworzyli paradygmat. Większość znanych wyników nie stanowi nawet ślepej próby, a już na pewno nie podwójnej ślepej próby. Rzadko rozumiemy, w jakikolwiek sposób, procesy zachodzące podczas, gdy pracujemy z komputerami. Używamy megabajtów kodu napisanego przez kogoś innego, który jest nienajlepiej udokumentowany, niewystarczająco przetestowany i używany na sposoby, które nie zostały przewidziane przez twórców.

Religia metodologii nie jest groźna sama w sobie. Zawsze istnieje ryzyko prześladowań na tle religijnym, ale naprawdę groźni ludzie to wariaci religijni, którzy nie zdają sobie sprawy z tego, że nimi są. Nie lubię odwoływać się do przezwisk, ale jak Steve mógł tego nie wiedzieć:

Natomiast zamiast wymieniać wszystkie nie-Agile'owe zespoły i firmy, jako szczególne przypadki, ustanówmy pewną zasadę: większość dobrych programistów z całego świata nie używa metodologii Agile. Po prostu pracują ciężko, pozostają lekcy i tworzą wspaniałe rzeczy. Większość programistów wciąż nie ma pojęcia, czym jest Agile. Pomyśl o tym!

  1. Czym dokładnie "pozostawanie lekkim" różni się od metodologii Agile? Czy Agile nie jest przypadkiem Kościołem Lekkości? Steve może się nie zgadzać z pewnymi doktrynami danego kościoła (programowanie w parach, itp) i to jest w porządku. Nikt nie modli się dokładnie w taki sam sposób, jak również nie każdy jest fanatykiem. Ale zawsze posiadasz pewien zbiór wspólnych, podstawowych wierzeń. A lekkie rozwijanie oprogramowania jest, oczywiście, rdzeniem wiary w Agile.
  2. Prawdą jest, iż większość programistów nie używa metodologii Agile w wytwarzaniu oprogramowania. Ale nie z wyboru. Nie mieli go danego. Zazwyczaj tkwią w organizacjach, które nie pozwalają im na luksus "pozostawania lekkimi". Są robotnikami w fabryce kiełbasek.
  3. Steve mówi o "pozostawaniu lekkim" tak, jakby to była najłatwiejsza rzecz na świecie, jakby to był stan łaski, z którym programiści oraz firmy się rodzą. Mówienie programistom, aby pozostawali lekkimi, to jak mówienie komuś z depresją, żeby się nie martwił.

Nie jestem pewien, dlaczego Steve czuje się niepewny, jeśli chodzi o traktowanie tworzenia oprogramowania jako religii, zbioru wspólnych wierzeń z nikłymi "podstawami naukowymi, czy rozumowaniem". Ponieważ z pewnością jest on jednym z najlepszych ewangelistów, jakiego kiedykolwiek czytałem.

Data publikacji oryginału: 9 października, 2006

Przejrzyj swój kod zanim zaczniesz obwiniać innych - Allan Kelly (9. z 97 rzeczy)

Kolejny artykuł z serii 97 rzeczy jest już dostępny.

Pozdrawiamy,

Zespół devBlogi.pl

Sortowanie dla ludzi - naturalna kolejność sortowania

Oryginalny post: Sorting for Humans : Natural Sort Order

Autor: Jeff Atwood

Domyślne funkcje sortowania w niemal każdym języku programowania są słabo dopasowane do ludzkich potrzeb. Co przez to rozumiem? Cóż, rozważ różnice pomiędzy sortowaniem nazw plików w Eksploratorze Windows, a sortowaniem tych nazw poprzez kod Array.Sort():

Sortowanie Eksploratora Array.Sort()
sortowanie alfabetyczne sortowanie ASCIIbetyczne

Niemała różnica.

Bez przesady mogę powiedzieć, że dokładnie ten problem był czułym punktem każdego projektu, nad którym pracowałem. Użytkownicy ciągle będą narzekać, że ich elementy nie sortują się poprawnie i będą zgłaszać bugi związane z tymi "błędami". Jako iż jesteśmy członkami klubu homo logicus, my programiści, wzdychamy ze znużenia, staramy się trzymać w ryzach wywracanie oczami z oczywistości podczas, gdy cierpliwie informujemy naszych użytkowników, że to nie jest błąd. Elementy sortowane w prawidłowej kolejności. W sensie, prawidłowiej kolejności według ASCII. Miejmy nadzieję, że jak odchodzimy, nie będziesz nas słyszał, jak mamroczemy pod nosem to, co aktualnie myślimy &mdash "Głupi użytkownicy! Nie rozumieją nawet, jak działa sortowanie!"

Zawsze czułem ukłucie żalu, gdy odrzucałem takie zgłoszenia. Szczerze, spójrz na te dwie listy — jaka osoba o zdrowym umyśle chciałaby kolejność według ASCII? Jest to zupełnie bezsensowny porządek dla każdego, kto nie ma zakodowanej tablicy ASCII w umyśle (a tak przy okazji, duże A, to 65). Niemal nigdy nie rozumiałem, że może być inny rodzaj sortowania nawet, gdy sortowanie naturalne, było tuż przed naszymi oczami pod postacią Mac Findera, czy listy plików w Eksploratorze Windows. Miałem nałożone językowe klapki na oczach. Jeśli wbudowana funkcja sort zwracała w porządku ASCII, to musiało to być poprawne. Zostawili to nam w spadku Bogowie Językowi. Czy może być inny sposób?

Kate Rhodes jest lekko oburzona naszą ogólną ignorancją problemu "ASCIIbetycznie kontra Alfabetycznie". Nie mogę powiedzieć, że ją obwiniam. Jestem tak samo winny, jak każdy inny. Okazuje się, że to nie użytkownicy byli głupi &mdash ja byłem.

Niech mnie, liczyłem na to, iż skoro sortowanie alfabetyczne było tak powszechną potrzebą (a sądząc po liczbie ludzi pytających, jak to zrobić, nie mylę się), to nie będę musiał do licha nic pisać. Ale nie zdawałem sobie sprawy z głupiego czynnika. Jezu Chryste. Jesteście programistami. Niemal wszyscy jesteście po studiach i nikt z Was nie wie, co do k***y znaczy "alfabetycznie". Powinno być Wam wstyd. Jeśli ktokolwiek z Was używa domyślnego algorytmu sortowania w swoim języku, który niemal na pewno jest ASCIIbetyczny (z konkretnych powodów), aby zaimplementować sortowanie alfabetyczne, niech uda się przed najbliższe lustro i uderzy kilkakrotnie w twarz przed tym, jak powróci do swojego biurka i naprawi testy jednostkowe, które nie wyłapały tego problemu.

Nie nazywa się to "sortowanie alfabetyczne"; bardziej znane jest jako sortowanie naturalne. Ale ma ona rację, co do jednej rzeczy: trudno jest znaleźć informacje na temat sortowania naturalnego i wielu programistów całkowicie ignoruje ten problem. Żaden z popularnych języków programowania (które znam) nie implementuje niczego innego, niż sortowanie ASCIIbetyczne. Jednakże, istnieje trochę miejsc, gdzie znajdziemy algorytmy sortowania naturalnego:

Nie pozwól na to, aby pythonowy dzięsięciolinijkowiec Neda Cię ogłupił. Zaimplementowanie sortowania naturalnego jest trudniejsze, niż się wydaje i nie chodzi tylko o fajne problemy związane z i18n, o których wspominałem powyżej. Ale implementacje w Pythonie są imponująco zwięzłe. Jeden z komentatorów Neda podesłał swoją wersję, która jest jeszcze krótsza:

    import re 

    def sort_nicely( l ): 
      """ Sort the given list in the way that humans expect. 
      """ 
      convert = lambda text: int(text) if text.isdigit() else text 
      alphanum_key = lambda key: [ convert(c) for c in re.split('([0-9]+)', key) ] 
      l.sort( key=alphanum_key ) 
  

Próbowałem dojść do jakiejś sprytnej, zwięzłej implementacji sortowania naturalnego w C# 3.0, ale bez powodzenia. Nie interesuje mnie żaden jednolinijkowiec, ale wydaje mi się, iż podstawowy algorytm sortowania naturalnego nie powinien wymagać więcej niż 40 linijek kodu tak, jak w przypadku większości języków programowania.

Jako programiści, postaramy się zachować w pamięci lekcję od Kate: ASCIIbetycznie to nie to samo, co alfabetycznie. Sortowanie ASCII jest na potrzeby komputerów i kompilatorów, to co jest w takim razie dla ludzi? Być może naturalne sortowanie, bardziej przyjazne ludziom, powinno być wbudowane w najpopularniejszych językach programowania.

Data publikacji oryginału: 12 grudnia, 2007

Nie bój się psuć - Mike Lewis (24. z 97 rzeczy)

Zgodnie z zapowiedziami, kolejny tydzień oznacza pojawienie się nowego tłumaczenia artykułu z serii 97 rzeczy.
  • Nie bój się psuć (autor: Mike Lewis)

    Każdy w branży bez wątpienia pracował nad kodem, który był conajmniej niepewny. System jest kiepsko zorganizowany, a zmiana jednej rzeczy oznacza zepsucie jakiejś zupełnie innej. Zawsze kiedy dodaje się moduł, pierwszorzędnym celem jego twórcy jest zmiana jak najmniejszej części kodu, a potem wstrzymywanie oddechu podczas każdego wypuszczenia produktu. Jest to programistyczny odpowiednik grania w Jenga kształtownikami w wieżowcu, musi się skończyć katastrofą.

Pozdrawiamy, Zespół devBlogi.pl

Więcej robisz, czy gadasz?

Oryginalny post: Are You a Doer or a Talker?

Autor: Jeff Atwood

Dzisiejsza lekcja sponsorowana jest przez Twój lokalny Wydział Transportu:

Wydział Transportu stanu Utah wydaje $6 milionów na badania odnośnie wykonalności mostu, który miałby iść nad jeziorem. W tym samym czasie Wydział Komunikacji nie ma wystarczającej ilości pieniędzy, aby zamontować kamery video w niebezpiecznych górskich przejściach i kanionach, aby pomóc zmotoryzowanym obierać bezpieczne trasy. Te $6 milionów z powodzeniem wystarczyłoby na kamery i nadal zostałoby trochę na rozsądne analizy odnośnie mostu.

W stanie Washington, pieniądze zabudżetowane na projekt osuszania zostały przeznaczone na badania. Tymczasem, ostatnie podtopienia nawiedziły kilka małych miast, robiąc zniszczeń za miliony i niszcząc życie wielu ludziom. $16 milionów zostało wydane na badania dotyczące przeprojektowania szlaku kolejowego. Te pieniądze wystarczyłyby na wybudowanie nowego węzła na autostradzie, co spowodowałoby, iż nie tracilibyśmy milionów przez opóźnienia związane z zatorami oraz poprawiłoby bezpieczeństwo już dziś.

John Taber, autor powyższego artykułu, jest zawodowo uwikłany w dokładnie tego typu badania. Jego opinia?

Do licha, zarabiam na życie robiąc badania odnośnie transportu i nawet ja twierdzę, że jest w tym wszystkim za dużo badań, a zbyt mało tworzenia.

Jest to prosta pojęciowa wycieczka od budowy mostów do tworzenia oprogramowania. W świecie oprogramowania, niektórzy programiści zasiedlają się na planecie architektury, nieziemskim miejscu, gdzie oprogramowanie jest wiecznie planowane i dyskutowane, ale nigdy w zasadzie nie jest tworzone. Odbywanie niekończących się dyskusji odnośnie oprogramowania w pokoju konferencyjnym bądź na listach mailingowych wydaje się być użyteczną pracą — ale czy tak jest? Dopóki nie wyprodukujesz jakiegoś namacalnego, działającego artefaktu, to czy w ogóle coś zrobiłeś?

Jeden z moich ulubionych cytatów w tym temacie pochodzi od Christophera Bausa. Niestety nie jestem w stanie przytoczyć dosłownego cytatu; wygląda na to, że skasował on ten wpis ze swojego bloga.

Oprogramowanie nie dotyczy metodologii, języków, czy nawet systemów operacyjnych. To co się liczy, to działające aplikacje. W Adobe nauczyłbym się sztuki tworzenia olbrzymich aplikacji, które generują miliony dolarów zysku. Pewnie, PostScript nie był najseksowniejszą aplikacją, i był napisany w starym, dobrym C, ale wykonywał znaczące i użyteczne zadanie, na którym polegały tysiące (jeśli nie miliony) ludzi. Trudno o lepsze miejsce do nauki umiejętności budowania komercyjnych aplikacji, niezależnie od tego jakich narzędzi się wtedy używało. W ObjectSpace natomiast nauczyłem się ważnej lekcji. Diagram UML nie jest w stanie przecisnąć 500 stron na minutę przez RIP.

Mamy w branży dwa typu ludzi. Ci co Gadają i ci, co Robią. ObjectSpace było firmą ludzi gadających. Adobe jest firmą tych, co robią. Adobe zarobiło $430 milionów w poprzednim kwartale. ObjectSpace zbankrutowało.

Tak więc to jest to, o co powinieneś siebie zapytać: więcej robisz, czy gadasz? W idealnym świecie, robiłbyś jednego i drugiego po trochu, tak jak o tym wspominałem. Istnieje pewna wartość w jakimś dyskutowaniu i planowaniu w Twoim zespole. Ale jeśli musisz wybrać między jednym a drugim, staraj się błądzić po stronie, która w efekcie daje użyteczny, działający kod:

Najlepszym sposobem na rozpoczęcie projektu Open Source jest kod. Działający kod. Skleć coś w domu podczas weekendu, może zaproś kilku przyjaciół, aby Ci pomogli i nie publikuj niczego, dopóki nie będziesz miał do pokazania czegoś interesującego, co stanowiłoby podstawę dla innych, aby budować za pomocą tego więcej interesujących rzeczy. Potrzebujesz tego z kilku różnych powodów: ustanawia to dobre zamiary osoby pierwotnie wnoszącej wkład w open-source'owej merytokracji, ucina wszystkie niszczące debaty na temat stylu kodowania i architektury, które mogą zastopować projekt zanim ruszy, i tym podobne.

Działający kod przyciąga ludzi, którzy chcą kodować. Dokumenty projektowe przyciągają ludzi, którzy chcą rozmawiać o programowaniu.

Istnieje wyraźna górna granica pomiędzy tym, co jest czystą, teoretyczną dyskusją a planowaniem w świecie tworzenia oprogramowania. Sztuką jest wiedzieć, kiedy się ją osiągnęło i przekierować wysiłek na tworzenie konkretnego kodu zamiast pozwolić mu się rozproszyć w powietrzu.

Data publikacji oryginału: 10 grudnia, 2007

Nowe tłumaczenie z cyklu 97rzeczy

Opublikowane zostało nowe tłumaczenie z cyklu 97 rzeczy:

  • Ciągłe doskonalenie (autor: Clint Shank)

    Żyjemy w ciekawych czasach. W miarę jak tworzenie oprogramowania rozprasza się po planecie zaczynasz zdawać sobie sprawę, że jest wielu ludzi zdolnych wykonywać Twoją pracę. Musisz ciągle się uczyć, aby zostać na rynku. W przeciwnym wypadku staniesz się dinozaurem tkwiącym na jednym stanowisku aż pewnego dnia nie będziesz już potrzebny albo zostaniesz zastąpiony przez tańszą siłę roboczą.

W kolejce czeka kilkanaście następnych. Mamy nadzieję przywrócić cykl do życia po tym, jak zamarł na dłuższy czas. Planujemy publikować jeden artykuł tygodniowo, więc nie zapomnijcie zapisać 97rzeczy w swoich czytnikach RSS. Będziemy Was informować o nowych tłumaczeniach również na łamach devBlogów.

Zespół devMedia.pl

Related Posts with Thumbnails