Warstwa Abstrakcji Programistycznej

Oryginalny post: The Development Abstraction Layer

Autor: Joel Spolsky

Młody mężczyzna przyjeżdża do miasta. Jest całkiem przystojny, ma mało pieniędzy w portfelu, z łatwością nawiązuje kontakty z kobietami.

Nie mówi wiele o swojej przeszłości, ale to raczej jasne, że spędził dużo czasu w bezdusznej, wielkiej korporacji.

Jest naturalnie przyjazny i towarzyski, po cichu pewny siebie, ale nie arogancki. Dlatego łatwo mu chwytać się drobnych zleceń znalezionych na tablicy ogłoszeń w lokalnej Kawiarni Programistów. Szybko jednak traci zainteresowanie projektami baz danych dla ubezpieczycieli, próżnymi stronami internetowymi dla gospodyń domowych i silnikami do obliczeń finansowych.

Po roku zgromadził wystarczającą ilość pieniędzy, by pokryć swoje skromne wydatki przez rok czasu. Tak więc po skonsultowaniu się ze swoim owczarkiem, ustawia komputer w słonecznym pokoju w apartartamencie wynajętym nad sklepem spożywczym i instaluje starannie wybrane narzędzia.

Dzwoni do swoich znajomych, do jednego po drugim i uprzedza ich, że jeśli będzie wydawał się trochę odcięty od świata przez następnych kilka miesięcy to dlatego, że ciężko pracuje.

I siada do pisania kodu.

I to jakiego kodu. Doskonałego, kunsztownego, eleganckiego, bez błędów. Interfejs tak doskonale naśladuje proces myślowy użytkownika, że ludzie z Kawiarni Programistów, którym pokazuje swoje dzieło, ledwie dostrzegają, że jest tam jakiś interfejs. Jego kod jest fantastyczny.

Zachęcony ciepłym przyjęciem w grupie, postanawia założyć firmę i przyjmować zlecenia.

Jego skromność wyklucza jakiekolwiek roszczenia, ale po miesiącu sytuacja w banku nie wygląda ciekawie. Jak do tej pory złożono tylko trzy zamówienia: jedno od mamy, jedno od anonimowego dobroczyńcy z Kawiarni Programistów i jedno, które wysłał sam, aby przetestować system do sprzedaży.

W drugim miesiącu nie wpłynęły żadne nowe zamówienia.

To go zaskakuje i napełnia melancholią. W dużej firmie nowe produkty były tworzone dość regularnie i nawet jeśli były nieeleganckie i pospolite, to sprzedawały się w rozsądnych ilościach. Jeden produkt, nad którym tam pracował, okazał się być wielkim hitem.

Po kilku następnych miesiącach jego sytuacja finansowa zaczęła wyglądać lekko niebezpiecznie. Jego pies patrzył na niego smutnym wzrokiem, nie wiedząc co jest nie tak, ale widząc, że jego twarz jest bardziej pochmurna niż zwykle, że nie ma energii, żeby wyjść gdzieś ze znajomymi, po zakupy, by napełnić niebezpiecznie opustoszałą spiżarnię albo żeby chociażby wziąć kąpiel.

Pewnego wtorkowego poranka sprzedawca w sklepie spożywczym odmówił mu poszerzenia kredytu, który zdążył zaciągnąć, a jego bankowiec już dawno nie odbierał od niego telefonów.

Duża firma nie jest mściwa. Potrafią docenić talent i chętnie zatrudniają go ponownie, z wyższą pensją. Szybko zaczyna wyglądać lepiej, ma nowe ciuchy i wraca jego dawna pewność siebie. Ale czegoś gdzieś brakuje. Błysku w oku. Nadzieja, że mógłby być panem własnego losu, zniknęła.

SCal2

Dlaczego mu się nie udało? Jest prawie pewien, że wie. "Marketing", mówi. Jak wielu młodych inżynierów jest skłonny mówić "Microsoft ma gorsze produkty, ale lepszy marketing".

Mówiąc językiem programistów, termin "marketing" oznacza po prostu całą biznesową otoczkę, wszystko, czego oni nie rozumieją w procesie tworzenia i sprzedaży oprogramowania.

To nie jest marketing, tak właściwie. A Microsoft ma bardzo kiepski marketing. Wyobrażacie sobie, żeby te reklamy z dinozaurami przekonały kogokolwiek do kupna Microsoft Office?

Oprogramowanie to rozmowa między użytkownikiem a programistą. Ale żeby ta rozmowa się odbyła, potrzeba wiele pracy poza samym pisaniem oprogramowania. Potrzeba marketingu, tak, ale także sprzedaży i public relations, biura, sieci, infrastruktury, klimatyzacji w biurze, i obsługi klienta, i księgowości, i wielu innych wspomagających czynności.

A co robią programiści? Projektują i piszą kod, projektują ekrany interfejsu, debuggują, integrują, dodają kod źródłowy do repozytorium.

Poziom, na którym pracuje programista (np. Emacs) jest zbyt abstrakcyjny, aby wspierać sam biznes. Programiści pracujący w warstwie abstrakcji programistycznej potrzebują warstwy implementacyjnej - organizacji, która przekształci ich kod w produkt. Dolly Parton, pracująca w warstwie "śpiewania ładnej piosenki", potrzebuje także dużej warstwy implementacji, aby nagrywać płyty, rezerwować sale koncertowe, sprzedawać bilety, ustawiać sprzęt grający, promować nagrania i zbierać honoraria.

SCal3 Każda, odnosząca sukcesy, firma informatyczna będzie składała się z cienkiej warstwy programistów piszących oprogramowanie rozsianych pod olbrzymią, abstrakcyjną administracyjną organizacją.

Abstrakcja istnieje tylko i wyłącznie po to, aby stworzyć pozory, że codzienne aktywności programisty (projektowanie i pisanie kodu, debuggowanie, dodawanie go do repozytorium itp.) to wszystko, czego potrzeba, aby stworzyć produkt i wypuścić go na rynek. Co doprowadza mnie do najważniejszego punktu mojego eseju:

Twoim priorytetem, jako menadżera zespołu programistycznego, jest wytworzenie tej Warstwy Abstrakcji Programistycznej.

Większość nowych menadżerów zespołów programistycznych gubi ten punkt. Myślą o zarządzaniu w kategoriach tradycyjnego podejścia Rozkazuj-I-Zdobywaj (Command-and-Conquer), którego nauczyli się z hollywoodzkich filmów.

Zgodnie z podejściem Rozkazuj-I-Zdobywaj, menadżerowie-albo-inaczej-liderzy starają się wymyślić, w którą stronę pójdzie biznes i wysyłają odpowiednie rozkazy do swoich poruczników, aby ruszyli wspólny biznes w tamtą stronę. Ich porucznicy z kolei, dzielą zadania na mniejsze części i nakazują wykonanie swoich poleceń ludziom pod sobą. No i tak w dół schematu organizacyjnego firmy aż na samym końcu ktoś rzeczywiście coś robi. W tym modelu programista jest kołem zębatym tej maszyny: maszynistą, która wykonuje jedną część rozkazu manadżera.

Niektóre firmy rzeczywiście tak działają. Zawsze poznasz, jeśli będziesz miał styczność z taką firmą. Osoba, z którą będziesz miał do czynienia będzie właśnie robiła jakąś bezsensowną, frustrującą czynność i będzie wiedziała, że to bezsensowne, może nawet będzie ją to obchodziło, ale niestety nic nie będzie mogła na to poradzić. To na przykład linia lotnicza, która traci na zawsze swojego klienta z przelatanym milionem mil tylko dlatego, że nie chcieli zamienić mu jego nierefundowalnego biletu, by mógł wrócić do domu z powodu ważnej sytuacji rodzinnej. To Twój dostawca internetowy, który częściej nawala niż dostarcza Internet, a kiedy rezygnujesz z jego usług, on nadal wysyła rachunki, nalicza opłaty, nalicza opłaty, gdy dzwonisz z reklamacją musisz czekać ponad godzinę na płatnej linii, aby dowiedzieć się, że nie zwrócą Ci kosztów, dopóki nie zaczniesz pisać na blogu, jak bardzo są beznadziejni. To firma motoryzacyjna z Detroit, która już bardzo dawno straciła pomysł na stworzenie samochodu, który być może ktoś chciałby kupić, a zamiast tego słania się od jednej strategii marketingowej do drugiej tak, jakby jedynym powodem, że nie chcemy kupować ich gównianych samochodów, jest zbyt niski rabat.

SCal1 Wystarczy.

Zapomnij o tym. System zarządzania oparty na rozkazach i hierarchii został już wypróbowany i wydawał się działać w latach 20' w czasach konkurencji domokrążców pchających swoje wózki z towarami, ale nie nadaje się na XXI wiek. Dla firm informatycznych musisz użyć innego modelu.

W firmie informatycznej, najwyższym priorytetem dla menadżera powinno być stworzenie Warstwy Abstrakcji Programistycznej.

Jeśli programista gdzieś w firmie martwi się zepsutym krzesłem albo czeka wciąż na komputer od Della, to znaczy że ta warstwa zaczyna przeciekać.

Pomyśl o swojej Warstwie Abstrakcji Programistycznej jak o wielkim, pięknym jachcie z niesamowicie potężnym silnikiem. Jest nieskazitelny, zadbany. Posiłki dla prawdziwych smakoszy serwowane są jak w zegarku. Pokojówki sprzątają prywatne kabiny dwa razy dziennie. Mapy nawigacyjne są zawsze aktualne. GPS i radar zawsze działają, a jeśli się zepsują, zawsze jest jakiś zapasowy pod pokładem. Stojąc na kapitańskim mostku patrzysz na programistów, którzy myślą tylko i wyłącznie o prędkości, kierunku i czy na lunch wziąć łososia czy tuńczyka. W międzyczasie duża grupa profesjonalistów w wykrochmalonych, białych uniformach uwija się cichutko na paluszkach pod pokładem, utrzymując wszystko w ruchu, napełniając zbiorniki z benzyną, zdrapując skorupiaki, prasując serwetki na lunch. Dział obsługi wie, co robić, nawet mimo tego, że wskazówki otrzymuje od starego pierdziela, który ledwo co rusza ręką nadając rytm tej całej symfonii. A wszystko po to, aby programiści mogli nie myśleć o niczym związanym z jachtem poza prędkością, kierunkiem i tym, co będą jedli na lunch.

Menadżerowie w firmie informatycznej są po to, aby stworzyć Warstę Abstrakcji Programistycznej. Budujemy jacht, utrzymujemy jacht, jesteśmy jachtem, ale nie sterujemy nim. Wszystko, co robimy, sprowadza się do stworzenia nieprzeciekającej warstwy abstrakcji dla programistów tak, aby mogli pisać wspaniały kod i aby ten kod mógł dotrzeć do klientów, którzy na tym skorzystają.

Programiści potrzebują repozytorium Subversion. Dostarczenie Subversion wymaga posiadania sieci, serwera, który musi być kupiony, uruchomiony, utrzymywany, muszą być wykonywane kopie zapasowe, musi być zaopatrzony w niezawodne źródło zasilania, a taki serwer wytwarza dużo ciepła, co oznacza, że musi on stać w pomieszczeniu z dodatkową klimatyzacją, a ta klimatyzacja musi być wyprowadzona na zewnątrz budynku, co oznacza także zamontowanie 35-kilogramowego wiatraka na zewnętrznej ścianie budynku, co oczywiście denerwuje właścicieli budynku, muszą oni wezwać inżynierów, którzy określą gdzie najlepiej powiesić wiatrak (decyzja: na zewnętrznej ścianie, na osiemnastym piętrze, w najbardziej niewygodnym możliwie miejscu), no a to przywołuje od razu prawników, ponieważ musimy zrzec się swojego pierworodnego, aby móc wykonać taką instalację, a potem instalatorzy klimatyzacji zjawiają się z przyrządami do asekuracji godnymi zestawu dla Barbie, co z kolei denerwuje naczelnika, który nie pozwala na wyjście na zewnątrz budynku na osiemnastym piętrze w uprzęży firmy Mattel zrobionej z centrymetrowego różowego plastiku (przysięgam na Boga, że to mógłby być pas dyskotekowy Barbie), no i ktoś znowu musi wezwać agenta tego budynku, żeby sprawdzić dlaczego nagle uświadomili sobie (12 tygodni po zatwierdzeniu planu instalacji), że potrzebny jest kolejny aneks do umowy przez tę przeklętą klimatyzację, o której wiedzieli przed Bożym Narodzeniem, a dopiero zaczęli sobie zdawać z niej sprawę, i jeśli twoi programiści spędzą choćby minutę na zastanawianie się nad tym wszystkim, to spędzili o jedną minutę za dużo.

Dla programistów, to wszystko powinno być przykryte abstrakcją, taką jak pisanie svn commit w linii poleceń.

To jest powód, dla którego masz menadżerów.

Wszystkie te rzeczy są niezbędne do funkcjonowania firmy, ale jeśli programiści zaczynają się nimi martwić, to zarządzanie zawiodło, tak samo jak 30 metrowy jacht zawiódł, jeśli właściciel-milioner musi zejść pod pokład żeby, hmm, zbudować silnik.

Mamy typowe firmy założone przez byłych sprzedawców, gdzie wszystko jest Sprzedażą Sprzedażą Sprzedażą i wszyscy istniejemy po to, aby napędzać większą sprzedaż. Takie firmy rozpoznajemy w przyrodzie po tym, że wypuszczają wersję 1.0 oprogramowania (jakoś) i wtedy zupełnie tracą zainteresowanie produkowaniem oprogramowania. Ich drużyna programistów jest zagłodzona albo po prostu nie istnieje, bo nigdy nie udaje się im zbudować wersji 2.0... cała wiedza ich menadżerów sprowadza się do tego, jak wygenerować większą sprzedaż.

Po drugiej stronie mamy kolejne ekstremum - firmy założone przez byłych programistów. Te firmy są trudniejsze do odnalezienia, ponieważ zazwyczaj siedzą cichutko, polerując gdzieś na poddaszach kod, którego nikt nigdy nie odnajdzie, oni sami popadną powoli w zapomnienie zaraz po Wielkim Przepisaniu Systemu na Ruby, a ich kod po refaktoringu-zmieniejącym-świat będzie jakoś niedoceniony przez Ludzi.

Oba typy firm mogą być z łatwością wyparte przez firmy napędzane przez programistów i zorganizowane, aby posadzić programistów w fotelach kierowców, ale także posiadające wspaniałą abstrakcję, która wykonuje tę ciężką pracą przekuwając kod w produkt gdzieś pod pokładem.

Programista jest najbardziej produktywny w cichym, prywatnym biurze, ze wspaniałym komputerem, nielimitowanymi napojami, temperaturze otoczenia między 20 a 22 stopniami Celsjusza, bez odblasków na monitorze, na krześle, które jest tak wygodne, że go nie czujesz, z administratorem, który przynosi mu jego pocztę, zamawia podręczniki i książki, administratorem systemu, który sprawia, że Internet jest dostępny jak tlen, testerem, który znajdzie błędy, których po prostu nie sposób zobaczyć, grafikiem komputerowym, który sprawi, że ekrany interfejsu będą wyglądać pięknie, zespołem speców od marketingu, który sprawi, że masa ludzi będzie pragnąć jego produktu, zespołem sprzedawców, który sprawi, że masa ludzi dostanie jego produkt, jakichś anielsko cierpliwych ludzi od wsparcia technicznego, którzy pomogą klientom w pracy z oprogramowaniem, a także pomogą zrozumieć programistom, jakie problemy może ono stwarzać, do tego jakiś tuzin innych funkcji administracyjnych i organizacyjnych, które razem sumują się do 80% wszystkich wynagrodzeń. To nie przypadek, że Armia Rzymska miała proporcje czterech służących na jednego żołnierza. To nie była dekadencja. Nowoczesne armie prawdopodobnie mają proporcje 7:1. (A tutaj coś, czego nauczył mnie dzisiaj Pradeep Singh: jeśli tylko 20% Twojego zespołu to programiści i możesz oszczędzić 50% na ich wynagrodzeniu przenosząc oddział programistów do Indii - jak dużo przewagi wśród konkurencji możesz tak naprawdę wytworzyć z tych 10% oszczędności?)

Podstawowym zadaniem menadżerów ma być wytworzenie iluzji, że firmę da się prowadzić przez samo pisanie kodu, bo to jest właśnie to, co robią programiści. I nawet gdyby byłoby całkiem miło mieć programistów, którzy znają się na sprzedaży, grafice komputerowej, administracji systemów, gotowaniu, to jest to nierealne. To jakby chcieć nauczyć świnię śpiewać - Ty tracisz swój czas, a świnia się tylko denerwuje.

Microsoft jest bardzo dobry w tworzeniu tej iluzji tak, że ludzie, którzy odchodzą z Microsoftu notorycznie męczą się zakładając swoje własne firmy. Nie mogą po prostu uwierzyć, jak dużo działo się pod pokładem i nie wiedzą, jak to zreprodukować.

SCal4

Nikt nie oczekuje, że Dolly Parton będzie wiedziała, jak podłączyć mikrofon. Tam jest niesamowicie wielka infrastruktura menadżerów, muzyków, techników nagrań, firm nagraniowych, techników obsługujących koncerty, fryzjerów i publicystów pod spodem, która jest po to, aby sprawiać wrażenie, że samo fakt śpiewania Dolly wystarczy, żeby usłyszało ją milion ludzi. Cały ten zespół menadżerów i ludzi z obsługi wykonuje swoją pracę jak najlepiej wtedy, kiedy tworzy najbardziej perfekcyjną abstrakcję: najbardziej perfekcyjną iluzję, że Dolly śpiewa dla nas. To jest jej piosenka. Kiedy słuchasz jej na swoim iPodzie, potężna infrastruktura sprawia, że jest to możliwe, ale najlepsze, co może zrobić ta infrastruktura, to stać się kompletnie niewidoczną. Dostarczyć nieprzeciekającą abstrakcję, że Dolly śpiewa tylko dla nas.

Data publikacji oryginału: 11 kwietnia, 2006


9 komentarze:

Anonimowy pisze...

Fajny artykuł i dobre tłumaczenie.
Można go porównać do faktu, iż nie ma sensu pisać oprogramowania od zera dla samego pisania, ale korzystać z gotowych, sprawdzonych bibliotek (niekoniecznie cudzych), by skupić się na konkretnej funkcjonalności, a nie mieć wszystko na głowie.

mXs pisze...

@Anonimowy
To, o czym piszesz jest z kolei świetnie naświetlone przez Spolsky'ego tutaj: http://www.devblogi.pl/2010/07/rzeczy-ktorych-nigdy-nie-powinienes.html.
Przepisywanie systemu zazwyczaj nie jest dobrym pomysłem.

Rafał pisze...

Dzięki za tłumacznie. Dla mnie najciekawsze okazały się zdania: "Oprogramowanie to rozmowa między użytkownikiem a programistą.", "Myślą (menadżerowie) o zarządzaniu w kategoriach tradycyjnego podejścia Rozkazuj-I-Zdobywaj (Command-and-Conquer), którego nauczyli się z hollywoodzkich filmów.", "Oba typy firm mogą być z łatwością wyparte przez firmy napędzane przez programistów i zorganizowane ...". Artykuł przekazuje brutalną prawdę o jednoosobowych firmach - warto sobie uświadomić, że programista powinien tylko programować.

mXs pisze...

@Rafał
Jednoosobowe firmy, to raczej etap podbierania zleceń z Kawiarni Programistów.
Ale z drugiej strony patrząc na "nowoczesne" typy aplikacji na Androida, iPhone'a, Facebook'a czy aplikacje typu Twitter, to wydaje się, że programista sam w pojedynkę jest w stanie odnieść sukces.
Ale prawdą jest na pewno, że zazwyczaj udaje się tym, którzy nie traktują takiej działalności jako priorytetowy biznes. Bo jak już jest priorytetowy, to mają administracji w stosunku 4:1 lub 7:1 :)
Pozdrowienia!

Rafał pisze...

@mXS
Dzięki za odpowiedź :) Chciałbym tylko dodać, że nawet jeżeli programista działa tylko dorywczo, to i tak musi pomyśleć o marketingu, grafice, itd.

Anonimowy pisze...

Świetne. Jak to człowiek może czasem coś o sobie przeczytać...

Anonimowy pisze...

Oczywista oczywistość, z którą nie można się nie zgodzić. Sztandarowy środek literacki Joela Spolskiego.

Tomasz Kowalczyk pisze...

Jeden z najbardziej wnikliwych artykułów jakie do tej pory zobaczyłem na devBlogach. Widać wyraźnie różnicę pomiędzy dobrym, a genialnym programistą. ;]

mXs pisze...

@Tomasz Kowalczyk
Jest kilka naprawdę dobrych artykułów Joela, godnych polecenia. Nie będę ich tutaj wszystkich wymieniał, ale ten, o którym mowa - rzeczywiście spodobał się nam na tyle, że jest na devBlogach:)
Cieszę się, że się podoba...

Powodzenia w drodze od dobrego do genialnego (bo to nieustająca droga, prawda?) :)

Prześlij komentarz

Related Posts with Thumbnails