jutro będę duży...
wersja archiwalna
09.01.2004 : niegramotne muchozole
zadanie było sformułowane dosyć prosto: wdrożyć BTS (choć oczywiście szefostwo nie posługuje się takimi dosłownymi sformułowaniami ;-)), nie za wielki ale sprawny i przede wszystkim darmowy..
z jakichś nie całkiem dla mnie dziś zrozumiałych przyczyn postanowiłem zachować spójność technologii, czyli znaleźć coś takiego na platformę Windows.. no i wyglądało na to, że znalazłem — Bugs Online.. możliwości tego narzędzia nie są powalające, ale dla kilkuosobowego zespołu w sam raz.. i nawet na licencji GPL, czyli można by to trochę pod siebie dostosować.. próbna instalacja na moim kompie wykazała, że soft jest w miarę sprawny, główny analityk zaakceptowała takie rozwiązanie, programiści się nie burzyli — wszystko gra(ło)..
niestety instalacja i próba pracy na systemie docelowym wykazała niezbicie (nie po raz pierwszy zresztą), że połączenie IIS + ASP + ADODB + MS Access jest funta kłaków nie warte — jednym słowem: "Unspecified Error" :-(
w końcu postanowiłem rzucić to wszystko w cholerę i zainstalować coś, co na pewno działa, a przede wszystkim chodzi na Jakiejś Sensownej Platformie™.. idąc po najmniejszej linii oporu (a jakże), zacząłem od Krasnala.. no a na tym już FlySpray i .... hula aż miło.. trzeba było od tego zacząć :-)
ale to tylko tytułem wstępu — historie, w których po długich bojach z technologią główny bohater znajduje ukojenie w ramionach Wolnego Oprogramowania można by mnożyć bez końca.. a ja właściwie nie o tym chciałem...
stwierdzenie, że wszelkie technologie Cokolwiek Tracking System nie zdają się na nic jeśli ludzie nie umieją się porozumiewać, jest co najmniej banalne.. a jednak fakt ten zaatakował mnie dosyć brutalnie już po jednym dniu używania wspomnianego FlySpraya.. no bo co mi z tego, że istnieje jakiś system umożliwiający w miarę zorganizowany sposób obsługę błędu/zgłoszenia/zadania, skoro zawiera on opis stworzony przez człowieka mającego problemy z werbalizacją myśli — jeśli z opisu nie można zrozumieć o co w danym zgłoszeniu chodzi, to może lepiej żeby w ogóle tego zgłoszenia nie było..?
stąd ważne a nie od razu oczywiste wymaganie dla dowolnego członka zespołu rozwoju oprogramowania — umiejętność zrozumiałego wysławiania się...
z jakichś nie całkiem dla mnie dziś zrozumiałych przyczyn postanowiłem zachować spójność technologii, czyli znaleźć coś takiego na platformę Windows.. no i wyglądało na to, że znalazłem — Bugs Online.. możliwości tego narzędzia nie są powalające, ale dla kilkuosobowego zespołu w sam raz.. i nawet na licencji GPL, czyli można by to trochę pod siebie dostosować.. próbna instalacja na moim kompie wykazała, że soft jest w miarę sprawny, główny analityk zaakceptowała takie rozwiązanie, programiści się nie burzyli — wszystko gra(ło)..
niestety instalacja i próba pracy na systemie docelowym wykazała niezbicie (nie po raz pierwszy zresztą), że połączenie IIS + ASP + ADODB + MS Access jest funta kłaków nie warte — jednym słowem: "Unspecified Error" :-(
w końcu postanowiłem rzucić to wszystko w cholerę i zainstalować coś, co na pewno działa, a przede wszystkim chodzi na Jakiejś Sensownej Platformie™.. idąc po najmniejszej linii oporu (a jakże), zacząłem od Krasnala.. no a na tym już FlySpray i .... hula aż miło.. trzeba było od tego zacząć :-)
ale to tylko tytułem wstępu — historie, w których po długich bojach z technologią główny bohater znajduje ukojenie w ramionach Wolnego Oprogramowania można by mnożyć bez końca.. a ja właściwie nie o tym chciałem...
stwierdzenie, że wszelkie technologie Cokolwiek Tracking System nie zdają się na nic jeśli ludzie nie umieją się porozumiewać, jest co najmniej banalne.. a jednak fakt ten zaatakował mnie dosyć brutalnie już po jednym dniu używania wspomnianego FlySpraya.. no bo co mi z tego, że istnieje jakiś system umożliwiający w miarę zorganizowany sposób obsługę błędu/zgłoszenia/zadania, skoro zawiera on opis stworzony przez człowieka mającego problemy z werbalizacją myśli — jeśli z opisu nie można zrozumieć o co w danym zgłoszeniu chodzi, to może lepiej żeby w ogóle tego zgłoszenia nie było..?
stąd ważne a nie od razu oczywiste wymaganie dla dowolnego członka zespołu rozwoju oprogramowania — umiejętność zrozumiałego wysławiania się...
z cyklu: software development w praktyce | 2 komentarze
11.09.2003 : między odpornością a ignorancją
— odporność na stres.. w skali 0 do 3nie dość, że tego typu ankieta, niby badanie zdolności pracowników, jest z zasady do dupy, to jeszcze moje odpowiedzi się nie podobają... a przecież to ja powinienem wiedzieć czy moja odporność jest bliższa zera czy trójki raczej.. skoro mówię, że dwa, to rozumiem, że nie wszystko po mnie spływa, ale jednak się nie załamuję pod byle groźbą czy podejrzeniem zawalenia projektu.. rozumiem chyba, że jeśli projekt jest na drodze do klęski to już na niej będzie do niechlubnego końca, ale bynajmniej nie znaczy to, że wokół powinny się posypać nekrologi.. może nawet chwilami uwierzę w istnienie czegoś takiego jak "stres mobilizujący"..
— no... powiedzmy dwa
— o nie, nie.. ja panu nie daję więcej niż jeden....
a tymczasem słucham dalej:
— 3 to ma RR, którego nic nie rusza....czyli okazuje się, że znowu nic nie zrozumiałem — "posiadanie odporności na stres" w projekcie informatycznym to postawa typu: "robię co mi każą (czasem naprawdę, częściej udaję) i mam głęboko gdzieś to, co się dzieje wokół i czy ten statek tonie, czy jeszcze nie teraz"...
wygląda na to, że Wally nie wziął się znikąd.. :-/
z cyklu: software development w praktyce |
03.07.2003 : kret?
rozmyślania poboczne (niestety nie bez podstaw) na temat poprzedniego wpisu — jak bardzo programista, który [czuje|podejrzewa|wie], że [być może|prawdopodobnie|na pewno] zostanie zwolniony, może namieszać w programie, nad którym pracuje..? ile z tych głupot, które (niewątpliwie?) narobi wynika ze stresującej sytuacji, ile z roztargnienia i ze znudzenia tą niedługo-jeszcze-pracą, a ile z chęci zemsty (jakkolwiek rozumianej)..? i w ogóle, przeciw komu takie działania są skierowane..?
sytuacja niemiła — zmęczenie, rozczarowanie, poczucie straty czasu i niepotrzebnie zainwestowanego zaufania...
sytuacja niemiła — zmęczenie, rozczarowanie, poczucie straty czasu i niepotrzebnie zainwestowanego zaufania...
z cyklu: software development w praktyce | 1 komentarz
01.07.2003 : polityka czy ewolucja?
żyjemy w dobie globalnego kryzysu — w czasie niepokoju, zagrożenia, bezrobocia — wiadomo, przypominają nam to masmedia od świtu do świtu.. znacznie łatwiej dzisiaj być zwolnionym z pracy, niż znaleźć możliwość spełnienia planów i realizacji ścieżki kariery.. ludzie są zwalniani często nie z winy własnej nieudolności, a raczej na skutek nieporadności przełożonych i/lub nierealnych wymagań.. dokonujesz cudu, spełniasz kaprysy albo wylatujesz — to coraz częściej normalne założenie..
czasem jednak zdarza się coś takiego, co sugeruje, jakby działało tutaj coś w rodzaju sprawiedliwości — że mniej to zależy od jakiejś pokręconej, krwawej polityki, czy od tego kto komu robi loda, ale zwyczajnie wykrusza się ten, który wydaje się mniej sprawny niż inni.. może chwilami jest właśnie tak, jak ma być i może to wszystko ok, że będzie nas w zespole mniej..
ale w końcu, co ja mogę o tym wiedzieć...?
czasem jednak zdarza się coś takiego, co sugeruje, jakby działało tutaj coś w rodzaju sprawiedliwości — że mniej to zależy od jakiejś pokręconej, krwawej polityki, czy od tego kto komu robi loda, ale zwyczajnie wykrusza się ten, który wydaje się mniej sprawny niż inni.. może chwilami jest właśnie tak, jak ma być i może to wszystko ok, że będzie nas w zespole mniej..
ale w końcu, co ja mogę o tym wiedzieć...?
z cyklu: software development w praktyce | 1 komentarz
04.06.2003 : mowa jest zatem...
wyobraź sobie, że jesteś producentem pojazdów rolniczych (różnorakich — trafiały Ci się zarówno zdalnie sterowane kosiarki do trawy jak i latające kombajny zbożowe).. załóżmy, że dostałeś zlecenie zbudowania nowego modelu traktora z napędem na sześć kół, który poruszałby się po każdym możliwym terenie i umożliwiał podłączenie do niego dowolnej innej maszyny bez względu na warunki terenowe i kierunek grawitacji.. powiedzmy, że nawet udało Ci się zrobić jakieś skrzyżowanie jeepa z poduszkowcem i że przy pewnych sprytnych założeniach, przy kilku sztucznie podtrzymywanych modyfikacjach przestrzeni oraz zaledwie paru zaprzeczonych prawach fizyki całe ustrojstwo działa, a z daleka nie wygląda źle.. i do tego zmieściłeś się prawie w terminie..
a potem, jako wyjaśnienie pewnego spornego fragmentu w prawie już zrealizowanym zamówieniu, dostajesz taki tekst:
śmieszne? nie wiem.. nieprawdziwe? może.. przesadzone? nie bardzo..
wystarczy, że zamiast pojazdów rolniczo-terenowych wstawimy systemy informatyczne dla instytucji finansowych, zamiast trudnego terenu — szeroko parametryzowalne produkty finansowe, a zamiast paliwa — kilka szczegółów księgowych i już taka historyjka robi się prawdziwa, niemal codzienna i ani trochę nie śmieszna...
a potem, jako wyjaśnienie pewnego spornego fragmentu w prawie już zrealizowanym zamówieniu, dostajesz taki tekst:
W zleceniu nie jest uszczegółowiona kwestia sposobu zasilania pojazdu, nie możemy zatem mówić, iż nie jest w zleceniu uwzględniona możliwość stosowania różnych rodzajów paliwa. Mowa jest zatem o stosowaniu paliwa zarówno w postaci oleju rzepakowego jak i paliwa do silników rakietowych.dobra, po tym wszystkim co to coś już robi, może działać w ogóle na deszczówkę, spoko.. ale..., zaraz, jak to szło...?
nie jest uszczegółowiona kwestia .... nie możemy zatem mówić, iż nie jest uwzględniona możliwość .... mowa jest zatem o stosowaniu zarówno .... jak i ....no tak, logika nie do zaprzeczenia.. zatem wygląda na to, że przeoczyłeś kilka alternatywnych źródeł zasilania i nie wiadomo ile jeszcze nie uszczegółowionych zagadnień! najprostsza, pierwsza z brzegu rzecz — kwestia wyżywienia załogi również nie była uszczegółowiona, więc jak mogłeś założyć, że na pokładzie nie ma być całodobowej restauracji kuchni orientalnej!? reasumując dosadnie — dałeś dupy....
śmieszne? nie wiem.. nieprawdziwe? może.. przesadzone? nie bardzo..
wystarczy, że zamiast pojazdów rolniczo-terenowych wstawimy systemy informatyczne dla instytucji finansowych, zamiast trudnego terenu — szeroko parametryzowalne produkty finansowe, a zamiast paliwa — kilka szczegółów księgowych i już taka historyjka robi się prawdziwa, niemal codzienna i ani trochę nie śmieszna...
z cyklu: software development w praktyce |
19.05.2003 : kolejny kandydat na zbawiciela
znowu to samo zdanie, które słyszałem już tak wiele razy, że potrafię je wygłosić z pamięci po obudzeniu w przysłowiowym środku nocy — inżynieria oprogramowania, czy nawet IT w ogólności, to biznes o niewiarygodnym wręcz procencie niepowodzeń.. tym razem zostało to poparte zupełnie nie zaskakującymi liczbami:
za to na pewno warto zaprezentować (a z mojej strony obejrzeć) i sprzedać (a z mojej strony tylko obejrzeć) kolejne zupełnie nowe, oczywiście całkowicie genialne, jedyne, niepowtarzalne, niezaprzeczalnie rewolucyjne i ponownie dystansujące konkurencję rozwiązanie tego paradoksalnego problemu.. tym razem jest to CaliberRM + StarTeam + TogetherJBE oraz OptimizeIt jako kropka nad i..
fajnie, pięknie, narzędzia ciekawe, możliwości imponujące, głos prezentującego usypiający, "jeśli potrzeba to kolega zapewne przedstawi odpowiednie case study", kawa dziwnie śmierdząca, wersje 30dniowe do pobrania z sieci — słowem: standardowa prezentacja z gatunku "kupiliśmy pięć mniejszych firm i teraz mamy komplet niezbędny do zbawienia świata".. szkoda tylko, że po pierwsze miałem dzisiaj urlop(!), a po drugie rzecz odbywa się w stolicy, czyli współczynniki D-S-P wychodzą raczej kiepskie: 4-4-4
- 14% projektów zakończonych powodzeniem
- 7% projektów, które tylko jedna strona uznaje za udane
- 79% projektów uznanych przez obie strony za klęskę
za to na pewno warto zaprezentować (a z mojej strony obejrzeć) i sprzedać (a z mojej strony tylko obejrzeć) kolejne zupełnie nowe, oczywiście całkowicie genialne, jedyne, niepowtarzalne, niezaprzeczalnie rewolucyjne i ponownie dystansujące konkurencję rozwiązanie tego paradoksalnego problemu.. tym razem jest to CaliberRM + StarTeam + TogetherJBE oraz OptimizeIt jako kropka nad i..
fajnie, pięknie, narzędzia ciekawe, możliwości imponujące, głos prezentującego usypiający, "jeśli potrzeba to kolega zapewne przedstawi odpowiednie case study", kawa dziwnie śmierdząca, wersje 30dniowe do pobrania z sieci — słowem: standardowa prezentacja z gatunku "kupiliśmy pięć mniejszych firm i teraz mamy komplet niezbędny do zbawienia świata".. szkoda tylko, że po pierwsze miałem dzisiaj urlop(!), a po drugie rzecz odbywa się w stolicy, czyli współczynniki D-S-P wychodzą raczej kiepskie: 4-4-4
z cyklu: software development w praktyce |
15.05.2003 : ...ale najbardziej nieprzyjemne jest istnienie klienta
mówiłem to z tysiąc razy i powiem jeszcze raz — kontakty z klientem to najbardziej bolesne momenty w tej robocie..
w teorii osobiście tego nie robię — w zgodzie z ISO i ku wielkiej radości wszystkich stron.. jednak w małym zespole nie da się uniknąć sytuacji, kiedy inteligentne inaczej wypowiedzi klienta przeciekają przez sito analizy prosto w twarz projektanta.. analityk zadzwoni, napisze, przetrawi i wyjaśni — oczywiście, tylko czemu ja dostaję surowym tekstem po oczach? komu tak bardzo zależy na tym, żebym był uświadamiany o ponadprzeciętnych zdolnościach klienta do mieszania faktów, naciągania definicji, tworzenia mętnych specyfikacji, zmieniania zdania i wysławiania się w sposób totalnie niegramatyczny..? komu by to przeszkadzało jakbym sobie trwał w ułudzie, że otaczają mnie właściwi ludzie na właściwych stanowiskach, że strategiczne decyzje są podejmowane przez ludzi, którzy rozumieją co mówią..? ja bym sobie spokojnie żył w takim fałszywym przekonaniu, że IT jest branżą dla inteligentnych, że jest dobrze i teorie działają... no dlaczego nie mogę?!
w teorii osobiście tego nie robię — w zgodzie z ISO i ku wielkiej radości wszystkich stron.. jednak w małym zespole nie da się uniknąć sytuacji, kiedy inteligentne inaczej wypowiedzi klienta przeciekają przez sito analizy prosto w twarz projektanta.. analityk zadzwoni, napisze, przetrawi i wyjaśni — oczywiście, tylko czemu ja dostaję surowym tekstem po oczach? komu tak bardzo zależy na tym, żebym był uświadamiany o ponadprzeciętnych zdolnościach klienta do mieszania faktów, naciągania definicji, tworzenia mętnych specyfikacji, zmieniania zdania i wysławiania się w sposób totalnie niegramatyczny..? komu by to przeszkadzało jakbym sobie trwał w ułudzie, że otaczają mnie właściwi ludzie na właściwych stanowiskach, że strategiczne decyzje są podejmowane przez ludzi, którzy rozumieją co mówią..? ja bym sobie spokojnie żył w takim fałszywym przekonaniu, że IT jest branżą dla inteligentnych, że jest dobrze i teorie działają... no dlaczego nie mogę?!
z cyklu: software development w praktyce |
24.04.2003
gdzie leży granica skomplikowania projektu, powyżej której obsuwa jednego zadania powoduje katastrofę we wszystkich następnych? kiedy jest ten moment, kiedy pierwotnie dobry i sprawny harmonogram przekształca się w monstrum, w którym wszystkie zadania leżą na ścieżce krytycznej? ot, pytania z gatunku "the greatest mysteries of IT".. :-/
stanie przy konsoli serwerów przez 8 godzin w hałasie przekraczającym akceptowalny przeze mnie poziom o [kliknij tu i wpisz dowolną dużą liczbę] decybeli, to zdecydowanie za dużo jak dla mnie.. kawa o 8:00 i szansa na następny posiłek około 21:00 już mi nie wystarcza jak kiedyś.. nie taki chciałem mieć zawód, nie takie zadania — instalację, konfigurację i postawienie całego bałaganu najchętniej zostawiłbym innym.. nudne to i męczące..
o godzinie 21:05 siedzę w McDonald's Polska Warszawa, Rest: Wolica i przeżuwam cheesburgera grubości podeszwy moich butów.. do domu mam jeszcze jakieś 300 km.. a z plakatu na oknie mruga do mnie idiotyczne hasło
stanie przy konsoli serwerów przez 8 godzin w hałasie przekraczającym akceptowalny przeze mnie poziom o [kliknij tu i wpisz dowolną dużą liczbę] decybeli, to zdecydowanie za dużo jak dla mnie.. kawa o 8:00 i szansa na następny posiłek około 21:00 już mi nie wystarcza jak kiedyś.. nie taki chciałem mieć zawód, nie takie zadania — instalację, konfigurację i postawienie całego bałaganu najchętniej zostawiłbym innym.. nudne to i męczące..
o godzinie 21:05 siedzę w McDonald's Polska Warszawa, Rest: Wolica i przeżuwam cheesburgera grubości podeszwy moich butów.. do domu mam jeszcze jakieś 300 km.. a z plakatu na oknie mruga do mnie idiotyczne hasło
Każdy dzień to Twój dzień!
z cyklu: software development w praktyce |
04.04.2003
taka sobie pierwsza z brzegu sytuacja z pewnego systemu informatycznego: w pewnej encji (np.
bo widzisz, rozumiesz,
akurat tym systemem zajmuję się (z różną intensywnością) od lat — wiem, że tak jest i z grubsza pamiętam różne uwarunkowania historyczne, które doprowadziły do takiego stanu.. jednak nie zmienia to faktu, że wewnętrznie wszystko mi się przewraca jak o tym pomyślę.. to oczywiście nie jest jakiś przypadek szczególny ani w tym systemie, ani w innych, jakie miałem okazję widzieć.. nawet zaryzykuję stwierdzenie, że takie kuriozalne fragmenty występują we wszystkich systemach informatycznych, jakie istnieją aktualnie na świecie.. i niezależnie od tego, co mówią spece od inżynierii oprogramowania, prawdziwa wiedza o systemach opiera się nie na wymyślnych technikach projektowania, tylko na pamięci ludzi, którzy wiedzą, że
w projekcie kolejnej z niezliczonych modyfikacji systemu postuluję zrobić z tym porządek — wartościami dozwolonymi będą teraz
PRODUKT) występuje pewien atrybut (np. KOD_PRODUKTU) — dwa znaki, aktualnie dwie możliwe wartości, kiedyś trzy.. wartości dozwolone tego atrybutu to oczywiście nie jakieś 01, 02 czy choćby cokolwiek zbliżonego do sensownej sekwencji, tylko ... 00 oraz 72.bo widzisz, rozumiesz,
72 jako przeciwieństwo zera... :-/akurat tym systemem zajmuję się (z różną intensywnością) od lat — wiem, że tak jest i z grubsza pamiętam różne uwarunkowania historyczne, które doprowadziły do takiego stanu.. jednak nie zmienia to faktu, że wewnętrznie wszystko mi się przewraca jak o tym pomyślę.. to oczywiście nie jest jakiś przypadek szczególny ani w tym systemie, ani w innych, jakie miałem okazję widzieć.. nawet zaryzykuję stwierdzenie, że takie kuriozalne fragmenty występują we wszystkich systemach informatycznych, jakie istnieją aktualnie na świecie.. i niezależnie od tego, co mówią spece od inżynierii oprogramowania, prawdziwa wiedza o systemach opiera się nie na wymyślnych technikach projektowania, tylko na pamięci ludzi, którzy wiedzą, że
72 i znają tych, którzy prawdopodobnie pamiętają dlaczego..w projekcie kolejnej z niezliczonych modyfikacji systemu postuluję zrobić z tym porządek — wartościami dozwolonymi będą teraz
01 i 02.. i oczywiście 71 z cyklu: software development w praktyce |
22.02.2003
czytając książki ludzi pokroju Yourdona można odnieść wrażenie, że project management to jakaś tajemnicza i brutalna magia.. przychodzi taki magik i mówi "uratuję wasze dupy, ale mam warunki takie a takie".. i najważniejsze założenie — poprzedni kierownik projektu już w tym momencie nie pracuje.. to podstawa całej filozofii — kierownictwo projektu zmienia się jak słabe baterie — nie pociągnie to wypad, następny..
jednak w rzeczywistości wcale tak nie jest.. przynajmniej nie u nas (być może jesteśmy jeszcze zbyt daleko od cywilizacji..?).. trzeba mieć naprawdę poważny powód, żeby wywalić szefa projektu.. przecież jak się go wywali to trzeba będzie znaleźć następnego — a niby skąd? chętnych mało, zwłaszcza, kiedy wszyscy w okolicy zdążyli poznać całą gamę postaw - od "wy sobie beze mnie poradzicie, ale ja bez was nie istnieję.." aż po "wiem jakie popełniłem błędy, ale chciałbym żebyście sobie przypomnieli wasze.. i raczej nie liczcie na premię w tym miesiącu.."
tak naprawdę opiera się to głównie na groźbie i zastraszeniu.. to nie jest szczególnie skomplikowane ponieważ łatwo jest zastraszyć każdego, kto nie wygrał w totka..
być może idealiści będą rozczarowani, ale faktem jest, że project management to polityka.. zdolny kierownik to prawie tyle co sprytny polityk (no oczywiście wykształcenia i inteligencji musi mieć znacznie więcej, ale o to akurat nie trudno).. cała ta zabawa to niewiele więcej jak nieustanna wojna psychologiczna..
jednak w rzeczywistości wcale tak nie jest.. przynajmniej nie u nas (być może jesteśmy jeszcze zbyt daleko od cywilizacji..?).. trzeba mieć naprawdę poważny powód, żeby wywalić szefa projektu.. przecież jak się go wywali to trzeba będzie znaleźć następnego — a niby skąd? chętnych mało, zwłaszcza, kiedy wszyscy w okolicy zdążyli poznać całą gamę postaw - od "wy sobie beze mnie poradzicie, ale ja bez was nie istnieję.." aż po "wiem jakie popełniłem błędy, ale chciałbym żebyście sobie przypomnieli wasze.. i raczej nie liczcie na premię w tym miesiącu.."
tak naprawdę opiera się to głównie na groźbie i zastraszeniu.. to nie jest szczególnie skomplikowane ponieważ łatwo jest zastraszyć każdego, kto nie wygrał w totka..
być może idealiści będą rozczarowani, ale faktem jest, że project management to polityka.. zdolny kierownik to prawie tyle co sprytny polityk (no oczywiście wykształcenia i inteligencji musi mieć znacznie więcej, ale o to akurat nie trudno).. cała ta zabawa to niewiele więcej jak nieustanna wojna psychologiczna..
- Znam się na tym - to jest wtedy, kiedy przez całą noc przed bitwą walisz w tarczę, żeby wrogowie nie mogli się wyspać, śpiewasz "Jutro obetniemy wam jaja!" i takie tam.[Terry Pratchett : Ciekawe Czasy]
z cyklu: software development w praktyce |
05.02.2003
a ten co tu robi? czy on jest w tym projekcie? nie, chyba nie jest.. na pewno nie..
- cześć..
nie dać po sobie nic poznać, nie okazać zdziwienia — pełna kontrola i profesjonalizm.. choć skołowany umysł i tak już zaczyna swoje..
nikt na głos nie pytał..
- cześć..
nie dać po sobie nic poznać, nie okazać zdziwienia — pełna kontrola i profesjonalizm.. choć skołowany umysł i tak już zaczyna swoje..
raz, dwa, tri... malczikijest szef, nawet szef szefa, jest analityk, jestem ja.. jest kierownik projektu z drugiej strony wraz z przybocznym.. generalnie jest ten, kto być powinien.. oprócz niego.. przecież jego nie ma na mapie kompetencji projektu..
...i wartości swej, w pełni świadomy, świadomy że hej...wydaje się mniej potrzebny niż pani donosząca kawę, a jednak.. jest, siedzi, nawet odezwał się ze dwa razy.. w jakiej występuje roli? szpieg, obserwator, Wysłannik Samego Wodza? przecież oni nie mają nic do roboty w tym projekcie.. chociaż chcieliby, oczywiście..
...moi koledzy ścigają ze mną się...nawet mnie mogłoby nie być na tym etapie, ale jestem, bo i tak siedzę od trzech dni w stolicy, ale on..?! przyjechał tutaj z wybrzeża tego samego ranka, pewnie z pięć godzin drogi, specjalnie na te kilka godzin, specjalnie na spotkanie, na którym oficjalnie nie ma nic do roboty..
...bo do wyścigu każden gotów jest...po prostu przyjechał, posiedział, posłuchał, zanotował i wrócił do siebie..
nikt na głos nie pytał..
z cyklu: software development w praktyce |
17.12.2002
to, co jest dobre w muzyce streetpunkowej
banał? jasne.. oczywiście.. każdy wie..
i ignoruje.. dlatego trzy czwarte software'u, któremu powierzasz swoje sprawy, dokumenty, pieniądze, życie, .... to nic nie warty śmietnik..
tak, współczesna cywilizacja jest przerażająca, kiedy się wie kto i w jaki sposób ją tworzy..
To chuj, że gramy jak dwadzieścia lat temuzupełnie nie sprawdza się w programowaniu.. software musi być (na)pisany współcześnie, zgodnie z zasadami, sprawdzonymi schematami, równo i prosto — inaczej nigdy nie będzie napisany dobrze.. a jak nie będzie dobrze napisany to nie będzie dobrze działał, będzie powolny, toporny i niekonserwowalny..
To chuj, że nierówno wchodzimy w refreny...
banał? jasne.. oczywiście.. każdy wie..
i ignoruje.. dlatego trzy czwarte software'u, któremu powierzasz swoje sprawy, dokumenty, pieniądze, życie, .... to nic nie warty śmietnik..
tak, współczesna cywilizacja jest przerażająca, kiedy się wie kto i w jaki sposób ją tworzy..
z cyklu: software development w praktyce |
16.12.2002
nie ma najmniejszego powodu, żeby branżą IT była pozbawiona sztucznych sytuacji kreowanych przez dupków z przerostem ambicji i różnych innych polityków.. dlatego nie dziwi, że także tutaj toczą się różne rozgrywki polityczne — gówna typu: kto będzie prowadził nowy projekt, który zespół będzie to realizował, kto skończy projekty aktualne itp... jak wiadomo granie na zwłokę jest jedną z ich ulubionych technik, więc...
szkolenie jest przesunięte, bo podobno wykładowca miał wypadek.
chyba, że mnie znowu okłamali..
z cyklu: software development w praktyce |
08.12.2002
szkolenie — proceder, w którym jedna firma specjalizuje się w wydawaniu papierków, dzięki którym inna firma zwiększa swoje szanse w różnorakich przetargach, podnosi "wartość zespołu", realizuje budżet lub przynajmniej owe papierki kolekcjonuje.. raczej rzadko chodzi o nauczenie kogokolwiek czegokolwiek — częściej o zwiększenie ilości asów w talii, zwłaszcza w sytuacji, gdy w każdym niemal projekcie wymagany jest zawodnik z papierem.. osobisty zysk człowieka wplątanego w te polityczne rozgrywki to najwyżej zdanie w CV..
w każdym razie ja, jak to już dawniej bywało, grudzień spędzam na naukach w stolicy.. wracam za kilka dni (przynajmniej na chwilę)..
w każdym razie ja, jak to już dawniej bywało, grudzień spędzam na naukach w stolicy.. wracam za kilka dni (przynajmniej na chwilę)..
z cyklu: software development w praktyce |
25.11.2002
[Architektury, komponenty i uparty Polak - wywiad z Wojtkiem Kozaczyńskim : Computerworld 40-2002]:
wbrew wyobrażeniom ludzi na wysokich stołkach "gracze indywidualni" widzą co wyprawiają menedżerowie — dobra zabawa i satysfakcja nie przesłaniają zdrowego rozsądku.. jeżeli wspomniana sprzeczność interesów jest podsycana rażącym brakiem profesjonalizmu, nieporadnością, a niejednokrotnie pospolitą głupotą szefów, to nabiera odcienia trudnego do zniesienia.. naprawdę trudnego do zniesienia..
i stąd takie dialogi dnia powszedniego:
ja — powinniśmy się z nimi zamienić miejscami
Ania — ale oni sobie tutaj nie poradzą..
ja — to wtedy się ich zwolni..
Ania — no fakt..
Budowa systemów to gra zarówno zespołowa i indywidualna. Im bardziej skomplikowany i im większy system, tym bardziej skomplikowana gra. Ci od gry indywidualnej i ci od zespołowej grają z innych pobudek. Pierwsi, indywidualni programiści i projektanci, po prostu dobrze się bawią i samo robienie ciekawego software'u daje im satysfakcję. Ci drudzy, nazwijmy ich menedżerami, grają w tę grę dla pieniędzy - oni chcą robić biznes - i próbują wstawić tych indywidualnych graczy w ustalone szablony, spoza których nie idzie się wychylić. Tę sprzeczność interesów często widać na dużych projektach biznesowych.prawda niezaprzeczalna.. i w dodatku, jak wszystko w tym chamskim sporcie, ma jeszcze drugie dno i niekoniecznie jasne konsekwencje..
wbrew wyobrażeniom ludzi na wysokich stołkach "gracze indywidualni" widzą co wyprawiają menedżerowie — dobra zabawa i satysfakcja nie przesłaniają zdrowego rozsądku.. jeżeli wspomniana sprzeczność interesów jest podsycana rażącym brakiem profesjonalizmu, nieporadnością, a niejednokrotnie pospolitą głupotą szefów, to nabiera odcienia trudnego do zniesienia.. naprawdę trudnego do zniesienia..
i stąd takie dialogi dnia powszedniego:
ja — powinniśmy się z nimi zamienić miejscami
Ania — ale oni sobie tutaj nie poradzą..
ja — to wtedy się ich zwolni..
Ania — no fakt..
z cyklu: software development w praktyce |
14.11.2002
uzgodnione, podpisane, sprzedane.. co prawda system nie działa jak powinien, nie spełnia wymogów i generalnie w obecnym stanie nie nadaje się do wdrożenia — każdy zdrowo myślący biały człowiek™ uzna to za oczywiste.. jednak politycy podjęli decyzję, więc oficjalnie jest ok.. a cała brakująca funkcjonalność? powstanie w okresie gwarancyjnym, jeżeli w ogóle..
dokładnie tak było w poprzednim projekcie — sprawa zamknięta i jakimś cudem jeszcze trzy lata pracy.. skąd? jak? dlaczego? przecież system był gotowy i sprzedany..
ot, informatyczne cuda...
dokładnie tak było w poprzednim projekcie — sprawa zamknięta i jakimś cudem jeszcze trzy lata pracy.. skąd? jak? dlaczego? przecież system był gotowy i sprzedany..
ot, informatyczne cuda...
z cyklu: software development w praktyce |
30.10.2002
wróciłem wcześniej.. w sumie niby z tarczą, chociaż...
porządek panujący w UM można określić jedynie obrazowym słowem burdello.. norma ISO 9001 wdrożona, a jakże, jednak nikt nie wie gdzie są jakie komputery, gdzie jaki soft, a ustalenie gdzie ma być wdrożony nowy system robione jest na bieżąco.. nieznany człowiek może bez obstawy i zaanonsowania wejść wszędzie, zasiąść przed dowolnym komputerem i zrobić co tylko chce.. i tylko jedna (słownie: "jedna") pani spytała "a kim panowie w ogóle są? jakieś legitymacje może?".. wykreśliliśmy ją z grafika ;-)
z wielu innych ciekawostek w UM jeszcze jedna jest godna odnotowania — dostęp do internetu zablokowany na połowie stanowisk.. nie zgodnie z potrzebami stanowiska, wydziału lub zakresem obowiązków pracownika tylko tak sobie, dla kaprysu — co drugie mniej więcej.. panie płaczą "kiedyś miałam, teraz nie mam", a my... no cóż, skoro żaden lokalny informatyk nie interesuje się specjalnie tym co robię, a ładna dziewczyna ładnie prosi, to ulegam.. zwłaszcza kiedy sprawa polega jedynie na przywróceniu ustawień proxy.. ot, kawałek technicznej magii dla rozjaśnienia czyjegoś życia, choć na moment ;-)
porządek panujący w UM można określić jedynie obrazowym słowem burdello.. norma ISO 9001 wdrożona, a jakże, jednak nikt nie wie gdzie są jakie komputery, gdzie jaki soft, a ustalenie gdzie ma być wdrożony nowy system robione jest na bieżąco.. nieznany człowiek może bez obstawy i zaanonsowania wejść wszędzie, zasiąść przed dowolnym komputerem i zrobić co tylko chce.. i tylko jedna (słownie: "jedna") pani spytała "a kim panowie w ogóle są? jakieś legitymacje może?".. wykreśliliśmy ją z grafika ;-)
z wielu innych ciekawostek w UM jeszcze jedna jest godna odnotowania — dostęp do internetu zablokowany na połowie stanowisk.. nie zgodnie z potrzebami stanowiska, wydziału lub zakresem obowiązków pracownika tylko tak sobie, dla kaprysu — co drugie mniej więcej.. panie płaczą "kiedyś miałam, teraz nie mam", a my... no cóż, skoro żaden lokalny informatyk nie interesuje się specjalnie tym co robię, a ładna dziewczyna ładnie prosi, to ulegam.. zwłaszcza kiedy sprawa polega jedynie na przywróceniu ustawień proxy.. ot, kawałek technicznej magii dla rozjaśnienia czyjegoś życia, choć na moment ;-)
z cyklu: software development w praktyce |
08.10.2002
wspominana godzina zero przyszła i minęła.. co prawda system w dalszym ciągu nie wygląda nawet w przybliżeniu tak jak powinien, ale nic to — gramy dalej..
kiedyś, jak byłem całkiem mały, sądziłem, że sukces tak rozbudowanego przedsięwzięcia jak stworzenie i wdrożenie systemu informatycznego pokrywającego całość (lub prawie-całość) biznesu klienta to skutek dogrania wielu subtelnych czynników — niezawodny sprzęt na czas, odpowiedni soft na czas, całość sprawdzona, przetestowana, zaakceptowana, ludzie przeszkoleni.. wszystko zgodnie z założeniami i życzeniami klienta, tak jak stoi w dokumentach z analizy..
dzisiaj już widziałem swoje.. odarty z dziecięcych wyobrażeń i książkowych teorii, porzuciwszy wszystko czego mnie usiłowali nauczyć na kursach różnorakich, dziś już wiem... nie musi istnieć dogłębna analiza rzeczywistości, którą budowany system ma wspomagać.. nie musi istnieć projekt techniczny tłumaczący wynik analizy na język zrozumiały dla programistów.. żaden programista nie musi znać szerszego kontekstu fragmentu, który ma oprogramować.. scenariusze testowe nie muszą być stworzone tak by zapewnić poprawność i stabilność systemu.. w ogóle system nie musi istnieć by był oddany.. bowiem tak na prawdę liczy się wyłącznie polityka.. wyłącznie.. termin mija, ale my gramy dalej..
powoli przestaje mnie dziwić ten totalnie pokręcony świat 'profesjonalistów'.. teoria przegrywa nierówną walkę z praktyką — boleśnie umierają kolejne 'musi' i 'nie da się'.. jednak z dnia na dzień buntu coraz mniej.. ciekawe jak na ten świat spojrzę jutro, kiedy będę już duży..?
kiedyś, jak byłem całkiem mały, sądziłem, że sukces tak rozbudowanego przedsięwzięcia jak stworzenie i wdrożenie systemu informatycznego pokrywającego całość (lub prawie-całość) biznesu klienta to skutek dogrania wielu subtelnych czynników — niezawodny sprzęt na czas, odpowiedni soft na czas, całość sprawdzona, przetestowana, zaakceptowana, ludzie przeszkoleni.. wszystko zgodnie z założeniami i życzeniami klienta, tak jak stoi w dokumentach z analizy..
dzisiaj już widziałem swoje.. odarty z dziecięcych wyobrażeń i książkowych teorii, porzuciwszy wszystko czego mnie usiłowali nauczyć na kursach różnorakich, dziś już wiem... nie musi istnieć dogłębna analiza rzeczywistości, którą budowany system ma wspomagać.. nie musi istnieć projekt techniczny tłumaczący wynik analizy na język zrozumiały dla programistów.. żaden programista nie musi znać szerszego kontekstu fragmentu, który ma oprogramować.. scenariusze testowe nie muszą być stworzone tak by zapewnić poprawność i stabilność systemu.. w ogóle system nie musi istnieć by był oddany.. bowiem tak na prawdę liczy się wyłącznie polityka.. wyłącznie.. termin mija, ale my gramy dalej..
powoli przestaje mnie dziwić ten totalnie pokręcony świat 'profesjonalistów'.. teoria przegrywa nierówną walkę z praktyką — boleśnie umierają kolejne 'musi' i 'nie da się'.. jednak z dnia na dzień buntu coraz mniej.. ciekawe jak na ten świat spojrzę jutro, kiedy będę już duży..?
z cyklu: software development w praktyce |
20.09.2002
— niech mi pan powie - dlaczego on to tak długo robi? takie trudne, czy nie umie, czy co?
każdy ma jakieś swoje tempo — wiadomo, jak we wszystkim.. a jeśliby potraktować programistę jako twórcę, artystę wręcz to w ogóle trudno oceniać tempo jakiekolwiek.. niestety dzisiaj już nikt programistów tak nie traktuje — dzisiaj to najczęściej robotnik, trybik w maszynie a nie twórca jakikolwiek, rzemieślnik co najwyżej.. zdecydowanie na czas — szybciej, szybciej..! a jednak mimo wszystko..
— nie wiem...
no bo jak można ocenić kolegę? pracuje ile uważa i robi tak jak potrafi.. zespół nigdy nie jest równy.. a poza tym wszyscy w głębi serca wyznajemy zasadę "będzie gotowe kiedy będzie gotowe, nie wcześniej"..
— ...widocznie natrafił na jakieś nieprzewidziane problemy.. ja nie analizowałem szczegółów..
każdy ma jakieś swoje tempo — wiadomo, jak we wszystkim.. a jeśliby potraktować programistę jako twórcę, artystę wręcz to w ogóle trudno oceniać tempo jakiekolwiek.. niestety dzisiaj już nikt programistów tak nie traktuje — dzisiaj to najczęściej robotnik, trybik w maszynie a nie twórca jakikolwiek, rzemieślnik co najwyżej.. zdecydowanie na czas — szybciej, szybciej..! a jednak mimo wszystko..
— nie wiem...
no bo jak można ocenić kolegę? pracuje ile uważa i robi tak jak potrafi.. zespół nigdy nie jest równy.. a poza tym wszyscy w głębi serca wyznajemy zasadę "będzie gotowe kiedy będzie gotowe, nie wcześniej"..
— ...widocznie natrafił na jakieś nieprzewidziane problemy.. ja nie analizowałem szczegółów..
z cyklu: software development w praktyce |
06.09.2002
czasem jest taki moment, że nie ma sensu ciągnąć sprawy dalej.. że jest tak wszystko niedobrze, że dobrze już nie będzie.. że trzeba by wyciąć większość organów, szkielet w kilku miejscach podeprzeć i wszystkie bebechy zacząć odbudowywać od zera.. od koncepcji niemalże..
wtedy trzeba miłosiernie dokonać eutanazji projektu..
ale jak to zwykle z eutanazjami bywa, mało kto się odważa..
wtedy trzeba miłosiernie dokonać eutanazji projektu..
ale jak to zwykle z eutanazjami bywa, mało kto się odważa..
z cyklu: software development w praktyce |
04.08.2002
jednak z drugiej strony, kiedy już poznasz wszystkie dziwne nazwy i akronimy, kiedy chwycisz jakąś myśl przewodnią i zaczynasz zauważać, że to jednak ma jakiś cel a może sens nawet, można ulec wrażeniu, że właściwie wszystko jest proste..
a to znaczy, że najwyższy czas na nową wersję lub przynajmniej udziwnienie specyfikacji.. bowiem rację miał również Gregory Benford:
a to znaczy, że najwyższy czas na nową wersję lub przynajmniej udziwnienie specyfikacji.. bowiem rację miał również Gregory Benford:
Każda technologia odróżnialna od magii jest niedostatecznie zaawansowana.
z cyklu: software development w praktyce |
03.08.2002
jakiś tydzień temu zabrałem się za wymyślanie czegoś, co by pasowało do czegoś innego, czego nie znam i realizowało zadania, których nie potrafiłem sprecyzować dokładniej niż na poziomie ulotki reklamowej.. mówiąc bardziej obrazowo - zostałem zrzucony na środek oceanu ze świadomością, że abym przeżył ja sam i to wszystko, co tu zaraz spadnie moim śladem, potrzebuję mieć statek.. duży i natychmiast..
wiem, że takie rzeczy się robi, że z grubsza na tym polega mój zawód, wiem nawet co powinienem wykorzystać i mniej więcej wiem dlaczego, ale... ale wiem również, jak dużo racji miał Arthur C. Clarke mówiąc:
wiem, że takie rzeczy się robi, że z grubsza na tym polega mój zawód, wiem nawet co powinienem wykorzystać i mniej więcej wiem dlaczego, ale... ale wiem również, jak dużo racji miał Arthur C. Clarke mówiąc:
Każda dostatecznie zaawansowana technologia jest nieodróżnialna od magii.a na magii to ja się mało znam.. jeszcze..
z cyklu: software development w praktyce |
31.07.2002
Masz komfort pracy wydzielonej, która nie leży na ścieżce krytycznej projektu. Wyżywaj się. Jeżeli dobrze zaprojektujesz i opiszesz moduł, masz szanse nie wykonywać go osobiście.widzisz tu groźbę? widzisz ten cień? masz szansę zaledwie...
zrobić projekt dla innych jest łatwo — kilka 'prawie dobrych' pomysłów a resztę doszlifują programiści.. pisać wg cudzego projektu też jest łatwo — w systemie same protezy, ledwo to wszystko działa ale to nie moja wina bo przecież projekt był do dupy.. ale napisać program wg własnego projektu, to już zupełnie inna sprawa — nie masz na kogo przerzucić odpowiedzialności i sam jesteś winien klęski.. wyłącznie i osobiście..
kiedyś, jak byłem młody i naiwny, wydawało mi się, że raczej odwrotnie....
z cyklu: software development w praktyce |
17.07.2002
nie odzywam się, mówisz...
trudno zaprzeczyć.. ale wspaniałe życie, (co do którego, nawiasem mówiąc nadal nie mam przekonania) poczęstowało mnie pewną ciekawą sytuacją skutecznie zmniejszającą wszelką aktywność zewnętrzną, sieciową zwłaszcza..
w zatwierdzonym planie urlopów przy moim nazwisku w dniach od 15.07 do 26.07 widnieją równe i całkiem zdecydowane krzyżyki.. a tymczasem zamiast siedzieć za sterem "lekko przeżaglowanej samoróbki, niegdyś sportiny" tak jak to miałem w planach, siedzę w niemiłosiernie gorącym pokoju — niby tym samym co zawsze, tylko powietrze gęściejsze jakieś.. natomiast na ekranie oprócz*) starych narzędzi pojawiają się nowe zabawki z przyległościami i dziwnymi technologiami w tle..
w ramach terminologii zrozumiałej przez wszelkich twórców wszelkiego oprogramowania w całym multiwersum sytuacja taka nazywa się "bagno po same uszy" (lub odpowiednio dosadniej w zależności od lokalnego kolorytu)..
wrócę jak tylko się rozdwoję...
*) naiwny kto sądzi, że udział w nowym projekcie oznacza porzucenie poprzedniego...
trudno zaprzeczyć.. ale wspaniałe życie, (co do którego, nawiasem mówiąc nadal nie mam przekonania) poczęstowało mnie pewną ciekawą sytuacją skutecznie zmniejszającą wszelką aktywność zewnętrzną, sieciową zwłaszcza..
w zatwierdzonym planie urlopów przy moim nazwisku w dniach od 15.07 do 26.07 widnieją równe i całkiem zdecydowane krzyżyki.. a tymczasem zamiast siedzieć za sterem "lekko przeżaglowanej samoróbki, niegdyś sportiny" tak jak to miałem w planach, siedzę w niemiłosiernie gorącym pokoju — niby tym samym co zawsze, tylko powietrze gęściejsze jakieś.. natomiast na ekranie oprócz*) starych narzędzi pojawiają się nowe zabawki z przyległościami i dziwnymi technologiami w tle..
w ramach terminologii zrozumiałej przez wszelkich twórców wszelkiego oprogramowania w całym multiwersum sytuacja taka nazywa się "bagno po same uszy" (lub odpowiednio dosadniej w zależności od lokalnego kolorytu)..
wrócę jak tylko się rozdwoję...
z cyklu: software development w praktyce |
09.07.2002
z projektami informatycznymi jest trochę tak jak ze starym statkiem — jeśli ci co wiosłują nie dają sobie rady to dodaje się kilku nowych i/lub karze wiosłować szybciej, więcej, dłużej i bez przerw.. z czasem wioślarzy jest tylu, że mimo zakazu przybierania na wadze, zaczynają przekraczać wyporność statku.. no więc połowę wywala się za burtę a pozostałym zakazuje zwalniać pod groźbą utraty pierwszorzędnych cech płciowych..
a tym czasem zapomniany i podarty żagiel powiewa na nimi melancholijnie..
a tym czasem zapomniany i podarty żagiel powiewa na nimi melancholijnie..
z cyklu: software development w praktyce |
01.07.2002
tak się czasem zastanawiam w przypływie nastroju filozoficznego, czy istnieje jakaś inna dziedzina naukowo-techniczno-przemysłowej działalności człowieka, w której występowałby tak jawny dysonans między teorią a praktyką jaki występuje w inżynierii oprogramowania?
większość specjalistów od nowych metod czy innych pomysłów z kategorii silver bullet solution, którzy tak chętnie wymądrzają się w mniej lub bardziej popularnych publikacjach zgodnie twierdzi, że:
jasne, piękne i oczywiste.. w teorii.. a w praktyce koledzy zastanawiają się czy mają na tyle odwagi żeby poprosić szefa o wolną niedzielę..
większość specjalistów od nowych metod czy innych pomysłów z kategorii silver bullet solution, którzy tak chętnie wymądrzają się w mniej lub bardziej popularnych publikacjach zgodnie twierdzi, że:
people constitute the most important control parameter in every disciplinei stąd — pomijając już wszelkie metody, techniki i procesy — wykwalifikowany, doświadczony i odpowiednio motywowany zespół jest podstawą do myślenia o jakimkolwiek sukcesie..
jasne, piękne i oczywiste.. w teorii.. a w praktyce koledzy zastanawiają się czy mają na tyle odwagi żeby poprosić szefa o wolną niedzielę..
z cyklu: software development w praktyce |
14.06.2002
łatwo jest mówić teoretycznie zwłaszcza o sprawach związanych z indywidualnym poczuciem tego co właściwe, prawdziwe, szczere w rozmowach o tym jak jest..
w praktyce jednak rozbieżność faktów i raportów bywa ogromna.. wiesz co robisz, wiesz ile jeszcze przed Tobą, wiesz jak u innych i wszyscy macie świadomość, że bez kilku miesięcy dodatkowego czasu nic nie da się zrobić.. ale cóż z tego jeśli wyżej przepływają raporty o 90% kompletności.. przecież napisane, że zgodnie z harmonogramem, wszystko na czas — na papierze się zgadza, wiec who cares..?
i pewnego dnia przychodzi ten moment oznaczony w harmonogramie jako prezentacja wersji prototypowej albo jeszcze jakoś gorzej.. i cóż.... z gównem pojechaliśmy to z gównem nas zmieszali mówią chłopcy po powrocie..
rzecz prosta do przewidzenia a jednak zdumiewająco częsta.. tak to już jest — IT to brutalny biznes kłamców :-/
w praktyce jednak rozbieżność faktów i raportów bywa ogromna.. wiesz co robisz, wiesz ile jeszcze przed Tobą, wiesz jak u innych i wszyscy macie świadomość, że bez kilku miesięcy dodatkowego czasu nic nie da się zrobić.. ale cóż z tego jeśli wyżej przepływają raporty o 90% kompletności.. przecież napisane, że zgodnie z harmonogramem, wszystko na czas — na papierze się zgadza, wiec who cares..?
i pewnego dnia przychodzi ten moment oznaczony w harmonogramie jako prezentacja wersji prototypowej albo jeszcze jakoś gorzej.. i cóż.... z gównem pojechaliśmy to z gównem nas zmieszali mówią chłopcy po powrocie..
rzecz prosta do przewidzenia a jednak zdumiewająco częsta.. tak to już jest — IT to brutalny biznes kłamców :-/
z cyklu: software development w praktyce |
07.06.2002
jeśli uważasz, że można nie posiadać certyfikatu ISO9001 a mimo to uchodzić za poważną i nowoczesną firmę dbającą o potrzeby klienta to nie znasz siły magicznego słowa certyfikat i pewnie również nie rozumiesz pojęcia marketing..
jeżeli uważasz, że posiadanie wspomnianego certyfikatu, regularne kontrole auditorów i zewnętrzne wrażenie wysokiej kultury zarządzania oznaczają, że firma autentycznie przestrzega ścisłej polityki jakości to nie odróżniasz teorii od praktyki..
jeśli wierzysz, że wspaniałe teorie wymyślane przez mądrych ludzi służą temu aby wszystkim było lepiej, więcej, szybciej, taniej i dostatniej to jesteś frajerem, który nigdy nie dojdzie tam, gdzie są prawdziwe pieniądze..
zupełnie jak ja... :-/
jeżeli uważasz, że posiadanie wspomnianego certyfikatu, regularne kontrole auditorów i zewnętrzne wrażenie wysokiej kultury zarządzania oznaczają, że firma autentycznie przestrzega ścisłej polityki jakości to nie odróżniasz teorii od praktyki..
jeśli wierzysz, że wspaniałe teorie wymyślane przez mądrych ludzi służą temu aby wszystkim było lepiej, więcej, szybciej, taniej i dostatniej to jesteś frajerem, który nigdy nie dojdzie tam, gdzie są prawdziwe pieniądze..
zupełnie jak ja... :-/
z cyklu: software development w praktyce |
05.06.2002
jakieś 330 kilometrów stąd usiłuję się dowiedzieć jakie Szanowny Klient ma przemyślenia na temat nowej funkcjonalności systemu.. wychodzi na to, że szczególnych przemyśleń nie ma i zgadzają się z naszą koncepcją...
— ale z którą? bo przedstawiliśmy Państwu dwa warianty rozwiązania..
— jak to dwa? tam były dwa?? gdzie.... ale ja naprawdę to czytałem...
kilka mało ważnych zdań więcej i można wracać do domu..
w sumie 12 godzin i 655 kilometrów w prażącym słońcu.. ot, taki prezent od życia z okazji moich urodzin..
— ale z którą? bo przedstawiliśmy Państwu dwa warianty rozwiązania..
— jak to dwa? tam były dwa?? gdzie.... ale ja naprawdę to czytałem...
kilka mało ważnych zdań więcej i można wracać do domu..
w sumie 12 godzin i 655 kilometrów w prażącym słońcu.. ot, taki prezent od życia z okazji moich urodzin..
z cyklu: software development w praktyce |
24.05.2002
mam wrażenie, że teoria/nauka/sztuka prowadzenia "co najmniej średnich" projektów informatycznych przegrywa do zera brutalną konfrontację z rzeczywistością..
można być (i chyba nawet jest to w modzie) dokładnie wyszkolonym, wyedukowanym a nawet przekonanym o tym, że da się osiągnąć sukces nawet w projekcie, który jawi się jako death march.. jednak co z tego, skoro jest się pazernym dupkiem, któremu zmutowane ego wyżarło resztki inteligencji..
jeśli będąc kierownikiem projektu, dyrektorem czy innym bossem nie oddasz pełni władzy w zakresie decyzji merytorycznych analitykowi i całkowitej władzy nad stroną techniczną projektantowi to daleko nie pojedziecie.. nawet jeśli potrafisz to wszystko pociągnąć sam, czyli jesteś jakimś lokalnym bogiem, to i tak zginiesz z powodu braku wyznawców..
niby banalne, prawda? a jednak...
można być (i chyba nawet jest to w modzie) dokładnie wyszkolonym, wyedukowanym a nawet przekonanym o tym, że da się osiągnąć sukces nawet w projekcie, który jawi się jako death march.. jednak co z tego, skoro jest się pazernym dupkiem, któremu zmutowane ego wyżarło resztki inteligencji..
jeśli będąc kierownikiem projektu, dyrektorem czy innym bossem nie oddasz pełni władzy w zakresie decyzji merytorycznych analitykowi i całkowitej władzy nad stroną techniczną projektantowi to daleko nie pojedziecie.. nawet jeśli potrafisz to wszystko pociągnąć sam, czyli jesteś jakimś lokalnym bogiem, to i tak zginiesz z powodu braku wyznawców..
niby banalne, prawda? a jednak...
z cyklu: software development w praktyce |
23.05.2002
auditorzy Jakości - niczym współcześni inkwizytorzy pod sztandarami ISO9001..
już oni sprawdzą czy Twoje myśli i czyny są zgodne z literą i duchem Księgi Jakości i czy jesteś godzien przebywać na łaskawym łonie matki Normy.. oczywiście wiedzą(naj)lepiej jaką czystość, skrupulatność i poziom biurokracji powinieneś zachowywać żeby Twój klient był szczęśliwy..
raczej nie szczędzą nagan i ostrzeżeń..
już oni sprawdzą czy Twoje myśli i czyny są zgodne z literą i duchem Księgi Jakości i czy jesteś godzien przebywać na łaskawym łonie matki Normy.. oczywiście wiedzą
raczej nie szczędzą nagan i ostrzeżeń..
z cyklu: software development w praktyce |
20.05.2002
programistą być znów przez chwilę...
pamiętasz ten typ utalentowanego młodzieńca? człowiek bystry choć generalnie dziwny a może i tajemniczy.. w głębi duszy (i tak między nami) raczej zarozumiały.. jakby wiedział coś o czym nie mają pojęcia inni.. jak jakiś specyficzny twórca albo magik czy inny za przeproszeniem artysta..
władca Innej Rzeczywistości?
raczej nie.. raczej nie dzisiaj i nie tutaj.. w Tej Rzeczywistości to najwyżej trybik w maszynie.. jeśli ma szczęście to w maszynie napędzanej normą ISO:9001.. jeśli nie - to jedynie dumą i ambicją wysokich stołków..
raport niezgodności, zadanie, specyfikacja, implementacja, test, scenariusz, spodziewane rezultaty, wynik, opinia, następne.. numer, data, numer, data, sygnatura, data, podpis, data.. fabryka.
programistą nie być nigdy więcej...
pamiętasz ten typ utalentowanego młodzieńca? człowiek bystry choć generalnie dziwny a może i tajemniczy.. w głębi duszy (i tak między nami) raczej zarozumiały.. jakby wiedział coś o czym nie mają pojęcia inni.. jak jakiś specyficzny twórca albo magik czy inny za przeproszeniem artysta..
władca Innej Rzeczywistości?
raczej nie.. raczej nie dzisiaj i nie tutaj.. w Tej Rzeczywistości to najwyżej trybik w maszynie.. jeśli ma szczęście to w maszynie napędzanej normą ISO:9001.. jeśli nie - to jedynie dumą i ambicją wysokich stołków..
raport niezgodności, zadanie, specyfikacja, implementacja, test, scenariusz, spodziewane rezultaty, wynik, opinia, następne.. numer, data, numer, data, sygnatura, data, podpis, data.. fabryka.
programistą nie być nigdy więcej...
z cyklu: software development w praktyce |
20.12.2001
jedna ze standardowych pseudo mądrości ludzkości głosi, że człowiek uczy się całe życie.. to dość oczywista bzdura, jeśli zauważyć, że większość ludzi nie uczy się nigdy i niczego.. być może ja również — czas pokaże..
w każdym razie notatki mam takie:
:: istotne zmiany przychodzą po cichu i nocą
:: rozsądku i wyobraźni jest zawsze za mało
:: przyczyną największych zagrożeń i najbardziej spektakularnych wpadek jest niemal zawsze głupota i zachłanność
:: nikt nie zrobi nic, jeśli nie zobaczy w tym osobistych korzyści — altruizm nie istnieje
:: duże IQ musi występować równocześnie z dużym EQ — najgorszy jest niezrównoważony psychicznie geniusz
:: dyskusja to wymiana poglądów a nie sejm — ostrożnie z krytycyzmem
:: 1+1=3 ale 1+1+1+...+1=-3
:: nie ma uczelni, która tego uczy
no i tyle..
w każdym razie notatki mam takie:
:: istotne zmiany przychodzą po cichu i nocą
:: rozsądku i wyobraźni jest zawsze za mało
:: przyczyną największych zagrożeń i najbardziej spektakularnych wpadek jest niemal zawsze głupota i zachłanność
:: nikt nie zrobi nic, jeśli nie zobaczy w tym osobistych korzyści — altruizm nie istnieje
:: duże IQ musi występować równocześnie z dużym EQ — najgorszy jest niezrównoważony psychicznie geniusz
:: dyskusja to wymiana poglądów a nie sejm — ostrożnie z krytycyzmem
:: 1+1=3 ale 1+1+1+...+1=-3
:: nie ma uczelni, która tego uczy
no i tyle..
z cyklu: software development w praktyce |
19.12.2001
gęstość atmosfery zdecydowanie powyżej wydajności klimatyzacji.. dużo ludzi, stoły poprzestawiane (dla wygody zapewne), stosy papierów, kubki i termosy z kawą, co metr leży komórka, notebook co dwa, plątanina kabli co trzy.. padło kilka dobrych pomysłów, kilka ciekawych historii i przeżyć a na sali siedzi raczej nadmiar specjalistów.. coś jakby piekło i niebo projektów informatycznych zostało urządzone w jednym miejscu..
jak się skupię na chwilę to mam niemiłe wrażenie, że jednak nie całkiem tutaj pasuję.. jednak nie jestem samoistnym geniuszem, nie nabierałem doświadczenia od kołyski i mam wrażenie, że pomyliłem się w życiu więcej niż jeden raz..
i jednak lubię świeże powietrze..
jak się skupię na chwilę to mam niemiłe wrażenie, że jednak nie całkiem tutaj pasuję.. jednak nie jestem samoistnym geniuszem, nie nabierałem doświadczenia od kołyski i mam wrażenie, że pomyliłem się w życiu więcej niż jeden raz..
i jednak lubię świeże powietrze..
z cyklu: software development w praktyce |
03.12.2001
istnieją z grubsza rzecz biorąc dwa typy programistów — typ samodzielnego artysty i dokładnego rzemieślnika..
artysta dostając zadanie znika mi z pola widzenia.. czasami coś zapyta, coś zechce wyjaśnić i ewentualnie wytknie braki w projekcie.. generalnie jednak nie pokazuje się dopóki nie skończy.. artysta bywa geniuszem — czasem ze szczątków projektu zrobi arcydzieło działające dokładnie tak jak trzeba — po prostu mówisz 'zrób to' i dostajesz gotowe i bezbłędne.. niestety nader często powstały program jest jedynie odbiciem prywatnego poglądu artysty na sprawę — wtedy trzeba dokładnie sprawdzić czy otrzymany program nie robi przypadkiem czegoś zupełnie odwrotnego..
rzemieślnik nie znika w ogóle.. najmniejszy problem, pytanie, niedopowiedzenie czy jakąkolwiek wątpliwość musi głośno wyartykułować i wyjaśnić.. z jednej strony to dobrze — wiadomo, że zostanie napisane dokładnie tak jak się ustali, że nic nie będzie wynikiem jego prywatnych przemyśleń.. jednak rzemieślnik potrafi zamęczyć projektanta na śmierć a analitykowi wytknie jeden przypadek na milion, którego nie umiemy poprawnie obsłużyć..
któremu z nich dać do napisania bardzo ważny moduł systemu?
artysta dostając zadanie znika mi z pola widzenia.. czasami coś zapyta, coś zechce wyjaśnić i ewentualnie wytknie braki w projekcie.. generalnie jednak nie pokazuje się dopóki nie skończy.. artysta bywa geniuszem — czasem ze szczątków projektu zrobi arcydzieło działające dokładnie tak jak trzeba — po prostu mówisz 'zrób to' i dostajesz gotowe i bezbłędne.. niestety nader często powstały program jest jedynie odbiciem prywatnego poglądu artysty na sprawę — wtedy trzeba dokładnie sprawdzić czy otrzymany program nie robi przypadkiem czegoś zupełnie odwrotnego..
rzemieślnik nie znika w ogóle.. najmniejszy problem, pytanie, niedopowiedzenie czy jakąkolwiek wątpliwość musi głośno wyartykułować i wyjaśnić.. z jednej strony to dobrze — wiadomo, że zostanie napisane dokładnie tak jak się ustali, że nic nie będzie wynikiem jego prywatnych przemyśleń.. jednak rzemieślnik potrafi zamęczyć projektanta na śmierć a analitykowi wytknie jeden przypadek na milion, którego nie umiemy poprawnie obsłużyć..
któremu z nich dać do napisania bardzo ważny moduł systemu?
z cyklu: software development w praktyce | 4 komentarze
01.12.2001
cytat do przemyślenia przez weekend:
Fizycy są głęboko przekonani, że istnieją unifikujące zasady - czy to w postaci teorii kwarków, czy jednolitej teorii pola. Einstein wielokrotnie dowodził, żę muszą być uproszczone wyjaśnienia natury, bo Bóg nie jest ani kapryśny, ani arbitralny.
Nie ma żadnej takiej wiary, która dodawałaby otuchy inżynierowi oprogramowania. Złożoność, którą musi opanować, jest w znacznym stopniu złożonością arbitralną, wymuszoną bez ładu i składu przez liczne instytucje i systemy, z którymi jego interfejsy muszą być zgodne. Te zaś różnią się między sobą nie z konieczności, a jedynie dlatego, że zostały stworzone przez rozmaitych ludzi, a nie przez Boga.[Frederick P. Brooks, Jr. : brakująca srebrna kula - zadania zasadnicze i uboczne w inżynierii oprogramowania]
z cyklu: software development w praktyce |
01.12.2001
należę chyba do tego gatunku absolutnie niewyrozumiałych skurwieli, którzy zawsze są niezadowoleni z siebie i przeważnie niezadowoleni z innych.. objawia się to opieprzaniem wszystkich za najmniejsze błędy lub choćby podejrzenie braku profesjonalizmu.. jest na to tylko jeden sposób — ..... nie, właściwie nie ma na to sposobu..
współczuję wszystkim w jakikolwiek sposób zawodowo ode mnie zależnym.. :-|
współczuję wszystkim w jakikolwiek sposób zawodowo ode mnie zależnym.. :-|
z cyklu: software development w praktyce |
22.11.2001
może się wydawać, że ja stale marudzę, że wkurzam się na nierealne terminy, niekompletne specyfikacje, kilkunastogodzinny dzień pracy, irytującego klienta a ostatnio także na pomysły pana geniusza Belki..
właściwie tak jest.. ale równocześnie podpisuję się obiema rękami pod słowami Brooksa:
właściwie tak jest.. ale równocześnie podpisuję się obiema rękami pod słowami Brooksa:
Tylko niewielu ludziom Pan Bóg daje przywilej zarabiania na życie wykonywaniem tego, co chętnie robiliby za darmo, jedynie z pasji. Jestem Mu bardzo wdzięczny, że jestem jednym z nich.[Frederick P. Brooks, Jr. : mityczny osobomiesiąc]
z cyklu: software development w praktyce | 4 komentarze
21.11.2001
— panie michale, czy pan czuje, że pan panuje nad systemem?
ponad dwa lata pracy kilku ludzi (dziś dziewięciu).. ponad 60 MB programu, jakieś 130 modułów i 150 tabel.. ilości linii kodu nie jestem w stanie podać nawet w przybliżeniu.. niezliczone zakamarki, niuanse obliczeń finansowych, specyficzne interpretacje i pojawiające się niespodziewanie niezrozumiałe lub przynajmniej zapomniane szczegóły.. dwa lata zmagań z instytucjami typu ZUS, KDPW czy inne UNFE, o 'widzimisie' jednego czy drugiego towarzystwa nie wspominając.. i to wszystko w nieustannej atmosferze nierealnych terminów i szczątkowych specyfikacji..
nad takim czymś nie da się panować..
— tak panie prezesie, oczywiście..
z cyklu: software development w praktyce | 3 komentarze
09.11.2001
pewne sytuacje w tej branży nie przestaną mnie dziwić chyba nigdy.. np. jak to możliwe, żeby brakowało mi jakiegokolwiek programu — dlaczego na komputerze, na którym jest software za kilkadziesiąt tysięcy dolców nie można zainstalować kilku podstawowych narzędzi za grosze w sumie..? no dlaczego nie?
każdy kto musi się jakoś w miarę sprawnie poruszać w tym całym bajzlu potrzebuje kilku niezbędników — no i każdy sobie radzi jak umie.. a potem przychodzi czas kontroli.. bywa różnie...
tak przy okazji tych przemyśleń — próbuję skompletować listę programów i programików użytku codziennego.. oczywiście najbardziej interesują mnie gesty dobrej woli i zerowe koszty.. na razie mam tak:
:: PowerArchiver 2001
:: 2xExplorer
:: VNC
:: TOAD freeware
:: NoteTab Light
:: EditPad
:: XnView
:: PuTTY
:: niByLog :-)
jakieś sugestie?
każdy kto musi się jakoś w miarę sprawnie poruszać w tym całym bajzlu potrzebuje kilku niezbędników — no i każdy sobie radzi jak umie.. a potem przychodzi czas kontroli.. bywa różnie...
tak przy okazji tych przemyśleń — próbuję skompletować listę programów i programików użytku codziennego.. oczywiście najbardziej interesują mnie gesty dobrej woli i zerowe koszty.. na razie mam tak:
:: PowerArchiver 2001
:: 2xExplorer
:: VNC
:: TOAD freeware
:: NoteTab Light
:: EditPad
:: XnView
:: PuTTY
:: niByLog :-)
jakieś sugestie?
z cyklu: software development w praktyce | 3 komentarze
24.10.2001
istnieje wiele książek usiłujących opisać szczególną rzeczywistość projektów informatycznych.. wśród nich również pozycje oparte na wieloletnich doświadczeniach autorów i niejednokrotnie podparte ich osobistą sławą.. książki z gatunku takich, które wszyscy znają, wielu kupuje, a mało kto tak naprawdę czyta.. można je pochłonąć wszystkie, można nawet przy odrobinie wysiłku je zrozumieć i usiłować poznać pewne mechanizmy, można zaakceptować fakt, że death march istnieje..
jednak nawet jeśli wiesz wszystko o inżynierii oprogramowania, nawet jeśli projekty informatyczne nie mają przed tobą tajemnic to i tak nie rozumiesz nic dopóki nie zetkniesz się z tym na polu walki.. nie da się teoretycznie wytłumaczyć jak niekompletne mogą być niekompletne wymagania, jak mało współpracujący może być niewspółpracujący klient albo jak krótki może być krótki termin..
i chyba głównie dlatego nie usiłuję tłumaczyć ludziom na czym polega moja praca..
jednak nawet jeśli wiesz wszystko o inżynierii oprogramowania, nawet jeśli projekty informatyczne nie mają przed tobą tajemnic to i tak nie rozumiesz nic dopóki nie zetkniesz się z tym na polu walki.. nie da się teoretycznie wytłumaczyć jak niekompletne mogą być niekompletne wymagania, jak mało współpracujący może być niewspółpracujący klient albo jak krótki może być krótki termin..
i chyba głównie dlatego nie usiłuję tłumaczyć ludziom na czym polega moja praca..
z cyklu: software development w praktyce | 2 komentarze
22.10.2001
nie lubię takich dni, które muszę spędzać pod krawatem, w stolicy, na dziwnych rozmowach.. ludzie siedzący po drugiej stronie stołu mają pewnie taki sam stosunek do nas jak my do nich — wszyscy wolelibyśmy być gdzie indziej.. niestety razem wdepnęliśmy w to gówno i razem się w nim zanurzamy.. jak pogadamy to może coś ustalimy, napiszemy, połatamy.. będzie jakoś, w sumie może nawet dobrze — przecież tutaj każdy jest właściwym człowiekiem na właściwym miejscu..
ale tak naprawdę to oni próbują wyjść na powierzchnię po naszych głowach a my robimy oczywiście dokładnie to samo — w końcu każdy ma jakiegoś szefa, któremu musi się tłumaczyć..
ale tak naprawdę to oni próbują wyjść na powierzchnię po naszych głowach a my robimy oczywiście dokładnie to samo — w końcu każdy ma jakiegoś szefa, któremu musi się tłumaczyć..
z cyklu: software development w praktyce | 4 komentarze
10.10.2001
przez ostatnich kilka lat już zdążyłem się przyzwyczaić, że świat informatyków opolskich jest mały — z każdym albo studiowałem, albo go/ją znam, albo w najgorszym przypadku znam kogoś kto go/ją zna.. wiadomo — małe miasto, ciasne znajomości..
jednak jeżeli na poziomie ogólnopolskim przedstawiciel dużej światowej firmy na nasze pytania odpowiada "- no ja tak dokładnie nie wiem, ale jest taki człowiek u was, (tutaj pada nazwisko mojego kolegi) i on się zna lepiej.." to jestem troszkę zdziwiony.. wygląda na to, że generalnie w tej branży też panują stosunki takie jakbyśmy wszyscy byli na jednych studiach.. ;-)
przy okazji mały wniosek na przyszłość — nie należy sprawdzać informacji podawanych przez kolegę na wypadek, gdyby ten właśnie człowiek okazał się oficjalnym specjalistą ;-)
jednak jeżeli na poziomie ogólnopolskim przedstawiciel dużej światowej firmy na nasze pytania odpowiada "- no ja tak dokładnie nie wiem, ale jest taki człowiek u was, (tutaj pada nazwisko mojego kolegi) i on się zna lepiej.." to jestem troszkę zdziwiony.. wygląda na to, że generalnie w tej branży też panują stosunki takie jakbyśmy wszyscy byli na jednych studiach.. ;-)
przy okazji mały wniosek na przyszłość — nie należy sprawdzać informacji podawanych przez kolegę na wypadek, gdyby ten właśnie człowiek okazał się oficjalnym specjalistą ;-)
z cyklu: software development w praktyce |
03.10.2001
czy jeżeli programista mi mówi, że czegoś nie da się napisać tak jak to wymyśliłem to znaczy, że to cienki programista, czy mój projekt jest beznadziejny..? albo: czy programista powinien wykazywać na tyle inwencji, żeby do pracy wystarczała mu ogólna koncepcja rozwiązania, czy ma robić dokładnie tak jak zostało zaprojektowane i ani więcej ani mniej, nawet jeśli projekt ma jakieś braki..? albo: czy stwierdzenie, że programista jest artystą odnosi się do wszystkich projektów czy tylko do takich, gdzie jest jeden facet (sam sobie sterem, żeglarzem, okrętem, analitykiem, projektantem, testerem, sekretarką ...)..?
czy ktoś zna odpowiedzi na takie pytania?
czy ktoś zna odpowiedzi na takie pytania?
z cyklu: software development w praktyce |
20.09.2001
wniosków z kursu ciąg dalszy:
jeśli uważasz, że w projekcie nie ma ryzyka to nie rób tego projektu, bo sobie nie uświadamiasz zagrożeń.. jeżeli uważasz, że projekt jest ryzykowny to możesz go robić bo jesteś świadomy..
czasami mi się wydaje, że moja praca jest zbyt zbliżona do samobójstwa.. to trochę irracjonalne i dziwne, że ludzie chcą się zajmować produkcją systemów informatycznych mając świadomość, że ta zabawa jest jak piknik na polu minowym.. ;-/
jeśli uważasz, że w projekcie nie ma ryzyka to nie rób tego projektu, bo sobie nie uświadamiasz zagrożeń.. jeżeli uważasz, że projekt jest ryzykowny to możesz go robić bo jesteś świadomy..
czasami mi się wydaje, że moja praca jest zbyt zbliżona do samobójstwa.. to trochę irracjonalne i dziwne, że ludzie chcą się zajmować produkcją systemów informatycznych mając świadomość, że ta zabawa jest jak piknik na polu minowym.. ;-/
z cyklu: software development w praktyce |
19.09.2001
wczoraj, dziś i jutro — kurs "zarządzanie projektami informatycznymi".. wniosek na razie mam jeden: jedyną niezmienną rzeczą w projekcie jest to, że wszystko się zmienia..
z cyklu: software development w praktyce |
04.09.2001
15 godzin w pracy w tym blisko 9 w samochodzie.. skomplikowane zadanie, krótki termin, trudny klient — takie rozmowy nigdy się nie kleją.. w sumie zmęczenie totalne.. :-|
a stolica nieodmiennie robi na mnie niemiłe wrażenie.. dobrze przynajmniej, że niektóre firmy mają przyjemne lokale..
a stolica nieodmiennie robi na mnie niemiłe wrażenie.. dobrze przynajmniej, że niektóre firmy mają przyjemne lokale..
z cyklu: software development w praktyce |
06.08.2001
ile czasu? jedno z najgorszych możliwych pytań.. wiadomo przecież że będzie gotowe jak się skończy, na pewno nie wcześniej.. ale kiedy?
zastanówmy się — jak długo będę musiał myśleć aż wymyślę rozwiązanie? czy będę miał przebłysk geniuszu czy raczej nie ruszę z miejsca przez tydzień? czy dostanę odpowiedzi na wszystkie pytania? czy w ogóle znam pytania jakie będę zadawał? ile czasu poświęcę na bezsensowne dłubanie w nosie? ile przesiedzę w kiblu? a jak długo będzie się to potem pisać? kto to w ogóle będzie pisał? czy mój projekt przyda się na cokolwiek? a blog? co z blogiem?
wystarczy odpowiedzieć na taki prosty zestaw pytań i wstępna kalkulacja kosztu opracowania gotowa.. koszmar dnia codziennego.. :-|
zastanówmy się — jak długo będę musiał myśleć aż wymyślę rozwiązanie? czy będę miał przebłysk geniuszu czy raczej nie ruszę z miejsca przez tydzień? czy dostanę odpowiedzi na wszystkie pytania? czy w ogóle znam pytania jakie będę zadawał? ile czasu poświęcę na bezsensowne dłubanie w nosie? ile przesiedzę w kiblu? a jak długo będzie się to potem pisać? kto to w ogóle będzie pisał? czy mój projekt przyda się na cokolwiek? a blog? co z blogiem?
wystarczy odpowiedzieć na taki prosty zestaw pytań i wstępna kalkulacja kosztu opracowania gotowa.. koszmar dnia codziennego.. :-|
z cyklu: software development w praktyce |
09.04.2001
nic ciekawego się nie wydarzy.. znam AGATę od prawie dwóch lat.. byłem przy jej największych upadkach i rzadkich momentach chwały, spędziłem z nią długie wieczory i niejeden weekend wykradziony mojej żonie.. przez ten czas nauczyłem się jednego: AGATa to dziwka - zabiera ludziom czas i siły dając w zamian chwilową ułudę szczęścia.. możecie się dobrze znać a i tak przy byle okazji wbije Ci nóż w plecy :-(
z cyklu: software development w praktyce | 1 komentarz
20.03.2001
"— robimy to wszystko na raz i wdrażamy równocześnie.. nie ma na co czekać.. małe kroki są dobre dla kosmonautów.."
no nie wiem.. ja na przykład wolałbym zwolnić i odpocząć.. może jakiś urlop, albo coś takiego.. jak nie ma co robić to nie jest dobrze, ale jak jest za dużo to jeszcze gorzej.. niestety w tej branży nigdy nie ma nic po środku :-|
no nie wiem.. ja na przykład wolałbym zwolnić i odpocząć.. może jakiś urlop, albo coś takiego.. jak nie ma co robić to nie jest dobrze, ale jak jest za dużo to jeszcze gorzej.. niestety w tej branży nigdy nie ma nic po środku :-|
z cyklu: software development w praktyce |
12.03.2001
próba profesjonalnego spojrzenia na moją pracę i okolice wywołuje zawsze przygnębiające wnioski - wszędzie amatorszczyzna.. tutaj nawet zawodowcy są amatorami, nawet najlepsi.. do tego żeby być programistą nie potrzeba żadnego wykształcenia, niewiele doświadczenia, nie trzeba mieć żadnych certyfikatów ani uprawnień.. wszystkiego się nabywa z czasem, albo wcale i też nie szkodzi.. oczywiście bardziej wymagające firmy oczekują od pracowników "doświadczenia" - ale co to właściwie jest? wystarczy powiedzieć "ja mam doświadczenie, nie takie rzeczy robiłem, znam się na tym, jestem dobry, spoko.. a tego co nie wiem to się nauczę i też sobie dam radę..".. to najczęściej gówno prawda..
dla kontrastu proponuję przyjrzeć się jakiemukolwiek innemu inżynierowi/projektantowi - człowiek, który nie może okazać swoich uprawnień nie ma szans na sprzedanie czegokolwiek.. nie zaprojektuje żadnej instalacji, budynku, mostu, maszyny, niczego - nawet wentylacji w szopie ani rozmieszczenia pisuarów w kiblu..
a projektant/programista..? "bystry chłopak jest" - i wystarczy..
znam genialnych programistów bez wykształcenia.. oczywiście, że znam, ale nie o to chodzi - oni mogą być świetni, niezastąpieni, podziwiani, mistrzowie świata.. ale w klasie amatorów.. dopóki poważne oprogramowanie jest tworzone przez każdego kto ma na to ochotę, póty w licencji dowolnego programu będzie sakramentalne "without warranty of any kind".. żenada :-|
dla kontrastu proponuję przyjrzeć się jakiemukolwiek innemu inżynierowi/projektantowi - człowiek, który nie może okazać swoich uprawnień nie ma szans na sprzedanie czegokolwiek.. nie zaprojektuje żadnej instalacji, budynku, mostu, maszyny, niczego - nawet wentylacji w szopie ani rozmieszczenia pisuarów w kiblu..
a projektant/programista..? "bystry chłopak jest" - i wystarczy..
znam genialnych programistów bez wykształcenia.. oczywiście, że znam, ale nie o to chodzi - oni mogą być świetni, niezastąpieni, podziwiani, mistrzowie świata.. ale w klasie amatorów.. dopóki poważne oprogramowanie jest tworzone przez każdego kto ma na to ochotę, póty w licencji dowolnego programu będzie sakramentalne "without warranty of any kind".. żenada :-|
z cyklu: software development w praktyce |
27.02.2001
to było tak: jeden napisał drugiemu kiepski system i teraz ten drugi nie może się dogadać z trzecim w sprawie jeszcze innych.. no i niby wszystko normalnie - kryzys oprogramowania w działaniu.. tylko, że ja zaraz dostanę od tego wrzodów na żołądku :-|
z cyklu: software development w praktyce |
21.02.2001
...
18:40 jeszcze o tym nie wiem, ale mój kierownik odbiera telefon i udziela standardowej odpowiedzi kierownika numer 1 - "jeśli ktoś może to sprawdzić to chyba najszybciej Michał"
18:50 telefon: dowiaduję się o powyższym.. nie mam pojęcia co to za kod E_UMO001.. jak dostanę oficjalne polecenie to wrócę do firmy i sprawdzę.. tak, pracę kończę o 16:00.. oczywiście wiem, że jest to potrzebne dzisiaj.. mogę spróbować podpowiedzieć gdzie szukać.. jest zimno i wieje..
18:55 sms: "sprytne" ALTER TABLE ... było mi potrzebne jakieś 6 godzin temu.. dzięki..
19:02 telefon: fajnie, że już wiadomo co to E_UMO001.. to po co było do mnie dzwonić?
19:15 jestem wreszcie w domu
19:17 włączam komputer
19:20 idę sobie zrobić trzecią kawę..
...
można się przyzwyczaić, można też zwariować - wybór indywidualny.. ja ostatnio nie jestem pewien co wybieram.. trochę mnie ciągnie do Rzeczywistości Analogowej.. gdzie nie ma telefonów i ... tak, nawet komputerów tam nie ma.. do takiego miejsca, gdzie są tylko moje własne problemy.. i Stare Płyty..
ale to kiedyś.. a jutro..? jutro wstanę rano i znów pójdę do pracy.. nic nadzwyczajnego, prawda? a jednak..
18:40 jeszcze o tym nie wiem, ale mój kierownik odbiera telefon i udziela standardowej odpowiedzi kierownika numer 1 - "jeśli ktoś może to sprawdzić to chyba najszybciej Michał"
18:50 telefon: dowiaduję się o powyższym.. nie mam pojęcia co to za kod E_UMO001.. jak dostanę oficjalne polecenie to wrócę do firmy i sprawdzę.. tak, pracę kończę o 16:00.. oczywiście wiem, że jest to potrzebne dzisiaj.. mogę spróbować podpowiedzieć gdzie szukać.. jest zimno i wieje..
18:55 sms: "sprytne" ALTER TABLE ... było mi potrzebne jakieś 6 godzin temu.. dzięki..
19:02 telefon: fajnie, że już wiadomo co to E_UMO001.. to po co było do mnie dzwonić?
19:15 jestem wreszcie w domu
19:17 włączam komputer
19:20 idę sobie zrobić trzecią kawę..
...
można się przyzwyczaić, można też zwariować - wybór indywidualny.. ja ostatnio nie jestem pewien co wybieram.. trochę mnie ciągnie do Rzeczywistości Analogowej.. gdzie nie ma telefonów i ... tak, nawet komputerów tam nie ma.. do takiego miejsca, gdzie są tylko moje własne problemy.. i Stare Płyty..
ale to kiedyś.. a jutro..? jutro wstanę rano i znów pójdę do pracy.. nic nadzwyczajnego, prawda? a jednak..
wchodzę bezbronnie rozebrany do klatki w której tygrys śpi
na ścianach jarzą się ekrany i widzę o czym bestia śni
oto mój krzyk i strach przed śmiercią przecina błysk tygrysich kłów
obracam w palcach złoty pieniądz kopniakiem budząc go ze snu[perfect : obracam w palcach złoty pieniądz]
z cyklu: software development w praktyce |
14.02.2001
jedną z najbardziej denerwujących rzeczy w tym narzędziu jest duża doza ornitologii — wszystko zależy od umiejętnego podejścia do ptaszków.. nieraz spędziłem pół dnia na szukaniu dlaczego coś zachowuje się inaczej niż by się wydawało, aż w końcu gdzieś w zakamarkach znajdowałem okienko dialogowe z checkboxem 'zachowuj się normalnie' — postawienie w tym miejscu ptaszka diametralnie zmieniało sytuację.. z czasem nauczyłem się kilku takich sztuczek, ale ponieważ nigdy nie miałem zamiłowania ornitologicznego to śledzenie ptaszków nadal mnie męczy.. :-|
z cyklu: software development w praktyce |
13.02.2001
Frederick P. Brooks, Jr : mityczny osobomiesiąc - eseje o inżynierii oprogramowania:
Programowanie jest [...] smolistym grzęzawiskiem, w którym utknęło wiele prac, i twórczą działalnością, która daje radość, ale sprawia ból. Według wielu ludzi, radość przeważa nad bólem.może i przeważa.. ale na pewno nie dzisiaj :-|
z cyklu: software development w praktyce |
02.02.2001
Frederick P. Brooks, Jr : mityczny osobomiesiąc - eseje o inżynierii oprogramowania:
Radość programowania: Pierwsza to zwyczajna rozkosz tworzenia czegoś. Jak dziecko lubi stawiać domki z piasku, tak dorosły lubi budować coś, zwłaszcza według własnego projektu. [...] Druga to przyjemność robienia czegoś przydatnego dla innych ludzi. W głębi duszy chcemy, żeby inni korzystali z naszej pracy i uznawali ją za użyteczną. [...] Trzecia przyjemność to fascynacja tworzenia złożonych przedmiotów, przypominających łamigłówki składające się z zazębiających się, ruchomych części, i obserwowanie ich działania [...]. Czwarta przyjemność wypływa z ciągłego uczenia się i wiąże się z niepowtarzalnością istoty zadania. W taki czy inny sposób problem jest wciąż nowy, a ten, kto go rozwiązuje, czegoś się uczy [...]świetnie.. ale już następny rozdział ma tytuł Ból programowania, gdyż
świadomość nieuniknionych nieszczęść pomaga je znieść, kiedy nadejdą;-)
z cyklu: software development w praktyce |
24.01.2001
czy ktoś przypadkiem może mi podpowiedzieć do czego służy zmienna a_0007274662_ioa->l000l01.format_001as w funkcji f_327701() w pliku ikw1knt.c? bo ja po kilku godzinach walki dochodzę do wniosku, że nie mam bladego pojęcia :-|
lubię moją pracę, ale czasem jestem całkowicie bezsilny.. zwłaszcza jak trafi mi w ręce jakaś pozostałość po panach z tej firmy.. niby wszystko jest ok - przecież to się kompiluje i nawet działa.. wiem, że jeśli kompilator to rozumie to ja też potrafię.. tylko, że to tak bardzo męczy...
lubię moją pracę, ale czasem jestem całkowicie bezsilny.. zwłaszcza jak trafi mi w ręce jakaś pozostałość po panach z tej firmy.. niby wszystko jest ok - przecież to się kompiluje i nawet działa.. wiem, że jeśli kompilator to rozumie to ja też potrafię.. tylko, że to tak bardzo męczy...
z cyklu: software development w praktyce |
05.01.2001
jak długo można dyskutować o subtelnych różnicach w znaczeniu słów modyfikacja, rozbudowa i poprawa błędu?
na razie trzeci dzień..
na razie trzeci dzień..
z cyklu: software development w praktyce |
15.12.2000
filozofia niektórych znanych mi pracodawców: "jak zaczynasz rozumieć jak coś działa i dlaczego to znaczy, że już za długo się tym zajmujesz".. i jeszcze takie kwiatki jak: "potrzebujemy programistów a nie programistów języka x i specjalistów a nie specjalistów branży x".. dosyć pokręcone pojmowanie postulatu konkurencyjności w szerokim zakresie.. ;-)
z drugiej strony są tacy, którzy uważają, że jedynie słuszną drogą jest wąska specjalizacja - wgłębienie się w jakiś temat na tyle, żeby po prostu nie było konkurencji..
i kto ma rację?
z drugiej strony są tacy, którzy uważają, że jedynie słuszną drogą jest wąska specjalizacja - wgłębienie się w jakiś temat na tyle, żeby po prostu nie było konkurencji..
i kto ma rację?
z cyklu: software development w praktyce |
13.12.2000
właśnie znalazłem we fragmencie kodu nad którym się chwilowo znęcam coś takiego:
NOTE ***** TO DOCZYTANIE MUSI BYC - NIEZLY SYF !!!!!!!
a kiedyś się śmiali z mojego
NOTE *** That's all folks!
na końcu niektórych action blocków ;-)
a propos: niektórzy programiści mają bardzo specyficzny sposób komentowania kodu - niejednokrotnie czytając komentarz (lub pseudo komentarz) bezbłędnie zgaduję kto to pisał.. niektórzy np. używają tylko dużych liter, inni tylko małych, jedni komentują "poważnie", inni "z jajem", jedni bardziej a inni mniej emocjonalnie, jedni "gęsto", inni tylko w najważniejszych momentach, jedni z ozdobnikami typu "--------------" czy inne gwiazdki, inni zupełnie bez.. to pewnym czasie pracy w zespole pojawiają się zdania typu "a to pewnie JYK pisał.. tak wygląda na jego styl" :-)
oczywiście większość nie komentuje wcale.. ale to już zupełnie inna historia..
NOTE ***** TO DOCZYTANIE MUSI BYC - NIEZLY SYF !!!!!!!
a kiedyś się śmiali z mojego
NOTE *** That's all folks!
na końcu niektórych action blocków ;-)
a propos: niektórzy programiści mają bardzo specyficzny sposób komentowania kodu - niejednokrotnie czytając komentarz (lub pseudo komentarz) bezbłędnie zgaduję kto to pisał.. niektórzy np. używają tylko dużych liter, inni tylko małych, jedni komentują "poważnie", inni "z jajem", jedni bardziej a inni mniej emocjonalnie, jedni "gęsto", inni tylko w najważniejszych momentach, jedni z ozdobnikami typu "--------------" czy inne gwiazdki, inni zupełnie bez.. to pewnym czasie pracy w zespole pojawiają się zdania typu "a to pewnie JYK pisał.. tak wygląda na jego styl" :-)
oczywiście większość nie komentuje wcale.. ale to już zupełnie inna historia..
z cyklu: software development w praktyce |
08.11.2000
okazuje się, że "spróbuj jeszcze raz" może być oficjalnym rozwiązaniem problemu - przykład z dokumentacji Oracla: "Try the operation again in a few minutes. If this message occurs often, shut down Oracle, [..bla bla bla...], and restart Oracle." :-|
z cyklu: software development w praktyce |
08.11.2000
ludzie chcący się zatrudnić jako programiści powinni przechodzić egzamin praktyczny z posługiwania się klawiaturą.. nie chodzi pisanie bezwzrokowe w ekspresowym tempie z wykorzystaniem 10 palców - to przychodzi z czasem lub wcale (sam ledwie używam ośmiu i też wystarcza).. chodzi raczej o ogólne obycie i coś co nazwałbym umiejętnością korzystania z narzędzia.. jeśli facet usiłuje coś pisać, same czyste teksty i leży mu przed nosem te sto-coś klawiszy a mimo to ręka mu lata bez przerwy między klawiaturą a myszą, to ja uważam, że marnuje czas, narzędzie i moją cierpliwość.. i nie ważne, że robi to w czterech plikach i w trzech różnych edytorach równocześnie - znając kilka banalnych kombinacji klawiszy można (czytaj: trzeba) to zrobić 10 razy szybciej nie tracąc ani na moment kontaktu z klawiaturą..
z cyklu: software development w praktyce |
25.10.2000
zastanawialiście się kto pisze helpy i dokumentacje programów? piszą "specjaliści".. w moim przypadku bywało różnie - czasem byli to ludzie z serwisu oprogramowania zajmujący się też wdrożeniami u klienta, czasem byli to analitycy piszący również wymagania i założenia systemowe.. nigdy nie byli to programiści.. to zbyt nudne zajęcie a wymówek jest na prawdę sporo: "- bo nie ma czasu", "- bo lepiej poprawiać błędy niż pisać helpy", "- bo umiem się wysławiać tylko w C++ a nie po polsku" a nawet jak usłyszałem od pewnego popularnego w okolicy twórcy: "- bo ja za dobrze rozumiem program i dobrej pomocy nie zrobię" :-D
z cyklu: software development w praktyce |
23.10.2000
co zrobić jak program się 'lubi się' wieszać i wywracać w najmniej oczekiwanych momentach..? przepraszać użytkowników, wydawać patche, zmieniać wymagania sprzętowe..? można.. ale można też zrobić tak jak chłopcy ze Sterlinga - opublikować "developer's tips and tricks", w nim napisać że jedynym wyjściem jest częste zapisywanie i jeszcze zrobić z tego slogan CTRL+V for Victory.. uwielbiam ich styl :-D
z cyklu: software development w praktyce |
19.10.2000
czy jeżeli napiszesz kawałek programu, który się wykonuje godzinę, a potem zmodyfikujesz go tak, że robi to samo w dwie minuty to możesz być z siebie dumny?
nie! ponieważ oznacza to, że w pierwotnej wersji ten program był żałosny.. zadowolony możesz być wtedy, kiedy od razu napiszesz tak, że nie da się tego przyspieszyć, lub koszt optymalizacji jest na tyle wysoki, że taka zabawa jest nieopłacalna..
nie! ponieważ oznacza to, że w pierwotnej wersji ten program był żałosny.. zadowolony możesz być wtedy, kiedy od razu napiszesz tak, że nie da się tego przyspieszyć, lub koszt optymalizacji jest na tyle wysoki, że taka zabawa jest nieopłacalna..
z cyklu: software development w praktyce |
12.10.2000
jeszcze odnośnie tej książki..
oglądając ją w księgarni zerknąłem na przypadkowy fragment wstępu - trafiłem na coś takiego:
zdecydowanie polecam każdemu kto ma jakikolwiek udział w przynajmniej kilkuosobowym projekcie informatycznym - nauczycie się jak przetrwać, a przynajmniej poczytajcie że wszyscy na całym świecie mają to samo.. projekt na drodze ku klęsce to reguła, nie wyjątek - takie już są uroki tego zawodu :-)
oglądając ją w księgarni zerknąłem na przypadkowy fragment wstępu - trafiłem na coś takiego:
projekty bywają marszami ku klęsce, ponieważ kierownictwo to obłudne sukinsyny, a użytkownicy są naiwni i nie myślą realnieod tego momentu wiedziałem, że to jest książka o moim życiu (zawodowym).. sytuacje beznadziejne, terminy na "tydzień temu", brak ludzi i pomysłów, ale my i tak zdążymy, bo ... takie są założenie szefostwa a nieistniejący program jest już dawno sprzedany..
zdecydowanie polecam każdemu kto ma jakikolwiek udział w przynajmniej kilkuosobowym projekcie informatycznym - nauczycie się jak przetrwać, a przynajmniej poczytajcie że wszyscy na całym świecie mają to samo.. projekt na drodze ku klęsce to reguła, nie wyjątek - takie już są uroki tego zawodu :-)
z cyklu: software development w praktyce |
12.10.2000
Dlaczego mimo ryzyka i konieczności pokonania olbrzymich trudności ludzie wspinają się na tak groźne szczyty, jak Mount Everest? Bo te szczyty istnieją. Dlaczego ludzie uczestniczą w maratonie i doprowadzają się do skrajnego wyczerpania w triatlonie? Bo to są wyzwania. Najbardziej podniecające są takie wyzwania, którym jeszcze nikt nie sprostał.czasami tak mam.. mimo, że z natury nie jestem jakoś chorobliwie ambitny..[Edward Yourdon : marsz ku klęsce]
z cyklu: software development w praktyce |
10.10.2000
niewielu widziałem programistów nie używających papieru.. mimo, że najczęściej nie umiemy za dobrze pisać w sposób tradycyjny to jednak każdy coś tam bazgrze.. długopisem, pisakiem, ołówkiem lub kredką.. jedni mają do tego przypadkowe karteczki, całe stosy karteczek, które z czasem oblegają ich ze wszystkich stron.. inni mają specjalnie w tym celu wyhodowane zeszyty..
ja też mam taki zeszyt.. leży tuż przede mną, a właściwie między mną a klawiaturą.. w nim notuję wszystkie ważne ustalenia, rysuję nowe koncepcje.. między jego kartkami trzymam różne mało ważne pisma, faksy, zlecenia.. na nim także jem, stawiam ociekające kubki z kawą, kładę tłuste bułki i czekoladowe wafelki.. taki niby zwykły zeszyt formatu A4, a z czasem staje się sporym kawałkiem historii.. wszystko co ważne mam gdzieś w nim zapisane - jakieś 100 kartek ważnych rzeczy, niezwykle cennych schematów i przeważnie poronionych koncepcji..
mój zeszyt niedługo się skończy.. będę musiał wziąć nowy, tylko że nowy jest do niczego.. bardzo długo jest do niczego.. zacznie coś znaczyć właśnie wtedy jak zacznie się kończyć..
ja też mam taki zeszyt.. leży tuż przede mną, a właściwie między mną a klawiaturą.. w nim notuję wszystkie ważne ustalenia, rysuję nowe koncepcje.. między jego kartkami trzymam różne mało ważne pisma, faksy, zlecenia.. na nim także jem, stawiam ociekające kubki z kawą, kładę tłuste bułki i czekoladowe wafelki.. taki niby zwykły zeszyt formatu A4, a z czasem staje się sporym kawałkiem historii.. wszystko co ważne mam gdzieś w nim zapisane - jakieś 100 kartek ważnych rzeczy, niezwykle cennych schematów i przeważnie poronionych koncepcji..
mój zeszyt niedługo się skończy.. będę musiał wziąć nowy, tylko że nowy jest do niczego.. bardzo długo jest do niczego.. zacznie coś znaczyć właśnie wtedy jak zacznie się kończyć..
z cyklu: software development w praktyce |
01.08.2000
czy można w trakcie działania edytora jakiegoś języka programowania na bieżąco zamieniać kolejność parametrów wywołania jednej z podstawowych funkcji? okazuje się, że można.. chociaż do tego są zdolni chyba tylko chłopcy ze Sterlinga..
z cyklu: software development w praktyce |
28.07.2000
ja nikogo nie popędzam.. każdy ma swoje zadanie i wie jaki jest termin.. ja co najwyżej przypominam, że ten termin jest w poniedziałek.. zdążysz zrobić w jeden dzień tyle co inni w miesiąc - to ci się chwali.. jak nie, to przynajmniej zastanów się co potem..
praca zespołowa ma swoje zalety (nie musisz działać sam) ale ma też i wady (nie możesz działać sam)...
praca zespołowa ma swoje zalety (nie musisz działać sam) ale ma też i wady (nie możesz działać sam)...
z cyklu: software development w praktyce |
26.07.2000
informatycy, a szczególnie programiści to (może wbrew pozorom) najbardziej leniwi ludzie jakich znam.. jeżeli jest jakaś żmudna praca do wykonania to "rasowy" informatyk/programista zaczyna od "przygotowania narzędzia" - jakiś program czy skrypt wobec alternatywy ręcznego dłubania jest po prostu konieczny, nawet jeśli jest to zadanie jednorazowe.. najważniejsze, żeby problem rozwiązać szybko, bez zbytniego wysiłku albo najlepiej automatycznie..
a fakt, że wynalezienie narzędzia zajęło kilkakrotnie więcej czasu i energii niż zajęłoby wykonanie tego ręcznie to już zupełnie inna sprawa..
a fakt, że wynalezienie narzędzia zajęło kilkakrotnie więcej czasu i energii niż zajęłoby wykonanie tego ręcznie to już zupełnie inna sprawa..
z cyklu: software development w praktyce |
21.07.2000
muszę przyznać, że niewiele jest rzeczy, które mi imponują.. są to najczęściej fakty, ludzie lub cechy rzadkie i w pewnym świetle niezwykłe.. jedną z nich jest zdolność do mądrego spojrzenia na postawiony problem z całkiem innego punktu, całkiem z boku ale nie bez sensu..
są przykładowo takie momenty kiedy kilka osób męczy się nad jakimś problemem, próbując wymyślić jakiś sensowny algorytm reakcji na konkretną sytuację - za nic nie chce to wyjść, zawsze jest jakieś ale, jakiś szczególny przypadek, który kładzie całą koncepcję.. i nagle ktoś mówi "taki przypadek nas w ogóle nie interesuje, bo..." cośtam... coś o czym jakoś nikt nie pomyślał, a co jednym prostym zdaniem kwituje kilkugodzinną dyskusję.. jak jajko Kolumba - zaskakująco proste rozwiązanie bardzo trudnego problemu..
spotykam się z taką sytuacją co jakiś czas i zawsze jestem zaskoczony..
jeżeli przypadkowo tym kimś jestem ja - jestem zdumiony tym bardziej....
są przykładowo takie momenty kiedy kilka osób męczy się nad jakimś problemem, próbując wymyślić jakiś sensowny algorytm reakcji na konkretną sytuację - za nic nie chce to wyjść, zawsze jest jakieś ale, jakiś szczególny przypadek, który kładzie całą koncepcję.. i nagle ktoś mówi "taki przypadek nas w ogóle nie interesuje, bo..." cośtam... coś o czym jakoś nikt nie pomyślał, a co jednym prostym zdaniem kwituje kilkugodzinną dyskusję.. jak jajko Kolumba - zaskakująco proste rozwiązanie bardzo trudnego problemu..
spotykam się z taką sytuacją co jakiś czas i zawsze jestem zaskoczony..
jeżeli przypadkowo tym kimś jestem ja - jestem zdumiony tym bardziej....
z cyklu: software development w praktyce |
12.07.2000
burza mózgów.. rysuję coś na tablicy, ktoś mi to kreśli.. trzy kolory, diagram też jakby już nie jeden, koncepcje ze cztery równolegle.. na prawdę długo trwa zanim możemy powiedzieć "chyba będzie dobrze, ale zostawmy to do rana"..a jak to się ma do wstępnych założeń? nijak ale będzie dobrze...
praca w zespole to zupełnie inna bajka niż samotne dłubanie - dopiero pod wpływem innych masz pomysły o jakie sam siebie nie podejrzewałeś.. czy jak sam sobie powiesz "będzie działać" to możesz w to uwierzyć?
dosyć męczące, ale chyba właśnie za to kocham tą robotę..
praca w zespole to zupełnie inna bajka niż samotne dłubanie - dopiero pod wpływem innych masz pomysły o jakie sam siebie nie podejrzewałeś.. czy jak sam sobie powiesz "będzie działać" to możesz w to uwierzyć?
dosyć męczące, ale chyba właśnie za to kocham tą robotę..
z cyklu: software development w praktyce |