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