Tak jakby wymagało to metodycznej analizy:

http://arstechnica.com/business/news/2011/12/bad-cod
e-plagues-it-applications-especially-java-ones.ars

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?

Edek

do góry

On Dec 10, 9:20 am, Edek <e...@g...com> wrote:
> Tak jakby wymagało to metodycznej analizy:
>
> http://arstechnica.com/business/news/2011/12/bad-cod
e-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?

Takie porownania sa bez sensu. Nie uwzgledniaja roznych zastosowan
(biblioteka numeryczna w C++ nie bedzie miala problemow z security, bo
jedynie przezuwa i wypluwa liczby), nie uwzgledniaja tego, ze czas
pracy roznych programistow ma rozna wartosc (podejrzewam, ze specow od
Cobola jest juz tak malo, ze beda chcieli wiecej niz $75/h).

RW

do góry

On 10/12/2011 10:34, Roman W wrote:
> On Dec 10, 9:20 am, Edek<e...@g...com> wrote:
>> Tak jakby wymagało to metodycznej analizy:
>>
>> http://arstechnica.com/business/news/2011/12/bad-cod
e-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?
>
> Takie porownania sa bez sensu. Nie uwzgledniaja roznych zastosowan
> (biblioteka numeryczna w C++ nie bedzie miala problemow z security, bo
> jedynie przezuwa i wypluwa liczby), nie uwzgledniaja tego, ze czas
> pracy roznych programistow ma rozna wartosc (podejrzewam, ze specow od
> Cobola jest juz tak malo, ze beda chcieli wiecej niz $75/h).

Samego raportu nie widziałem, bo po pierwsze trzeba się rejestrować, a
po drugie pewnie i tak TL;DR, ale należałoby stwierdzić, czy korygują te
dane względem tego co piszesz, jak i też innych rzeczy.

Choćby doświadczenie programisty: na pewno nawet w obrębie tego samego
języka programista z 2-letnim doświadczeniem i programista z 30-letnim
doświadczeniem będą popełniali błędy z różną częstotliwością, a jeśli
porównamy rozkłady i zobaczymy jaki odsetek programistów dla Javy i
Cobola ma mnie lub więcej niż dwa, pięć, dziesięć czy trydzieści lat
doświadczenia, to... no właśnie.

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.

Ktoś może podrzucić linka, gdzie można będzie ściągnąć raport bez
rejestracji?

do góry

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.

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.

RW

do góry

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.

> 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.

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ń.
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, 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ę?

do góry

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-applications-especially-java-ones.ars
>
>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

A.L.

do góry

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.

do góry

W dniu 2011-12-10 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ć,

Jeszcze nikomu to nie zaszkodziło;)

> 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?

pzdr
bartekltg

do góry

On Sat, 10 Dec 2011 17:24:49 +0000, 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.

Drogi Kolego, ja juz keidys Kolege pytalem czy Kolega to student czy
hobbysta. Bo na zawodowca to Kolega mi nei wyglada...

A.L.

do góry

On 10/12/2011 17:46, A.L. wrote:
>
> Drogi Kolego, ja juz keidys Kolege pytalem czy Kolega to student czy
> hobbysta. Bo na zawodowca to Kolega mi nei wyglada...

Czy to nie Kolega przypadkiem miał zasadę wrzucania do killfajla za
dyskutowanie na temat swojej skromnej osoby?

do góry