Co to znaczy "dobrze napisać artykuł"?

Zainteresowałem się ostatnio na poważnie (z racji książki którą piszę) problematyką sprawnego władania językiem... polskim, z naciskiem na język pisany. Kupiłem opasłe tomisko traktujące o tymże języku i rozpocząłem mozolne (książka jest niezwykle gruba) studia. A tymczasem dostaję komentarz czytelnika do mojego ostatniego artykułu - że jest nieczytelny (choć merytorycznie dobry), z racji braku podziału na akapity.

Postanowiłem więc przeprowadzić eksperyment i przeredagowałem tekst co nieco. Tekst podzieliłem na akapity, które przy okazji przekonstruowałem tak, by nadać im w miarę możliwości charakter analityczny.

Akapit analityczny (powtarzam z pamięci za książką o której przed chwilą wspomniałem) to taki akapit, który zaczyna się od natychmiastowego - w pierwszym zdaniu - przedstawienia treści akapitu. Dalsze zdania stanowią rozwinięcie i wyjaśnienie stwierdzenia otwierającego akapit. Chodzi o to, aby dało się czytając tylko pierwsze zdania każdego akapitu wyłapać sens i tematykę tekstu. Naturalnie nie zawsze i nie każdy akapit powinien być właśnie taki - urozmaicenie formy też jest wskazane.

Zobaczmy co z tego wyszło i czy jest lepiej. Oto artykuł "Co to znaczy "dobrze wykonać projekt"?" w wersji 2.0:

Co to właściwie znaczy „dobrze wykonać projekt”? Zamyśliłem się co nieco nad tym inspirowany konferencją, na której ostatnio zdarzyło mi się gościć, a właściwie tym co tam usłyszałem. Widziałem na konferencji świetną prezentację o programowaniu sterowanym testami – brawa dla prelegenta; na innej prelekcji z kolei słyszałem uszczypliwe żarty ze strony publiki wykpiwającej praktyki wykonywania poprawek (tzn. bug-fixów) bezpośrednio na systemie produkcyjnym. Ktoś tam jeszcze mówił o ciągłej integracji (na tej prelekcji nie byłem), ktoś inny w jeszcze inny sposób promował techniki i sposoby tworzenia „dobrego” oprogramowania.

Odnoszę wrażenie, że wszyscy jako aksjomat przyjmują, że aplikacja powinna być zrobiona przede wszystkim „dobrze”; możliwie kompleksowo przetestowana, możliwie jak najprzyzwoiciej wdrożona.

Ja tymczasem mam wrażenie, że w rzeczywistości rzadko chodzi o osiągnięcie właśnie tych celów. Właściwie wymienione powyżej to raczej środki do pewnego celu a nie same cele, tylko czy rzeczywiście zastanawiamy się nad tym, co jest prawdziwym celem?

Oczywiście wszyscy mamy potrzebę odczuwania zadowolenia z wykonywanej przez siebie pracy – a satysfakcję mamy przeważnie z pracy wykonanej dobrze – tyle tylko, że może nie do końca potrafimy sobie zdefiniować, co to „dobrze” oznacza.

Dobrze – w pewnej konkretnej sytuacji – może przecież oznaczać przede wszystkim szybko. Może firma która zleca nam wykonanie jakiegoś rozwiązania ma w planach zakup albo wykonanie poważnego systemu w przyszłości a póki co chcą tylko czegoś taniego i wykonanego szybko, po to by móc dodać do swej oferty możliwie szybko nowy produkt; po to by pomóc sobie samemu zdefiniować wymagania funkcjonalne dla aplikacji docelowej? A może są jeszcze jakieś inne powody? A może nie powinniśmy się zastanawiać dlaczego? Może po prostu powinniśmy słuchać i starać się odpowiadać na rzeczywiste zapotrzebowania, zgłaszane przez tego, który za implementację nowego rozwiązania zapłaci?

To co staram się powiedzieć można de facto wyrazić w jednym zdaniu – dopasowujmy sposób pracy (sposób wykonywania i wdrażania rozwiązań) do faktycznych celów i istniejących założeń, nie do aksjomatów narzuconych nam nie wiadomo jak, kiedy i przez kogo.

Pamiętajmy jednak aby nie popadać ze skrajności w skrajność. Gdybyśmy rzeczywiście zechcieli kiedyś pokusić się o dostarczenie rozwiązania-prowizorki, nie zapominajmy, że prowizorki często są najtrwalsze. A jeśli już zdecydujemy się na wypuszczenie naprędce upichconego gniota, to liczmy się z tym, że ktoś kiedyś – nie rozumiejąc okoliczności – zapyta… „kto tą aplikację (…) wykonał”? No ale sztuka kreowania wizerunku i zabezpieczania się przed potencjalnymi atakami to już inny temat.