Rynek IT przeżywa swój rozkwit już od kilku lat.

Jak myślicie, czy wykorzystujemy zawsze i w pełni podstawy teoretyczne a może korzenie matematyczne samej informatyki odeszły w zapomnienie i liczy się teraz aby było "szybko i tanio" ?

Marzę o świecie, w którym płaci się za dobrą złożoność algorytmu, wysoką jakość kodu i inwestuje się w szybki rozwój nowych gałęzi Computer Science, takich jak Distributed Data Mining, Sieci Neuronowe, Sztuczna Inteligencja, Idealny kompilator itp.

Drugie pytanie brzmi: jak widzicie najbliższe 10 lat na tym rynku?

Krzysztof Andrzej Parjaszewski:
Marzę o świecie, w którym płaci się za dobrą złożoność algorytmu, wysoką jakość kodu i inwestuje się w szybki rozwój

Widać, że Googlizarka to nie tylko moc tysięcy serwerów, ale też starannie zrealizowany kod i dobrze przemyślany algorytm. ALe tu konkretów nie umiem podać.

Mam za to kilka własnych przykładów, że warto tworzyc dobre algorytmy.
Kiedyś kolega wygłosił referat o pewnym algorytmie optymalizacji, który mną tak wstrząsnął, że w kilka miesięcy później postanowiłem wypróbować swój nowy komputer na nim właśnie. Implementowałem z pamięci odtwarzając algorytm. Okazało się, że w tym czasie kolega przygotowywał artykuł o tym do czasopisma i przypadkowo zaczął mi się żalić, że nie może liczyć większych instacji problemu niż 100. A ja mu na to, że właśnie przed wyjściem z pracy mój komputer policzył dla tysiąca. Postanowiliśmy porównać wyniki i programy. Okazało się, że źle zapamiętałem algorytm kolegi i liczyłem od drugiego końca. To jednak spowodowało, że mój algorytm miał złożoność O(n^2) gdy jego typową dla algorytmów programowania dynamicznego O(n^3). Opublikowaliśmy więc obydwa algorytmy razem: http://www.math.utah.edu/pub/tex/bib/infoproc1980.html...
Pytanie czy komuś na świecie przydają się nasze algorytmy?
Za to pod tym względem mogę być dumny z moich algorytmów naboru do szkół http://cepis-upgrade.com/issues/2005/6/up6-6Upenet.pdf str 10-13. Horror naboru do liceów 2002 roku nie powtórzył się w Poznaniu w 2003, bo już we wrześniu biegałem z tym algorytmem zaprogramowanym na notebooku wśród urzędników. Potem firma PCSS udostępniła system kilkunastu innym miastom.

Tyle, że problem na tyle łatwy, pokrewny sortowaniu, że możnaby kandydatów z całej Polski przetworzyć na jednym serwerze w parę minut.

nowych gałęzi Computer Science, takich jak Distributed Data Mining, Sieci Neuronowe, Sztuczna Inteligencja, Idealny kompilator

Te akurat dziedziny od lat nie zmieniają statusu dobrze rokujących i bliższe są s-f.

Krzysztof Andrzej Parjaszewski:
Rynek IT przeżywa swój rozkwit już od kilku lat.

Jak myślicie, czy wykorzystujemy zawsze i w pełni podstawy teoretyczne a może korzenie matematyczne samej informatyki odeszły w zapomnienie i liczy się teraz aby było "szybko i tanio" ?

IT w Businessie to tylko narzedzie do osiagniecia jakiegos celu a nie wartosc sama w sobie. Stad tez nie ma co marzyc o wielkich wyzwaniach teoretycznych bo kto mialby za to zaplacic. Jesli klient chce "szybko i tanio" to to wlasnie dostanie, jesli bedzie potrzebowal softu decydujacego o powodzeniu np. misji kosmicznej to pewnie szybko i tanio nie bedzie.
Moze jakims wyjsciem bylaby praca naukowa na uczelni...

Co to wogóle znaczy "szybko i tanio"? Każda procedura musi trwać określony czas. Prace można przyspieszyć tylko i wyłącznie ćwicząc umysł, rozwijające się, standaryzując procedury, wykorzystując "dobre praktyki" i wspólnie wypracowane przez pracowników firmy procedury. To wszystko jednak nie ma związku z "taniością".

ad.1. Myślę, że w dziedzinach takich jak obróbka i składowanie danych , transmisja danych, kryptografia - tam się płaci za dobry, optymalny kod i inwestuje w badania nad teorią i algorytmami (przykład, chociażby: http://research.microsoft.com/theory/ ).

ad.2 Nie jestem wróżką :) Jak pomyślę, że 10 lat temu to Pentium 90Mhz było demonem szybkości... to tym bardziej nie wiem :).Maciej L. edytował(a) ten post dnia 08.08.08 o godzinie 11:43

Dariusz Macina:
IT w Businessie to tylko narzedzie do osiagniecia jakiegos celu a
nie wartosc sama w sobie.

Polemizowałbym. IT w biznesie z jednej strony służy do osiągania celów, z drugiej zaś generuje je kreatywnie.

Podam prosty przykład:
Firma o ugruntowanej pozycji na rynku, ceniona wśród klientów,zakłada Intranet. Okazuje się, że wdrożenie systemu przyspieszyło realizację projektów i usprawniło komunikację na tyle, że czas wykonywania zadań uległ znacznej redukcji.
Wdrożenie Intranetu wygenerowało cel - zdobycie większej liczby zleceń i klientów. System informatyczny sprawdził się więc firma może iść dalej tą drogą. Może wdrożyć Ekstranet dla obecnych i potencjalnych klientów.

W ten sposób wpłynie na usprawnienie komunikacji z otoczeniem firmowym. Umiejętne zarządzanie Ekstranetem może przynieść skutki podobne do marketingu szeptanego - wzmocnienie reputacji firmy i zwiększenie sprzedaży.

Tego typu przykładów można podać jeszcze wiele. W szeroko rozumianym IT drzemie potencjał nieograniczonej liczby rozwiązań biznesowych. Trzeba je tylko umiejętnie wykorzystać;-)Grzegorz Skuza edytował(a) ten post dnia 08.08.08 o godzinie 12:03

Grzegorz Skuza:

Dariusz Macina:
IT w Businessie to tylko narzedzie do osiagniecia jakiegos celu a nie wartosc sama w sobie.

Polemizowałbym. IT w biznesie z jednej strony służy do osiągania celów, z drugiej zaś generuje je kreatywnie.
Podam prosty przykład:

Wydaje mi się, że tylko potwierdziłeś powyższą tezę :)
IT dla samego IT by nie istniało. Jeżeli firma wymieniona przez Ciebie wdraża internet to z pewnością jednym z celów jest poprawa komunikacji, usprawnienie obsługi, etc. Wątpię aby podłączyła się do sieci dla samego podłączenia :)

Osobiście niestety zbyt często widzę, że twórcy systemów IT są dumni ze swojego dzieła, które w praktyce jednak jest na tyle niedopracowane (np. słaba ergonomia interfejsu), że nie tylko nie wspiera użytkownika w jego działaniu, lecz wręcz utrudnia życie.
A przecież alternatywą dla tworzonego oprogramowania nie jest jego kolejna wersja, lecz inny sposób wykonania tego samego zadania np. zupełnie bez użycia komputera.
Odnoszę wrażenie, że IT zakłada, iż użytkownicy nie mają wyboru i muszą korzystać z IT, a przecież to nie jest prawdą.
Wartością dodaną IT jest ułatwienie dostępu do informacji, a nie jego utrudnianie.

Wojciech Kmiecik:
Osobiście niestety zbyt często widzę, że twórcy systemów IT są dumni ze swojego dzieła, które w praktyce jednak jest na tyle niedopracowane (np. słaba ergonomia interfejsu), że nie tylko nie wspiera użytkownika w jego działaniu, lecz wręcz utrudnia życie.

Zwykle zwiększenie pracochłonności przy takowym tworze (mówię tu o jego używaniu) jest wynikiem analizy (tę najczęściaj dostarcza, a zawsze akceptuje przed wykonaniem - klient). Ergonomia w lwiej części zalezy od założeń/wymagań analitycznych.

Błędy programowe najczęściej są wynikiem tworzenia produktu tanimi zasobami nie posiadającymi wystarczającego warsztatu, oraz oszczędnościami na testach (straszny błąd), lub też założeniem że produkt przetestuje docelowy klient podczas wdrożenia (poprostu herezja).
Jeżeli ktoś nie ma pojęcia o produkcji softu nie powinien brać udziału w procesach jego tworzenia - od założeń architektonicznych i analizy począwszy na testach i wdrożeniu kończąc.Krzysztof T. edytował(a) ten post dnia 11.08.08 o godzinie 16:54

Krzysztof Torenc:

Wojciech Kmiecik:
Osobiście niestety zbyt często widzę, że twórcy systemów IT są dumni ze swojego dzieła, które w praktyce jednak jest na tyle niedopracowane (np. słaba ergonomia interfejsu), że nie tylko nie wspiera użytkownika w jego działaniu, lecz wręcz utrudnia życie.

Zwykle zwiększenie pracochłonności przy takowym tworze (mówię tu o jego używaniu) jest wynikiem analizy (tę najczęściaj dostarcza, a zawsze akceptuje przed wykonaniem - klient). Ergonomia w lwiej części zalezy od założeń/wymagań analitycznych.

Dlatego coraz czesciej stosuje sie metodyki zwinne (MSF for Agile, Scrum) do prowadzenia projektow, oraz czesto firmy w Europie kupuja programistow na godziny... wykonanie zadania XYZ i Adios amigos do nastepnego zadania.

Błędy programowe najczęściej są wynikiem tworzenia produktu tanimi zasobami nie posiadającymi wystarczającego warsztatu, oraz oszczędnościami na testach (straszny błąd), lub też założeniem że produkt przetestuje docelowy klient podczas wdrożenia (poprostu herezja).

Tu wychodzi brak doswiadczenia i podejscie hybrydowe (bo "tanio"). Metodyka twarda do zdefiniowania problemu a potem lecimy metodyka miekka z ta roznica ze zakladamy jedna iteracje :-)

Jeżeli ktoś nie ma pojęcia o produkcji softu nie powinien brać
udziału w procesach jego tworzenia - od założeń architektonicznych i analizy począwszy na testach i wdrożeniu
kończąc

Alez powinien i to jak najbardziej, ale pod okiem i przewodnictwem doswiadczonych osob.

Rafał Ziółkowski:

Krzysztof Torenc:

Wojciech Kmiecik:
Osobiście niestety zbyt często widzę, że twórcy systemów IT są dumni ze swojego dzieła, które w praktyce jednak jest na tyle niedopracowane (np. słaba ergonomia interfejsu), że nie tylko nie wspiera użytkownika w jego działaniu, lecz wręcz utrudnia życie.

Zwykle zwiększenie pracochłonności przy takowym tworze (mówię tu o jego używaniu) jest wynikiem analizy (tę najczęściaj dostarcza, a zawsze akceptuje przed wykonaniem - klient). Ergonomia w lwiej części zalezy od założeń/wymagań analitycznych.

Dlatego coraz czesciej stosuje sie metodyki zwinne (MSF for Agile, Scrum) do prowadzenia projektow, oraz czesto firmy w Europie kupuja programistow na godziny... wykonanie zadania XYZ i Adios amigos do nastepnego zadania.

właśnie dlatego mam chleb z masełkiem obłożony szynką :))))
To system który opłaca się obu stronom.

Błędy programowe najczęściej są wynikiem tworzenia produktu tanimi zasobami nie posiadającymi wystarczającego warsztatu, oraz oszczędnościami na testach (straszny błąd), lub też założeniem że produkt przetestuje docelowy klient podczas wdrożenia (poprostu herezja).

Tu wychodzi brak doswiadczenia i podejscie hybrydowe (bo "tanio"). Metodyka twarda do zdefiniowania problemu a potem lecimy metodyka miekka z ta roznica ze zakladamy jedna iteracje :-)

nie mniej jednak mimo swych potężnych wad jest to z luboścją stosowane zwłasza w małych firmach. (co automatycznie sprawia, że takowa firma nigdy większą nie będzie...)

Jeżeli ktoś nie ma pojęcia o produkcji softu nie powinien brać
udziału w procesach jego tworzenia - od założeń architektonicznych i analizy począwszy na testach i wdrożeniu
kończąc

Alez powinien i to jak najbardziej, ale pod okiem i przewodnictwem doswiadczonych osob.

no tu podważyłeś - koleżko sympatyczny - moje zdanie, jednak jestem skłonny przyznać ci rację. TAK, przy założeniach jakie dodałeś - masz rację !!!. ;)))))))Krzysztof Torenc edytował(a) ten post dnia 26.08.08 o godzinie 21:38