On 09/05/2014 20:15, Andrzej Jarzabek wrote:

> Trochę się tu rozbijamy o kwestię definicji - według niektórych
> tworzenie produktów software'owych to jest R&D. Dalej to już dzielenie
> włosa na czworo: czy jeśli w kraju A(meryka) researcher wymyśla, co ma
> robić program, a w kraju B(olanda) developerzy piszą kod, ale również
> ktoś w kraju B rozmawia z researcherem i ustala szczegóły działania
> programu, to czy w kraju B odbywa się już R&D, czy jeszcze "samo pisanie
> kodu"? Czy jeśli część pracy przy projekcie R&D odbywa się w A, a część
> w B, to czy można powiedzieć, że firma robi R&D w B?
>


Najblizej do R&D w Polsce zblizyl sie chyba ktorys bank ktory przenosi
"model validation" do Krakowa. Oferuja niezle warunki jak na Polske (ok.
300 tys. zl. dla quanta). Ale "model validation" w bankach to na ogol
bardzo malo innowacji (jesli w ogole), innowacja jest w front office.

RW

do góry

On 10/05/2014 07:15, Adam Klobukowski wrote:

> Co do bankowego backoffice (który i tak jeszcze dzieli się na front i back), to
tego się nie tłumaczy (z wyjąckiem islamic banking, ale to inna para kaloszy). Więc
tłumaczenia odpadają.

CS nigdy nie przeniesie swojego front office do Polski, chyba ze zostana
wykupienie przez Pekao S.A.

RW

do góry

On 09/05/2014 08:52, Adam Klobukowski wrote:

> Tworzenie oprogramowania to nie 'samo pisanie kodu'. Bank wielkości CS ma co
najmniej kilka dużych systemów po kilka-naście milionów linii kodu. Jest nad czym
pracować.

99% tego kodu w CS nie zawiera nic innowacyjnego w porownaniu z kodem z,
dajmy na to, Unicredit czy Barclays. A ten 1% ktory jest faktycznie
efektem jakiegos "researchu" nie powstaje w Europie Wschodniej, tylko w
Londynie ew. Paryzu czy Zurichu.

Been there, done that.

RW

do góry

On 02/05/2014 15:09, A.L. wrote:
> Mam taka sama opinie. Styl jest nei najlepszy.
>
> A.L.
>

W szczegolnosci, padaja w tym wywiadzie nieprawdziwe stwierdzenia (ze
Polska staje sie jakims centrum informatycznego researchu - to
nieprawda) i kuriozalna, tracaca rasizmem opinia ze "można podejrzewać,
że mamy genetyczne predyspozycje".

RW

do góry

On Sat, 10 May 2014 11:22:43 +0100, Roman W
<b...@g...pl> wrote:
> gdzie sa te jezyki programowania ktore powstaly w Polsce? W UK
powstal

Prolog. Ale to dawno i nie sami. Pomijam np. Warsaw Basic itp.

Mizar, ale to też dawno.

do góry

On Sat, 10 May 2014 11:24:56 +0100, Roman W
<b...@g...pl> wrote:
> nieprawda) i kuriozalna, tracaca rasizmem opinia ze "można
podejrzewać,
> że mamy genetyczne predyspozycje".

Rasizm, paternalizm, nacjonalizm i nadużycie liczby mnogiej. A przy
tym FUD i kłamstwo. W jednym krótkim zdaniu.

do góry

Szarym od mżawki świtem Fri, 09 May 2014 11:26:03 -0700, Adam Klobukowski
wyrzucił pustą ćwiartkę i oznajmił:

> On Friday, 9 May 2014 19:30:05 UTC+2, Edek wrote:
>> Szarym od mżawki świtem Fri, 09 May 2014 00:52:57 -0700, Adam
>> Klobukowski
>>
>> wyrzucił pustą ćwiartkę i oznajmił:
>>
>> > On Friday, 9 May 2014 09:25:01 UTC+2, Roman W wrote:
>> >> On Fri, 09 May 2014 08:11:12 +0100, Andrzej Jarzabek
>> >>
>> >> <a...@g...com> wrote:
>> >> > > A co CS przeniosło do Polski? Backoffice? Model validation? To
>>
>> >> nie jest
>> >> > > R&D.
>> >>
>> >> > M.in. jest tworzone oprogramowanie, jeśli o to ci chodziło.
>> >>
>> >> Samo pisanie kodu to nie R&D.
>> >>
>> >> RW
>>
>> > Tworzenie oprogramowania to nie 'samo pisanie kodu'. Bank wielkości CS
>> > ma co najmniej kilka dużych systemów po kilka-naście milionów linii
>> > kodu. Jest nad czym pracować.
>>
>> Projektowanie rozwiązań, uzgadnianie specyfikacji, testowanie,
>> wymyślanie ulepszeń procesów tychże ciągle nie jest R&D. Uruchomienie
>> JIRA czy innego narzędzia też nie. Doskonalenie zarządzania kontrolą
>> wersji w celu dobrych releasów też nie. Metodologia Agile też nie.
>> Ani nie jest R&D napisanie tysiąca algorytmów rozwiązujących tysiąc
>> problemików, z czego 935 jest banalnych i wystarczy napisać je
>> poprawnie, 60 zaimplementuje się używając znalezionego w sieci
>> rozwiązania, a ostatnie 5 trafia najczęściej do kilku bardziej sprawnych
>> intelektualnie gości. Chyba że tych 60 reszta też nie potrafi znaleźć,
>> wtedy muszą się spytać.
>
> Wyobrażasz to sobie w bardzo małej skali. Przemnóż sobie złożoność tego
> przez 1000, a wtedy będziesz wiedział jaka jest skala systemów IT w dużym
> banku. To jest R&D.

Obawiam się, że jesteś zachłyśnięty rozmiarem. Za jakiś czas powinno przejść.
A pod względem złożoności akurat są bardziej skomplikowane systemy niż
bankowe, chociaż linii kodu mogą mieć o rząd czy dwa wielkości mniej. Jedne
pod względem złożoności logiki, drugie pod względem złożoności teorii jakie
za nimi stoją. Bankowe mogą mieć kilka takich elementów i muszą być dobrze
zaprojektowane, ale to wszystko. Jeżeli całość nazywa się R&D to tylko ze
względów podatkowych i PR.

--
Edek

do góry

On Saturday, 10 May 2014 15:12:54 UTC+2, Edek wrote:
> Szarym od mżawki świtem Fri, 09 May 2014 11:26:03 -0700, Adam Klobukowski
>
> wyrzucił pustą ćwiartkę i oznajmił:
>
> > On Friday, 9 May 2014 19:30:05 UTC+2, Edek wrote:
>
> >> Szarym od mżawki świtem Fri, 09 May 2014 00:52:57 -0700, Adam
> >> Klobukowski
>
> >> wyrzucił pustą ćwiartkę i oznajmił:
> >> > On Friday, 9 May 2014 09:25:01 UTC+2, Roman W wrote:
> >> >> On Fri, 09 May 2014 08:11:12 +0100, Andrzej Jarzabek
> >> >> <a...@g...com> wrote:
> >> >> > > A co CS przeniosło do Polski? Backoffice? Model validation? To
> >>
> >> >> nie jest
> >> >> > > R&D.
> >> >>
> >> >> > M.in. jest tworzone oprogramowanie, jeśli o to ci chodziło.
> >> >>
> >> >> Samo pisanie kodu to nie R&D.
> >> >>
> >> >> RW
> >>
> >> > Tworzenie oprogramowania to nie 'samo pisanie kodu'. Bank wielkości CS
> >> > ma co najmniej kilka dużych systemów po kilka-naście milionów linii
> >> > kodu. Jest nad czym pracować.
> >>
> >> Projektowanie rozwiązań, uzgadnianie specyfikacji, testowanie,
> >> wymyślanie ulepszeń procesów tychże ciągle nie jest R&D. Uruchomienie
> >> JIRA czy innego narzędzia też nie. Doskonalenie zarządzania kontrolą
> >> wersji w celu dobrych releasów też nie. Metodologia Agile też nie.
> >> Ani nie jest R&D napisanie tysiąca algorytmów rozwiązujących tysiąc
> >> problemików, z czego 935 jest banalnych i wystarczy napisać je
> >> poprawnie, 60 zaimplementuje się używając znalezionego w sieci
> >> rozwiązania, a ostatnie 5 trafia najczęściej do kilku bardziej sprawnych
> >> intelektualnie gości. Chyba że tych 60 reszta też nie potrafi znaleźć,
> >> wtedy muszą się spytać.
> >
> > Wyobrażasz to sobie w bardzo małej skali. Przemnóż sobie złożoność tego
> > przez 1000, a wtedy będziesz wiedział jaka jest skala systemów IT w dużym
> > banku. To jest R&D.
>
> Obawiam się, że jesteś zachłyśnięty rozmiarem. Za jakiś czas powinno przejść.
> A pod względem złożoności akurat są bardziej skomplikowane systemy niż
> bankowe, chociaż linii kodu mogą mieć o rząd czy dwa wielkości mniej. Jedne
> pod względem złożoności logiki, drugie pod względem złożoności teorii jakie
> za nimi stoją. Bankowe mogą mieć kilka takich elementów i muszą być dobrze
> zaprojektowane, ale to wszystko. Jeżeli całość nazywa się R&D to tylko ze
> względów podatkowych i PR.

Oczywiście że istnieją sytemy o wiele bardziej skomplikowane, jednak obawiam się że
nie jestem zachłyśnięty.

W Polsce tworzy się nowe i rozwija wiele produktów IT, także dla banków. To jest
właśnie R&D.

AdamK

do góry

On Saturday, 10 May 2014 12:24:26 UTC+2, Roman W wrote:
> On 09/05/2014 08:52, Adam Klobukowski wrote:
>
> > Tworzenie oprogramowania to nie 'samo pisanie kodu'. Bank wielko�ci CS ma co
najmniej kilka du�ych system�w po kilka-na�cie milion�w linii kodu. Jest nad
czym pracowaďż˝.
>
> 99% tego kodu w CS nie zawiera nic innowacyjnego w porownaniu z kodem z,
> dajmy na to, Unicredit czy Barclays. A ten 1% ktory jest faktycznie
> efektem jakiegos "researchu" nie powstaje w Europie Wschodniej, tylko w
> Londynie ew. Paryzu czy Zurichu.

Tylko widzisz, Unicredit czy Barclays nie dzielą się kodem, i to że coś wymyślono i
zrobiono w jednym, to nagle łatwiej się robi w drugim.

AdamK

do góry

On Sat, 10 May 2014 06:38:07 -0700 (PDT), Adam Klobukowski
<a...@g...com> wrote:
> Tylko widzisz, Unicredit czy Barclays nie dzielą się kodem, i to że
c=
> oś wymyślono i zrobiono w jednym, to nagle łatwiej się robi w drugi=
> m.

Ale ich pracownicy przechodzą z jednego banku do drugiego i wynoszą
pomysły.

RW

do góry