Niedawno internet obiegła poltka głosząca, iż po raz kolejny polski system stał się ofiarą ataku hakerskiego. Nie chodzi tutaj bynajmniej o ataki na strony premiera związane z wprowadzeniem ACTA ale "atak" na system prawny. Najnowszy hak to przerobienie samochodu na bankowóz tak aby móc odliczyć za niego VAT. I Chociaż o tym temacie specjalistą nie jestem to szukając informacji po necie natrafiłem na masę wpisów w stylu "jak wykorzystać luki w systemie na swoją korzyść".Coś dobudujemy,coś przystosujemy i odpowiednio zaksięgujemy.
No fajnie ale co ta informacja robi na blogu,który choć trochę, zajmuje się kwestiami programistycznymi?
Otóż :
Kroczą po tym świecie ludzie, którzy uważają, że programisci to debile.
Od murowania...
Co rusz na forach dyskusyjnych napotykam się na opinie głoszące : "programista jest jak murarz". Chciałbym w tym momencie móc zaznaczyć, że owe opinie tworzy jakaś określona - łatwo rozpoznawalny zbiór ludzi lecz niestety klasyfikacja ta nie jest taka prosta. Do tej grupy niestety zalicza się cały przekrój ról projektowych.
Na chwilę obecną dzielę owych osobników na dwie grupy :
- ludzi dążących do zbytniego uproszczenia rzeczywistości
Tutaj dosyć często pojawiają się programiści przemianowani na project managerów.Być może ze względu na zbyt małe doświadczenie w nowej roli a być może ze względu na jakieś introwertywne cechy charakteru próbują oni zredukować dynamiczne i nieliniowe prawa zachodzące w grupie do prostych zasad w stylu programista jest jak murarz i powinien słuchać a nie dyskutować.
- ludzi posiadających jakieś nieuświadomione kompleksy wymagające ciągłej kompensacji.
Wiem coś o tym bo sam to miałem. Polega to na deprecjonowaniu każdej odmiennej roli w projekcie. Taki rasizm projektowy. Manager będzie twierdził, że jego obowiązki są kluczowe dla projektu, i każdy musi się mu podporządkować, podobnie analityk, programista czy ktoś tam inny.
A prawda jest taka, że nie ma roli "ważniejszej". ale o tym kiedy indziej
...do stanowienia prawa
Dlaczego wcielanie w życie projektu IT nie jest jak budowanie domu?
Weźmy kawałek kodu :
public class App
{
public static void main( String[] args )
{
System.out.println( "Dupa" );
}
}
Pytanie : co sie właśnie stało?
Otóż nic się nie stało!! Ten kod tutaj nie zadziała podobnie jak wklejenie planów domu na stronę nie sprawi, że zbuduje się nagle dom. TAK!!! owe instrukcje to plany architektoniczne dla kompilatora jak ma zbudować wykonywalny kod maszynowy. Czy to jednak znaczy, że metafora jest dobra a programista jest jak architekt budynków?
No też nie. Każdy kto czyta tego bloga może sobie przekleić ów kod, (jeśli tylko ma zainstalowane JDK) skompilować i być świadkiem narodzin działającej funkcjonalności.
Gdybym umieścił tutaj plany budowy domu to również każdy mógłby je skopiować a później.., no właśnie co później. Trzeba by znaleźć jakąś firmę, która by owe plany wprowadziła w życie.
Cegła w IT jest ku*wa mać za darmo!!!!
W przeciwieństwie do budowy domu mogę zrobić prototyp, pokazać go klientowi a później wyrzucić. Mogę sobie robić refactoring (ta, jestem ciekaw czym w budowaniu domu miałby być refaktoring) i masę innych rzeczy, które po prostu nie miałyby miejsca przy budowaniu domu bo tam takie zabawy kosztują.
Gdzie jeszcze można tak swobodnie manipulować produktem?
Polskie prawo to jeden wielki kod źródłowy , bez żadnych testów jednostkowych, który jest non stop interpretowany przez przeróżne organy. Do czasu wypuszczenia produktu na produkcję można prototypować rozwiązania, robić przeróżne refactoringi czy hot fixy na znalezione bugi - buble prawne. Ostatnia sławna poprawka podegrana na produkcje zdaje się naprawiała bug z lekarzami i aptekarzami.
Podobieństw jest oczywiście więcej ale bynajmniej nie chodzi tutaj o to aby problemy w IT rozwiązywać poprzez analogie do systemu prawnego. Sądzę nawet, że wzór mógłby działać w przeciwną stronę. Jednak to co tutaj chcę uzyskać to skończyć ze stosowaniem zjebanych metafor projektów IT i wiążącym się z tym pewnym błędem logicznym :
Jeśli dziedzina A jest w jakimś stopniu taka jak dziedzina B to wtedy wszystkie problemy w A można rozwiązać poprzez analogiczne rozwiązania w B
Także jeszcze raz dużymi literami : PROJEKT IT NIE JEST JAK BUDOWANIE DOMU A PROGRAMIŚCI TO NIE MURARZE !
EDYCJA:
Natrafiłem an ciekawą prezentację, która w pewnym stopniu porusza przedstawiony tutaj temat.Oto ona:
http://www.infoq.com/presentations/Questions-for-an-Enterprise-Architect
