On 10/12/2011 17:41, bartekltg wrote:
> W dniu 2011-12-10 18:24, Andrzej Jarzabek pisze:
>>
>> Lepiej najpierw pomyśleć, potem jeszcze pomyśleć,
>
> Jeszcze nikomu to nie zaszkodziło;)

Chyba że to myślenie było zamiast robienia.

>> mnóstwo papierków, w końcu napisać kod, którego połowa nie działa w
>> ogóle, a druga połowa robi nie to, co trzeba.
>
> Jak ta same ekipa bez myślenia z palca napisze ten kod, to
> będzie lepiej?

Ja na przykład mam zwyczaj myśleć również w trakcie pisania kodu - wręcz
inaczej nie potrafię. Jeśli ta ekipa ma zwyczaj pisać kod bez
jednoczesnego myślenia o tym, co robi, to obawiam się, że żadne myślenie
wcześniej ich nie uratuje.

do góry

W dniu 10.12.2011 r. 18:24, Andrzej Jarzabek pisze:
> On 10/12/2011 16:36, A.L. wrote:
>> On Sat, 10 Dec 2011 10:20:37 +0100, Edek<e...@g...com>
>> wrote:
>>
>> Agile: Code first think later. Rzeczywiscie, potrzeba jest matka
>> wynalazku.
>>
>> Wyzszy stopien Agile (Agiel advanced): Code first
>
> Lepiej najpierw pomyśleć, potem jeszcze pomyśleć, potem wyprodukować
> mnóstwo papierków, w końcu napisać kod, którego połowa nie działa w
> ogóle, a druga połowa robi nie to, co trzeba.
"Empirical studies of agile software development: A systematic review",
T. Dyba, T. Dings?yr

Abstract:
The search strategy identified 1996 studies, of which 36 were identified
as empirical studies.

"4.7.3. Product quality
Several aspects of product quality were examined by the
studies in this review. For example, comparing the results
for a new release of a project to those for an old release,
Layman et al. (S14) found a 65% improvement in pre-
release quality and a 35% improvement in post-release
quality. Ilieva et al. (S10) found 13% fewer defects reported
by the customer or by the quality assurance team in an XP
project than in a non-XP project.
In Wellington et al.'s (S32) study, the XP team's code
scored consistently better on the quality metrics used than
the traditional team. In addition, the quality of the code
delivered by the XP team was significantly greater than that
delivered by the traditional team. However, both teams
agreed that the traditional team had developed a better
and much more consistent user interface.
Macias et al. (S15) measured the internal and external
quality of the products developed by 10 XP teams and 10
traditional teams. However, in contrast to Layman et al.
and Wellington et al., they found no difference in either
internal or external quality between the XP teams and
the traditional teams.
With respect to product size, the XP model teams in
Dalcher et al.'s (S7) study delivered 3.5 times more lines
of code than the V-model teams. This is in sharp contrast
to Wellington et al.'s (S32) results, which showed that the
traditional team delivered 78% more lines of code than
the XP team. However, in contrast to both Dalcher et al.
and Wellington et al., Macias et al. (S15) found no differ-
ence in product size between the XP teams and the tradi-
tional teams."

Hmmm....

do góry

On 10/12/2011 18:06, n...@m...invalid wrote:
> W dniu 10.12.2011 r. 18:24, Andrzej Jarzabek pisze:
[...]
> "Empirical studies of agile software development: A systematic review",
[...]
> Hmmm....

Chodzi o to, że z tych "studies" niewiele wynika?

do góry

On Dec 10, 3:22 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 10/12/2011 12:54, Roman W wrote:
>
> > On Dec 10, 12:24 pm, Andrzej Jarzabek<a...@g...com>
> > wrote:
> >> Kolejna sprawa to wiek samego kodu - jeśli weźmiemy jakiś system bankowy
> >> napisany w czymkolwiek, który powstał w latach 70-tych czy 80-tych i co
> >> najmniej od 15 lat ma stabilne ficzery, a wysiłek idzie w dużej mierze w
> >> robienie go bardziej niezawodnym i bezpiecznym, to nie jest dziwne, że
> >> jest bardziej niezawodny czy bezpieczny niż system podobnej wielkości,
> >> który zaczął powstawać półtora roku temu. Będzie to raczej prawdą
> >> niezależnie od zastosowanych języków. I tak dalej i tak dalej.
>
> > Male szanse, zeby system bankowy napisany w latach 70-tych czy 80-tych
> > nie przeszedl od tej pory wielu zmian. Zmiany w regulacjach, nowe
> > produkty, itd.
>
> Jasne, ale wydaje mi się, że proporcje będą jednak inne.

Nie wiem. W tej czesci bankowosci w ktorej pracuje, wiekszosc kodu
jest dosc nowa.
W detalicznej moze byc oczywiscie inaczej, zwl. w krajach w ktorych
kapitalizm zaczal sie wczesniej niz w 89 roku.

>
> > Moje osobiste obserwacje z systemami uzywanymi w duzych bankach (na
> > przykladzie Murex) sa takie, ze one sie rozwijaja organicznie i nowe
> > funkcjonalnosci sa czesto wrecz dopychane kolanem. Nikt nie ma czasu
> > porzadkowac kodu, bo klienci (wewnetrzni badz zewnetrzni) naciskaja na
> > nowe produkty. Grupa rozwijajaca dany kawalek kodu musi miec spory
> > autorytet zeby przeforsowac decyzje "nie dodajemy nowych
> > funkcjonalnosci przez pare miesiecy tylko refaktoryzujemy" bez
> > spotkania sie z wielkim oporem. A programisci w bankach sa dobrze
> > platni, ale na ogol nie maja wielkiego autorytetu.
>
> Ja, przyznam też nie jestem fanem podejścia "parę miesięcy
> refaktoryzujemy", znaczy w banku nie pracowałem, ale tak w ogóle wydaje
> się mało praktyczne. Według mnie sensowniej refaktoryzację powiązać ze
> zmianami funkcjonalnymi.

Zalezy jak duzo w kodzie jest do poprawki. Dwa razy bralem udzial w
duzym wysilku porzadkowania kodu. Zwl. w pierwszym przypadku stan
wyjsciowy byl taki, ze ciezko bylo cokolwiek dodac.

Martin Fowler zdaje sie poleca rozdzielac zmiany funkcjonalne i
refaktoryzacje?

>
> Z drugiej strony pozwalanie na zapuszczanie kodu pod pretekstem
> oszczędności czasu to kompletne marnotrawstwo - potem doprowadza się do
> tego, że prosta zmiana czy bugfiz zamiast pół dnia zajmuje tydzień.

O tak tak.

> Niestety znam takie przykłady z autopsji, z czego wynika że nie tylko w
> bankach ten problem się pojawia. Może w bankach jest gorzej, bo jest
> presja na krótkie terminy,

Zalezy jaki projekt. Jak trader chce miec zbudowany arkusz Excela do
wyceny jakiejs pojedynczej egzotycznej opcji, to moze Ci rzucic
terminem "pol godziny" (literalnie kiedys mi powiedzieli "musimy miec
te cene w 15 minut, albo kontrakt przepada" - i cene dostali :)).
Natomiast cos, co ma byc uzywane do regularnego obliczania zyskow/
strat (tzw. P&L) ksiegi musi przejsc etap testowania, musi byc
udokumentowane, zaakceptowane przez middle office, itd. - wiec terminy
sa normalne. Banki stac na zatrudnianie dobrych programistow, wiec
odpada problem, ze kolega obok jest glabem i jego kod wnosi negatywna
wartosc do projektu. Takie rzeczy sie raczej b. rzadko zdarzaja.

> ale z mojego doświadczenia wynika, że to
> często jest wina nie tylko presji, ale samych programistów.
>
> A ten Murex to jak guglnąłem to jest robiony przez jakąś firmę, a nie
> przez programistów pracujących w banku, czy źle patrzę?

Tak, ale jego integracja w duzym banku to wielki projekt sam w sobie,
itez wymaga pisania sporo kodu.

RW

do góry

On Dec 10, 4:36 pm, A.L. <l...@a...com> wrote:
> On Sat, 10 Dec 2011 10:20:37 +0100, Edek <e...@g...com>
> wrote:
>
> >Tak jakby wymagało to metodycznej analizy:
>
> >http://arstechnica.com/business/news/2011/12/bad-co
de-plagues-it-appl...
>
> >Nie znam szczegółów, ciekawiłoby mnie przede wszystkim,
> >ile z tych projeków powstawało w trybie Agile: intuicyjnie
> >powiedziałbym, że w Javie najczęściej występuje Agile,
> >którego jednym z głównych założeń jest niwelowanie
> >"technical debt" - potrzeba matką wynalazku?
>
> Agile: Code first think later. Rzeczywiscie, potrzeba jest matka
> wynalazku.
>
> Wyzszy stopien Agile (Agiel advanced): Code first

:D

RW

do góry

On Dec 10, 5:24 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 10/12/2011 16:36, A.L. wrote:
>
> > On Sat, 10 Dec 2011 10:20:37 +0100, Edek<e...@g...com>
> > wrote:
>
> > Agile: Code first think later. Rzeczywiscie, potrzeba jest matka
> > wynalazku.
>
> > Wyzszy stopien Agile (Agiel advanced): Code first
>
> Lepiej najpierw pomyśleć, potem jeszcze pomyśleć, potem wyprodukować
> mnóstwo papierków, w końcu napisać kod, którego połowa nie działa w
> ogóle, a druga połowa robi nie to, co trzeba.

Ja lubie dokumentacje. Tylko nie lubie jej pisac.

RW

do góry

On 10/12/2011 18:32, Roman W wrote:
> On Dec 10, 3:22 pm, Andrzej Jarzabek<a...@g...com>
>>
>>> Male szanse, zeby system bankowy napisany w latach 70-tych czy 80-tych
>>> nie przeszedl od tej pory wielu zmian. Zmiany w regulacjach, nowe
>>> produkty, itd.
>>
>> Jasne, ale wydaje mi się, że proporcje będą jednak inne.
>
> Nie wiem. W tej czesci bankowosci w ktorej pracuje, wiekszosc kodu
> jest dosc nowa.
> W detalicznej moze byc oczywiscie inaczej, zwl. w krajach w ktorych
> kapitalizm zaczal sie wczesniej niz w 89 roku.

No więc te wszystkie bankowe systemy w COBOL-u to raczej głównie
bankowość detaliczna. Zresztą jeśli chodzi o bankowość detaliczną, to ja
słyszałem historie o technologiach, przy których COBOL jest jeszcze
całkiem sensownym językiem.

>> Ja, przyznam też nie jestem fanem podejścia "parę miesięcy
>> refaktoryzujemy", znaczy w banku nie pracowałem, ale tak w ogóle wydaje
>> się mało praktyczne. Według mnie sensowniej refaktoryzację powiązać ze
>> zmianami funkcjonalnymi.
>
> Zalezy jak duzo w kodzie jest do poprawki. Dwa razy bralem udzial w
> duzym wysilku porzadkowania kodu. Zwl. w pierwszym przypadku stan
> wyjsciowy byl taki, ze ciezko bylo cokolwiek dodac.
>
> Martin Fowler zdaje sie poleca rozdzielac zmiany funkcjonalne i
> refaktoryzacje?

Jak najbardziej, ale niekoniecznie przecież w skali miesięcy. Po to masz
właśnie inkrementalną technikę refaktoryzacji, żeby nie musieć się
zagrzebywać w jakichś wielomiesięcznych fazach, w których nie możesz
dodawać funkcjonalności.

do góry

On 10/12/2011 18:33, Roman W wrote:
>
> Ja lubie dokumentacje. Tylko nie lubie jej pisac.

Ja nieszczególnie lubię sytuację, kiedy:
a) jest dokumentacja, ale opisuje nie do końca to, jaki program
faktycznie jest,
b) programu nie da się doczytać, co on naprawdę robi,
c) program robi nie to, co trzeba.

do góry

W dniu 10.12.2011 r. 19:29, Andrzej Jarzabek pisze:
> On 10/12/2011 18:06, n...@m...invalid wrote:
>> W dniu 10.12.2011 r. 18:24, Andrzej Jarzabek pisze:
> [...]
>> "Empirical studies of agile software development: A systematic review",
> [...]
>> Hmmm....
>
> Chodzi o to, że z tych "studies" niewiele wynika?
Dokładnie. Choć, zauważmy, metodologia SD != język programowania.
Choć przeglądałem pobieżnie, to znalazłem potem, że większość tych badań
opiera się na formie ankietowania grup początkujących (lub studenckich).
Nie wiem, czy zdołano całkowicie wyeliminować czynniki wynikające z
płytkiej adopcji technik agile. Problem needs further research :P
W każdym razie wniosek nasuwa się, że XP są co najmniej nie gorsze niż
tradycyjne w kategorii quality. Zarzut jest do koherentności interfejsów
użytkownika takich programów.

do góry

On Dec 10, 7:20 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 10/12/2011 18:33, Roman W wrote:
> > Ja lubie dokumentacje. Tylko nie lubie jej pisac.
> Ja nieszczególnie lubię sytuację, kiedy:
> a) jest dokumentacja, ale opisuje nie do końca to, jaki program
> faktycznie jest,

Ja tam wole miec niekompletna dokumentacje + zrodla niz tylko zrodla.

RW

do góry