Inżynieria oprogramowania - martwa?

Oryginalny post: Software Engineering: Dead?

Autor: Jeff Atwood

Po przeczytaniu nowego artykułu (pdf) z IEEE autorstwa Toma DeMarco byłem całkowicie zaskoczony. Sam się przekonaj dlaczego:

Moja wczesna książka o metrykach, Controlling Software Projects: Management, Measurement, and Estimates [1986], odegrała pewną rolę w tym, jak moi koledzy programiści mierzyli swoją pracę oraz planowali swoje projekty. W moim pełnym zadumy nastroju myślę sobie, czy te rady zawarte w książce były wtedy odpowiednie, czy nadal jest aktualna, oraz czy nadal uważam, że metryki są konieczne dla pomyślnego tworzenia oprogramowania? Moje odpowiedzi to: nie, nie i nie.

Powoli dochodzę do wniosku, że inżynieria oprogramowania jest pewną ideą, której czas nadszedł i się skończył.

Tworzenie oprogramowania jest i zawsze będzie poniekąd eksperymentalne. W istocie sama konstrukcja oprogramowania niekoniecznie jest eksperymentalna, ale koncepcje za nim stojące są. I to właśnie na to powinniśmy kierować naszą uwagę. To tam nasza uwaga powinna była być skupiona od zawsze.

Jeśli Twoja głowa właśnie eksplodowała, nie przejmuj się. Moja też. Aby nieco zredukować ten ból głowy, którego możesz teraz doświadczać po przeczytaniu powyższego streszczenia, gorąco polecam przejrzenie całego, dwustronicowego artykułu.

Tom DeMarco jest jednym z bardziej szanowanych autorytetów w przemyśle oprogramowania, będąc współautorem znakomitej i nowatorskiej książki zatytułowanej Peopleware oraz wielu niemal klasycznych książek o zarządzaniu projektami, jak na przykład Waltzing With Bears. Jak na gościa kalibru Toma, jego doświadczenia oraz wpływu, wyjść i wypalić, że inżynieria oprogramowania jest martwa...

... tak jak kiedyś powiedział Keanu Reeves, whoa.

To wielka sprawa, przerażająca.

Ale jest to również pewna ulga. Mnie kamień spadł z serca. Mogę publicznie przyznać to, z czego powoli i stopniowo zacząłem sobie zdawać sprawę przez ostatnie 5 czy 10 lat mojej kariery jako programista: to co robimy to rzemiosło, nie inżynieria. I mogę to powiedzieć z dumą, nie wstydząc się, bez cienia zwątpienia w siebie.

Myślę, że Joel Spolsky, mój partner od interesów, miał podobne objawienie. Napisał o tym w How Hard Could It Be?: The Unproven Path:

Mam całkiem głęboko zakorzenione wizje na temat tego, jak powinno się tworzyć oprogramowanie, ale trzymam je głównie dla siebie. Okazało się to dobrą rzeczą, ponieważ jak tylko organizacja zaczęła nabierać kształtu, wszystkie te zasady zostały porzucone.

Cały czas staram się dojść do tego, co to wszystko ma oznaczać. Porzuciłem siedem długo utrzymywanych zasad dotyczących biznesu oraz inżynierii oprogramowania i nic strasznego się nie stało. Czy byłem kiedyś za bardzo rozważny? Może chciałem być troszkę lekkomyślny, ponieważ to był tylko mój projekt poboczny, a nie mój główny interes. Doświadczenie jest bez wątpienia użytecznym przypominaczem, że dobrze jest być beztroskim, gdy buduje się coś nowego i nie ma się pojęcia, w którą stronę to zmierza.

Pewnie, mógłbym jeszcze wymienić sporo zastrzeżeń odnośnie inżynierii oprogramowania dotyczących szczegółów projektu, nad którym właśnie pracujesz: jego rodzaju (przełomowy, oczywiście), jego rozmiaru (na miarę Google, naturalnie), jego publiczności (miliony użytkowników, w rzeczy samej) i tak dalej.

Ale tego nie zrobię.

To co DeMarco wydawał się mówić -- a przynajmniej to, co ja stanowczo mówię -- to to, że kontrola jest całkowicie iluzoryczna jeśli chodzi o projekty programistyczne. Jeśli chcesz popychać swój projekt do przodu, to jedynym sposobem jest kultywowanie głębokiego poczucia rzemiosła i profesjonalizmu wokół niego.

Faceci i kobiety, którzy dzień w dzień pełni są entuzjazmu odnośnie doskonalenia swojego rzemiosła, którzy z pasją tworzą rzeczy o dużym znaczeniu dla nich, a może nawet w jakiejś części także dla reszty świata -- to są właśnie ci ludzie i te projekty, którzy ostatecznie odniosą sukces.

Cała reszta to tylko zakłócenia.

1 komentarze:

godlark pisze...

Jakoś nigdy nie mogłem przełknąć tego, że żeby zaprojektować aplikację, będę musiał sobie diagramy w UML-u rysować. Szkice mogę narysować, ogólny zarys. Kształt klas, kodu okazuje się w praniu ;)

Prześlij komentarz

Related Posts with Thumbnails