On 4 Lut, 20:50, A.L. <l...@a...com> wrote:
> On Fri, 04 Feb 2011 19:43:56 +0100, "R. P." <r...@w...pl>
> wrote:
>
>
>
>
>
>
>
>
>
> >W dniu 2011-02-04 19:08, A.L. pisze:
> >> On Fri, 4 Feb 2011 09:30:42 -0800 (PST), Andrzej Jarzabek
> >> <a...@g...com>  wrote:
>
> >>> On Feb 4, 5:24 pm, A.L.<l...@a...com>  wrote:
> >>>> On Fri, 4 Feb 2011 08:56:44 -0800 (PST), Andrzej Jarzabek
>
> >>>> <a...@g...com>  wrote:
> >>>>> On Feb 4, 4:37 pm, A.L.<l...@a...com>  wrote:
>
> >>>>>>http://www.pbm.com/~lindahl/real.programmers.h
tml
>
> >>>>> Ten tekst jest sooo last century...
>
> >>>> Owszem. Ale "message" jest aktualny i dzis.. technologia tylko deko
> >>>> inna...
>
> >>> Mimo wszystko zabawnie się czyta o tym, że "back in the good old days"
> >>> cośtam cośtam, a teraz są Emacs i Vi, UUCP-net, CP/M, a dzieciaki
> >>> grają na automatach w Pac-mana i Asteroids.
>
> >> Gorzej ze Emacs, vi, Unix, C itede w dalszym ciagu sa traktowane jako
> >> "rewolucyjna technologia"
>
> >Z tym pelna zgoda.
>
> >> A zupelnie zle ze metodologia budowy oprogramowania zupelnie, ale to
> >> zupelnie nei zmienila sie od tamtego czasu
>
> >Jak to? A to z tymi wszystkimi nowymi wynalazkami typu agile, scrum,
> >extreme programming etc.?
>
> To jest tak jak z przemowieniem Gomulki: "Towarzysze, dwa lata temu
> Polska stala na skraju przepasci. Od tego czasu wykonalismy wielki
> krok naprzod"/
>
> Agile, extreme programming itede to naukowe uzasdnienie badziewia,
> bezmyslnosci, nieuctwa, bulejakosci i paradygmatu "code first think
> later. If ever"
>
> A.L.

W programowaniu, w przeciwieństwie do budowy mostów, często nie wiesz
na początku jak będzie wyglądał system na końcu.

Nie jestem zwolennikiem robienia szopek wokół lekkich metodologii
(zwłaszcza, że one nie są "srebrnymi kulami" - dowód: jest ich tyle
różnych rodzajów; skoro jest ich tyle, to najwyraźniej żadna nie
działa :D). Niemniej jednak te bardziej "lekkie" metodologie mają
jedną mocną zaletę: stosunkowo ciasne sprzężenie zwrotne. Tutaj należy
się mała powtórka z teorii sterowania. Jedyny sposób, żeby sterować
układem, który nie ma sprzężenia zwrotnego to mieć o nim pełną wiedzę.
W przeciwnym wypadku, taki układ jest niesterowalny. Sprzężenie
zwrotne pozwala nam sterować systemami, o których nie mamy pełnej
wiedzy. Ponieważ o przebiegu projektów programistycznych nigdy nie
mamy pełnej wiedzy, używanie metod nie zawierających sprzężenia
zwrotnego jest... dziwne? Nierozsądne?