znalezione wpisy oznaczone „inżynieria?”:

kryptonim: polmos

Produkcja oprogramowania kategorii środkowej pociąga za sobą jeszcze jedną komplikację, której wcześniej nie byłem świadom — wersjonowanie programu okazuje się nie całkiem banalne.

...ponieważ jesteś kretynem, który łatwo daje się zagadać

Są takie książki, których warto się uczyć na pamięć. I są takie cytaty, które po prostu trzeba zapisać...

Jak przeżyć pod naporem zadań i nie zwariować do końca

Disclaimer: znowu będzie marudzenie o sprawach, które nikogo nie obchodzą. Za to będzie długo. Ale co mi tam. Czasem trzeba po prostu napisać coś dla przekonania samego siebie, że pewne działania wbrew pozorom mają sens... ;-) Charakter mojej pracy uległ w czasie ostatniego pół roku tak znacznej zmianie, że właściwie nie spodziewałem się, że to kiedykolwiek nastąpi. Słowem wpadłem po uszy w środowisko rzeczywiście sterowane zadaniami. Nie dziwne zatem, że starając się przeżyć (efektywnie) w pracy i równocześnie wyspać (również efektywnie) nie myśląc o pracy po nocy, opracowałem sobie pewien zestaw zachowań i zebrałem pewien zbiór maksymalnie prostych narzędzi umożliwiających funkcjonowanie w środowisku sterowanym zadaniami. Garść przemyśleń poniżej. Wszelkie komentarze i propozycje jak zwykle mile widziane...

Ja nic nie wiem, ja tu tylko programuję...

Po ponad 8 latach pracy zawodowej z systemami o zbliżonym i względnie ograniczonym zakresie biznesowym, dokonałem ostatnio całkowitej zmiany branży... Stąd narasta we mnie od jakiegoś czasu pytanie, którego nie miałem potrzeby zadawać właściwie nigdy wcześniej: na ile ważne jest zrozumienie procesu biznesowego klienta i sposobu w jaki używa on naszego oprogramowania?

Rzeczywistość tu jak nieczynne neony

Zapewne tego nie widać, ale sporo się u mnie dzieje. Niestety(?) nie w zakresie tematów, które mogłyby zainteresować potencjalnych czytelników tego bloga. Z waszego punktu widzenia można założyć, że mam coś w rodzaju wakacji. A w ramach zapchajdziury wrzucam tu kilka luźnych przemyśleń zainspirowanych miejscem, w którym się w międzyczasie znalazłem...

poniedziałek — czas zapolować na demony

Kiedy System Informatyczny staje się Dużym Systemem Informatycznym?

Mów do mnie obrazami

Luźna uwaga na boku: analiza zawierająca dużo tekstu i mało obrazków nie jest analizą dobrą. Kropka.

Wystarczająco prosty projekt interfejsu

Stworzenie prototypu funkcjonalnego interfejsu użytkownika w postaci obrazków (choćby i klikalnych, ale nie udających prawdziwego systemu) zamiast w jakiś sposób programistyczny (np. za pomocą „faktycznie działającego” HTML-a) ma kilka ciekawych konsekwencji, które z punktu widzenia jego przeznaczenia należy z pewnością uznać za zalety

Człowiek musi być obłąkany

Żadne przygotowanie teoretyczne nie jest w stanie uodpornić zdrowego człowieka na pomysły wariatów.

Czy klient to nasz pan?

Poniższe miało być komentarzem do wpisu Patrysa, który z kolei jest komentarzem do wpisu Łukasza, który komentuje ... i tak dalej i tak dalej... Postanowiłem kontynuować ten łańcuszek szczęścia i zamieszczam te kilka zdań jako wpis osobny. A co tam...

Każdy ma taką inżynierię, na jaką go stać

Z powodów najróżniejszych, wśród których zmiana pracodawcy wcale nie jest najważniejszym, nie poświęcam ostatnio tyle uwagi okolicznym blogom, ile szanujący się obywatel Sieci poświęcać powinien. Jednak mimo przeciwności zdarza mi się trafić, zazwyczaj po czasie, na coś interesującego...

profesja czy ledwie zajęcie?

Wszystkim znudzonym mnogością informacji czysto technicznych, ewentualnie zainteresowanym szukaniem ludzkiej strony branży polecam ostatni artykuł na Hacknot: „The Crooked Timber Of Software Development”.

gdzie ten diabeł?

wychodzi na to, że nawet jeśli faktycznie opis funkcjonalności jest „rozsądnie uogólniony”, to projekt techniczny i tak musi zawierać kilka zupełnie irracjonalnych szczegółów... :-/ Największy diabeł tkwi w tym, co zostało w cytowanym na wstępie tekście ujęte rozbrajająco prostym „oraz ERD”.

proste narzędzia

Simple tools are easy to learn, easy to use, and very often easy to share with others. Yes, complex tools have their place, assuming they provide the best value for your investment in them, but never underestimate the effectiveness of simple tools either.

SIWZ

W moim wyobrażonym świecie sytuacji idealnych, które czasami (wbrew pozorom) faktycznie się zdarzają, pierwszy kontakt ”technicznych” przedstawicieli producenta oprogramowania (czyli analityka i/lub szefa grupy wykonawczej) z potencjalnym przyszłym systemem informatycznym następuje na poziomie dokumentu SIWZ.

Jutro obetniemy wam jaja!

Przypomniałem sobie kilka słów, które napisałem (a może wręcz opublikowałem, w końcu to na blogu było) dwa i pół roku temu, a które dziwnie złośliwie nie chcą stracić na aktualności.

kiełbasy, ustawy i systemy

Żelazny kanclerz Niemiec Otto von Bismarck mawiał, że lepiej nie patrzeć, jak powstają kiełbasy i ustawy. Dziś należałoby jeszcze jego radę rozszerzyć o publiczne systemy informatyczne.

wycieczka do piekła

Im więcej różnych programistów lub zespołów roboczych pracuje nad projektem informatycznym w czasie całej jego historii, tym trudniej jest „zgrać” efekty ich działań i tym niższej jakości jest produkt tego projektu. Obserwacja ta wydaje się oczywista, wręcz banalna, a mimo to bywa zupełnie niepojęta

Kryzys wartości - odsłona trzecia i ostatnia

Ciąg dalszy dywagacji (powiadają, że straszliwych) na koniec roku.

Kryzys wartości - odsłona druga

Nie ma programu bez błędów — każdy, kto się zetknął z jakimkolwiek programowaniem czegokolwiek dobrze o tym wie. A jednak jest na takie buble popyt, więc z powodzeniem zajmujemy się ich komercyjną produkcją. Osobiście wątpię w uczciwość takiego zajęcia.

Kryzys wartości - odsłona pierwsza

Inżynieria oprogramowania (pomijając cokolwiek akademickie rozważania na temat zasadności samego słowa „inżynieria” w tym kontekście) jest jedną z najszybciej rozwijających się dziedzin działalności gospodarczej. Jeśli zagapisz się przez rok w innym kierunku, to właściwie nie masz szans wrócić w to samo środowisko — inne narzędzia, inne techniki, inne wymagania. Do spółki z wciąż szaleńczo galopującym rozwojem sprzętu tworzy to sytuację, w której tzw. „przeciętni ludzie” mimo, że mają coraz więcej powodów do korzystania z komputerów, rozumieją je coraz mniej. Nie potrafią powiedzieć jak to działa ani jak powstał program, który widzą „tam w środku”. A to są idealne wręcz warunki do rozwoju kilku zawodów i pojawiania się profesjonalistów — tam, gdzie szaleją demony, potrzebni są szamani, magicy i specjaliści wszelkiej maści.

Nie całuję nigdy w usta (aka: Kryzys wartości - wstęp)

Kod programów pisanych zawodowo (w sensie: przez profesjonalistów w celach zarobkowych) jest nader często pisany na szybko, źle zaprojektowany, pełen nieprzemyślanych fragmentów i łat, skomentowany słabo lub wcale, brzydki jak nieszczęście, a nawet zaskakująco nieprofesjonalny.

i co? i ... so

System zarządzania jakością — potężne narzędzie, bez którego trudno sobie wyobrazić utrzymanie w ryzach czegoś tak złożonego jak projekt informatyczny. Istnienie firmy zajmującej się tworzeniem wielu projektów bez takiego systemu wydaje się w ogóle nie poważne.

niewiele się zmienia przez lata

Wygrzebałem dzisiaj spod stosu papierów prawie nie używany firmowy kalendarz na rok 2002. Otworzyłem gdzieś w okolicach początku kwietnia i między sobotą a niedzielą naszkicowałem kilka tabelek mających stanowić protezę projektu do zadania, którym właśnie obarczałem kolegę. Krótka rozmowa i ten rysunek wystarczy.

Czyj to plan?

Przedsięwzięcie programistyczne, tak jak każdy inny przejaw zorganizowanej działalności zespołowej, nie może się obyć bez konkretnego planu działania. To z pozoru banał. Jednak wniknięcie w szczegóły powstawania planów lub harmonogramów na typowym grzęzawisku ujawnia znacznie mniej oczywiste zależności i konsekwencje.

this is weird

Cytat, który może być pomocny w nabraniu dystansu...

smutna prawda numer jeden

„Trudno powiedzieć, kto jest większym kretynem - klient, który to wymyślił czy my, którzy się na to zgadzamy...” — takim filozoficznym przemyśleniem poczęstował nas dzisiaj kolega ślęczący nad Dziwną Funkcjonalnością. I zrobił to nie jedyny, nie po raz pierwszy i nie ostatni.

engineering?

Pytanie o zasadność słowa engineering w wyrażeniu software engineering nie jest bynajmniej nowe ani dziwne. Jest wręcz uzasadnione, a uzasadnione pytania tego kalibru zawsze są kłopotliwe. Jeśli nie niebezpieczne...

survival test

Mierzenie jakości procesu produkcji oprogramowania jest chyba bardziej skomplikowane niż w przypadku jakiegokolwiek innego przedsięwzięcia. Istnieją na ten temat spore opracowania i rozbudowane techniki (które zawsze wymagają produkowania ogromnych stosów dokumentacji, dobrze jeśli niekoniecznie papierowej), ale istnieją też szybkie testy pozwalające zorientować się mniej więcej jak głęboko stoimy. Może zbyt to przypomina "testy psychologiczne" z gazet dla nastolatek, ale w gruncie rzeczy nie jest takie całkiem głupie...

kiedy byłem małym chłopcem, hej

Kiedy już wiedziałem, że chcę zawodowo pisać programy, że chcę być programistą, tak naprawdę nie wiedziałem i nie rozumiałem nic. Przez większość "szkolnej młodości" pisałem programy najróżniejsze, małe, średnie i "całkiem spore", na platformy wszelkie jakie się w tym czasie przewinęły przez scenę i moje łapy (począwszy od Atari 65XE, bo ZX Spectrum nie ma co wspominać). To hobby dało mi to pewne pojęcie o tym jak to się robi i chyba ogromnie ułatwiło życie na studiach. Wydawało mi się wtedy, że zawodowe tworzenie oprogramowania to podobna zabawa plus dodatkowo ktoś ci za to płaci — decyzja o wyborze zawodu była prosta. Zbyt prosta.

dwa cytaty tytułem wstępu

Smoliste grzęzawisko cytowałem już kiedyś lecz przytaczam i tutaj jako wyjaśnienie dla słabo kojarzących. Zresztą zapewne powtórzę to jeszcze nie raz, bo to tekst z gatunku ideologicznych...