SoftWave

Popularity: 22% [?]

Termin cloud computing polako se potvrđuje kao jedan od značajnijih buzzworda u 2008, a jedan od njegovih najvažnijih aktera svakako je internetski gigant Amazon sa svojim Amazon Web Services, koji uključuju Web-based sustav za pohranu podataka, virtualne servere po narudžbi, bazu podataka i još ponešto.

Ukoliko vas zanima ovaj trend u razvoju računalstva — a kojeg ja osobno smatram vrlo uzbudljivim i obećavajućim — svakako se potrudite da 7. travnja u 17 sati budete u Novinarskom domu u Zagrebu, Perkovčeva 2. Udruga Initium tada i tamo organizira predavanje Mike Culvera, evangelista AWS-a, koji će govoriti o tim uslugama i demonstrirati njene prednosti.

Popularity: 21% [?]

Još prije nešto više od dvije godine komentirao sam post na jednom SitePointovom blogu, pod naslovom 10 Years of Java… for what? SitePoint mi od tada automatski šalje obavijesti o svim komentarima koji su postani nakon mog, i logično je da su se s vremenom ti komentari prorijedili i naposlijetku sasvim prestali.

Zato me je prilično iznenadio jučerašnji mail kojim sam obaviješten o novom komentaru, dodanom dakle pune dvije godine nakon diskusije. Obično takve komentare letimice pročitam i odmah obrišem mail, ali ovaj me je iznenadio prije svega svojom dužinom, ali i sadržajem, zbog čega ga prenosim u cijelosti i bez ikakvog komentara.

I samo ime kojim se potpisao autor komentara samo po sebi dosta govori: paul works with java everyday at work since ‘94

hi-

I have been working with j2ee in corp. shops in the usa (boston) since nineties. I agree wholeheartedly with the original poster.

It is possible to see j2ee corp apps that run fast, but the entire j2ee tech stack must be configured perfectly and every line of java code perfectly written. Never happens in practice, or very rarely.

Programmers that write in java are less productive because of all the framework configuration, discovery and learning curves, etc. that are needed to build the scalable applications they are tasked to create. I work on j2ee apps that scale, but badly - poor performance and low availability at high numbers of concurrent users.

RIA with applets is a no-go, and a j2ee programming team capable of RIA without applets in j2ee along the lines of the very impressive thinkfree office will not be easy to assemble. applets in general are a deadend and the incompatibilities are astounding on a WORA-billed platform.

The entire universe of j2ee accoutremont: maven, ant, hibernate, jrun, junit, jmeter, on and on… the xml configuration files, all of this adds complexity, and team members, and increases code and chances for misconfiguration and errors in deployment.

Performance of j2ee is much better in recent years, but in 2008, i still use s-l-o-w j2ee applications every single day. the author of the post is right: ten years with little to show for it.

j2ee means all to frequently: no firefox ’cause we can’t support it, no mac, no linux. so, j2ee in the corp world means windows and IE. Not very hackerish. Or cool. Or fast. And I love windows as much as the others. I’m knocking most corp j2ee app development in the us, certainly 95% of it in boston in 2008.

The j2ee web application servers, and servlet containers frequently have their own problems which delay deployments and crash sites, etc. Things like weblogic, tomcat. Sometime you work in a j2ee shop that has one piece of the j2ee chain that’s a little older and it holds things up during deployment, retards performance of the j2ee application, or causes a recurring availability issue.

Jboss and related and similar j2ee enabling and complementary technologies are developed by toolmakers and when added to all the frameworks out there (ICEfaces, millions more), before you know it you’re using tech from dozens of vendors and keeping track of the lifecycles and updates becomes unmangeable. How about five, ten years from now? Where are the j2ee apps then? Who maintains them?

j2ee programmers need to know so many j2ee technologies that they even the best ones lack experience across the entire spectrum of technologies and so they learn on the job. And that takes time, and makes projects using j2ee later. They have less time to learn about anything but j2ee, and they think (my personal observation of many of them) you don’t know anything about computers if you don’t know java. Many have no experience of anything before java.

I already said above, j2ee apps scale - mostly not that well. Again, in my personal experience.

The JRE is not great. It is the weak link in many j2ee apps. Frequently incompat. between different j2ee apps which need a diff. version.

I have never ever seen a j2ee dev team that did anything more than pay cursory lipservice to agile development methodology.

I have seen during the nineties ecommerce buildout many scaled perl and scripting language LAMP applications and sites that filled millions of orders, charged millions of dollars, served millions of pages. So I know they scaled, because I saw them. J2ee’s scalability, to my mind, is frustratingly unevident when judged against these personal recollections. Most of the j2ee applications i have worked on slow down the more people are using them, etc. This is based on my daily working life in many j2ee-only shops in boston. I work with it for a living, and j2ee has paid my bills and put food on my table. I’m just simply agreeing with the original poster’s comments.

j2ee UI’s and UI development (JSF, java server faces): ack. Swing, struts, AWT: it just never happened correctly. Every j2ee dev team i work on has poor UI. I know, I know, your experience is different. Mine has been - java, j2ee UI is usually bad. I’m working on a VUI dialog designer for work that is an applet that interfaces with a j2ee backend. The UI is good, almost very good. I mentioned thinkfree office above. But almost all j2ee apps have poor UI and interface. In ten years, j2ee UI will be one of the main complaints about j2ee in hindsight, along with bloat, complexity, gross overuse, inappropriateness for a wide variety of programming problems, perfomance. Java is still too slow too often in 2008.

Gotta go work with more j2ee tomorrow at work, so I have to go. Just kidding about java and j2ee. It’s great.

Popularity: 25% [?]

Nakon što jako dugo nije bilo programerskih tema, danas sam naletio na site kojem ću se često vraćati kad se želim nasmijati ili se jednostavno podsjetiti što znači biti programer.

Quotes for Software Engineers sadrži upravo ono što mu naslov kaže: gomilu citata o programiranju, softverskom projektiranju i srodnim temama. Čak i ako niste programer, ali surađujete s njima kao manager, klijent ili na neki sličan način, savjetujem da posjetite sajt i malo se educirate, a ovdje ću samo prenijeti moj omiljeni, klasični citat:

The first 90 percent of the code accounts for the first 90 percent of the development time… The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Popularity: 40% [?]

U najnovijem postu na svom blogu Nik Cubrilovic se s pravom zgraža nad koderskom praksom startupa PayPerPost, prikazanog u filmovima koje mu je netko poslao na mail. Svaki iskusniji developer će se na prikazane aktivnosti ili slatko nasmijati ili užasnuti, a za dodatnu zabavu pronašao sam izvor tih videa.

Riječ je o serijalu Rockstart, koji u stilu reality televizije prati nastanak i razvoj PayPerPosta u kratkim epizodama u trajanju od 5-8 minuta. Iako nisam još pogledao sve epizode (najnovija, The ‘Duh’ Vinci Code, je četrnaesta po redu), jasno je da je serijal odličan prikaz nastanka jednog Web startupa “iznutra”. Već u ove dvije epizode koje je Nik prenio mogu se vidjeti početničke greške glavnih developera (pardon, code ninja), muljanje razvojnog direktora (pardon, dir of coding stuff) CEO-u i CEO-a investitorima, i ovdje wannabe poduzetnici mogu jasno vidjeti kako to izgleda u praksi.

Da se odmah ogradim od svih komentara na temu Falcon and the Snowman: da, svjestan sam da je ovo američki startup i da u domaćoj praksi mnoge stvari nemaju nikakve sličnosti s ovim što možemo vidjeti u serijalu. Međutim neke stvari su univerzalne (nepažljivo prtljanje SQL-om izravno po produkcijskoj bazi će rezultirati jednakim izrazom i na licu domaćeg direktora), dok su mnoge dovoljno slične da se iz njih mogu izvući neke pouke i u našim uvjetima. Možda je najveća razlika da američki startupi poput PayPerPosta imaju pristup venture kapitalu koji im donekle olakšava isplatu plaća i drugih briga — no i kod nas se stvari polako mijenjaju u tom pogledu.

Popularity: 51% [?]

Riječ iz naslova sam prvi put pročitao prije mnogo godina, i isprva me zbunila, no kasnije sam shvatio da je u pitanju kratica, i to za jedno od najosnovnijih načela poslovanja, ali i života općenito.

Frazu there ain’t no such thing as a free lunch često ćete naći nezgrapno i doslovno prevedenu u stilu “ne postoji takva stvar kao što je besplatan ručak”, no hrvatski ima drugu uzrečicu manje-više istog značenja: “sve se vraća, sve se plaća”.

Što to znači u praksi? Zamislite da imate savršenu ideju za online projekt, koji bi mogao djelovati komercijalno i čak biti uspješan na svjetskom tržištu. Koji korak morate prvo poduzeti? Platiti programera koji će napraviti prototip te aplikacije.

Ako sami znate programirati, imate sreću. Umjesto da svoje teško ušteđene kune/dolare/eure/pangalaktičke kredite potrošite na nekog programera za kojeg niste sigurni koliko će mu vremena trebati i kakav će biti krajnji rezultat, lijepo ćete sami sjesti i i napisati kostur svoje aplikacije. Tako ćete uštedjeti velike novce i besplatno dobiti prototip koji će privući investitore k’o muhe na med. Točno? Baš i ne, osim ako ste cajlonac.

Koliko god bili dobar programer, za izradu kvalitetnog proizvoda trebat će vam bar nekoliko mjeseci. Ako ste u stanju nekoliko mjeseci ne jesti i ne odmarati se, te programirati ne plaćajući račune za struju i Internet, molim vas javite mi se, mislim da mogu naći odličan posao za vas. A kako vjerojatno niste, budite sigurni da i vaš rad košta; ako i ne izravno, on svakako ima svoju cijenu.

[Napomena: Ovaj post sam započeo prije nekoliko mjeseci, ali razne real life okolnosti su me omele u njegovom dovršenju. Više se ne sjećam što sam točno planirao napisati nakon gornjeg uvoda, ali čitajući ga ponovo zaključio sam da i on sam daje sasvim suvislu poantu i koristan savjet, pa sam ga odlučio objaviti i ovako nedovršenog.]

Popularity: 67% [?]

Pišući novi tekst za stranicu O autoru (coming soon), pri čemu sam rekapitulirao svoje developerske korijene, shvatio sam kako je svojevremeno — tamo negdje sve do pucanja (prvog, rekli bi neki) dotcom mjehura — bilo sasvim normalno da jedni developeri rade na serverskoj strani Web aplikacija — JSP, PHP, ASP, ColdFusion… — dok drugi rade na klijentskoj strani — HTML, CSS, Javascript, Flash. Kad je prošlo vrijeme bezočnih ulaganja u Web i IT općenito, postalo je preskupo držati velik broj developera, pa su oni koji su bili dovoljno sretni da zadrže posao bili primorani raditi sve, potaknuti stavom poslodavaca “pa sve je to programiranje, možeš ti i jedno i drugo”.

Tako je nastala podjela posla po kojoj programeri pišu serverski kôd, a dizajneri pišu markup (i ne žele ni vidjeti programski kôd — otud toliki uspjeh template modula “for dummies”, kao što je Smarty), a negdje na ničijoj zemlji između njih ostale su client-side programske tehnologije poput Javascripta i ActionScripta. Kad god bi se pokazala potreba za razvojem nečega u njima, to je palo na leđa server-side programera, i tako su oni postali donekle “renesansni ljudi” Web developmenta, poznajući svaku od nužnih tehnologija do neke mjere.

Većina ljudi — a tu nažalost spada i većina klijenata — nije svjesna koju količinu tehnologija sadržava jedan prosječan (dinamički) Web site, a koju mora objediniti razvojni tim koji se nerijetko sastoji od samo jednog čovjeka. Podaci su najčešće smješteni u nekoj relacijskoj bazi — obično MySQL ili PostgreSQL — što podrazumijeva poznavanje SQL-a; poslovna logika koja se vrti sa serverske strane implementirana je u nekoj od adekvatnih tehnologija kao što su PHP, Perl, Java (JSP, J2EE), ASP, ASP.NET, Python, Ruby (on Rails), ColdFusion i druge; komunikacija s drugim Web aplikacijama zahtijeva poznavanje Web servisa, XML-a, RSS feedova i prema potrebi XSLT-a. Prikaz svega toga na serveru podrazumijeva znanje u najmanju ruku HTML-a (a i mnogi iskusni poznavatelji HTML-a nisu nikad čuli za vrlo korisne elemente kao što su q, fieldset, legend, label, pa čak i button), te CSS-a za oblikovanje, a često je potrebno i određeno znanje grafičke pripreme (npr. u čemu je razlika između GIF-a i JPEG-a i kad je kojega bolje koristiti). A ako dodamo malo aplikacijske logike na klijentskoj strani, komunikacije sa serverom bez osvježavanja stranice, dinamičke promjene sučelja itd, onda u igru ulazi i Javascript, dugo zanemareni i podcijenjeni jezik koji vlastitu renesansu doživljava pojavom “ajaxa”. Čak i najmanji dinamički site podrazumijeva redovno korištenje barem četiri od gore navedenih tehnologija: SQL, PHP (ili neku drugu serversku tehnologiju), HTML, CSS.

Kod klasičnog sistemskog i desktop developmenta broj tehnologija koje koristi jedan programer je daleko manji. Baza je često i ovdje prisutna, no brojni alati i libraryji omogućuju komunikaciju bez ijedne linije SQL koda; korisničko sučelje se također apstrahira iza raznih GUI libraryja. Jasno, postoje razlike od developera do developera, ali daleko lakše ćete naći desktop developera koji ne mora razmišljati o ničem drugom nego o temeljnoj logici u Javi ili C++-u, nego što će isti slučaj biti za Web developera.

Da zaključim: namjera mi nije izazvati sažaljenje prema “jadnim” Web developerima, već samo podsjetiti na nužnu širinu znanja koje oni posjeduju, te da Web development nije “pljuga” kako često čujem od vrlih kolega čije aplikacije rijetko imaju output raskošniji od jedne linije shella. Ne treba zaboraviti da svaka Web aplikacija, koliko god bila jednostavna, u suštini predstavlja dvije aplikacije: jednu, koja se vrti na serveru, i koju se obično smatra “pravom” aplikacijom, te drugu, koja se izvodi na klijentu — obično u browseru — a koja s prvom nema nikakve veze osim niza instrukcija koje joj ova šalje. Čak i najjednostavniji HTML — čest stav je bah, pa to je samo tekst — nije output Web aplikacije, već samo niz instrukcija klijentskoj platformi kako treba obaviti svoj dio posla.

Popularity: 52% [?]

U komentaru na moj prethodni post zigzig je opisao svoja iskustva s outsourcingom. Čini mi se da je ova tema zanimljiva i širem krugu, pa sam svoje odgovore izvukao u zaseban post.

Outsourcing zvuci sasvim lijepo u teoriji. No, kada se razmotri ponuda za filozofsko odrzavanje, sto je kod mene nedavno bio slucaj, ispadne ejziva svota. Za tu svotu mogu se uzeti kvalitetni ljudi koji ce sve skupa odraditi, a itronija je sto bi ti isti ljudi to radili outsourcano, samo sto bi to mene stajalo nekoliko puta vise.

Moram priznati da mi nije baš sasvim jasno kakvo je to filozofsko održavanje (osim što me podsjeća na onaj stari vic o četiri vrste ljubavi: studentskoj, nesretnoj, penzionerskoj i filozofskoj ), no pretpostavit ću da je riječ o uobičajenoj praksi domaćih informatičkih tvrtki da nakon isporuke temeljne narudžbe naplate po principu TV-pretplate: plaćaj svaki mjesec, koristio je ili ne.

Za razliku od inicijalnog razvoja, koji se ne može mjeriti u fiksnim, linearnim jedinicama — o tome više u nekom drugom postu — klasično održavanje je vrlo jednostavan, mjerljiv proces: nešto ne radi kako je predviđeno, dođeš, radiš sat ili dva i problem je ispravljen. Drugim riječima, mjesečna “pretplata” na održavanje nema puno smisla i potpuno je otimanje novca — kvalitetan ugovor o održavanju određuje uvjete pod kojima će ekipa održavatelja biti na usluzi, te kolika je cijena radnog sata, i to je sve.

zigzag ima još zanimljivih komentara:

Problem neodrzavanja izvire iz niskog prioriteta i vaznosti koji se daju pojedinim aktivnostima, te losem upravljanju projektima i procesima. Nikakav outspurcing to nece izmjeniti, moze samo prikriti, a kad eksplodira bit ce puno gadnije.

Prva rečenica je apsolutno točna, no druga malo previše uopćava stvari. Da bi se outsourcing obavljao na kvalitetan način nije dovoljno reći evo, ja imam X developera, dajte mi da za vas radimo posao — potrebno je te developere kvalitetno organizirati, i to čak i daleko detaljnije i pažljivije nego in-house razvojni tim. Osnovne prednosti outsourcing tima izviru iz toga što on može raditi za nekoliko projekata istovremeno, čime se smanjuje individualna cijena, no to zahtijeva dobru organizaciju: project manageri moraju kvalitetno obavljati komunikaciju između klijenata i developera, razni pomoćni libraryji i drugi dijeljeni kôd može se iskoristiti na više strana itd.

Dakle, loše organizirani outsourcing tim može napraviti čak i više štete nego loše organizirani in-house team — no to nije razlog da se odreknemo prednosti koje donosi outsourcing, već da se potrudimo stvari kvalitetnije organizirati.

Tko moze sprijeciti pruzatelja usluge da izbacuje losa rjesenja?

Odgovor na ovo pitanje u teoiji je vrlo jednostavan: konkurencija. No, u praksi se susrećemo s tradicionalnim gledištem koje je kod nas dosta prisutno, a koje bježi od konkurencije kao vrag od tamjana, pa čim u nekom području već postoji neka jača tvrtka stav je ovdje nemam šanse, neću se ni gurati.

Jedini način da se outsourcing kod nas razvije u kvalitetan biznis je da ima što više takvih firmi, te da tržište odredi koja je bolja a koja lošija. Ako jednom zezneš klijenta, on ti više neće dolaziti.

ako nisi mogao sprijeciti kod sebe, kad si imao 100% kontrolu, kako znati da te ovaj mulja?

Još jedan od problema kod nas, izravno vezan uz ovu konkurenciju koju sam spomenuo, jest činjenica da kod nas i nema pravih outsourcing tvrtki koje bi mogle stati iza svog posla. U većini slučajeva stvar se svodi na individualne developere ili manje timove koji često mijenjaju članove, nemaju nikakvu organizaciju i proces rada im je prilično kaotičan. Razvoj softvera treba znati organizirati bez obzira je li riječ o in-house timu ili zasebnoj tvrtki, no moj stav je da je daleko lakše kvalitetno organizirati outsourcing tim jer se on može maksimalno posvetiti svom core-businessu, a to je razvoj softvera.

Definirati ciljeve i parametre? Nisi znao ni prije, kako ces odjednom znati.

Jedna od osobina kvalitetnog razvojnog tima je da zna postaviti prava pitanja. Čest je slučaj da naručitelji nemaju ideju o tome što točno žele i kako definirati svoje potrebe, i tu je uloga razvojnog tima da na neki način postane savjetnik i usmjeri naručitelja u pravom smjeru. Nažalost, ovdje je česta situacija guranje određenih tehnologija i rješenja koja i nisu idealna za naručitelja, pa čak ni za razvojni tim, ali dobavljač na njima dobiva nekakvu proviziju.

Kako sprijeciti vendor lock-in i stvaranje ovisnosti o pruzatelju usluge?

Opet, kvalitetan razvojni tim isporučit će rješenje koje je dobro projektirano i uključuje dovoljno dokumentacije da ga može preuzeti i nastaviti svatko tko je vičan korištenoj tehnologiji. Iako na prvi pogled outsourceru to nije u interesu, smatram da to može biti odličan selling-point i donijeti više novog posla nego pomoći gubitku klijenata.

Klijenti nikad neće otići ako je posao dobro obavljen — dapače, klijenti vole imati jasan i siguran način da se izvuku iz problematičnih poslovnih odnosa, i ako im u startu pružite perspektivu takvog izlaza biti će spremniji poslovati s vama.

IT outsourcing nece donijeti rjesenje sam po sebi, moze samo unijeti jos veci nered ako se stavlja na nered

Daleko od toga da je stanje u našoj IT — a posebno softverskoj — branši idealno; upravo zato sam želio ukazati na načine kako se ono može popraviti. Možda je upravo jedan od razloga što nemamo puno outsourcing timova u tome što svi gledaju kratkoročno, projekt po projekt; potrebno je baciti pogled malo unaprijed i povući neke temeljne poteze koji će povećati kvalitetu rada i samim time stanje na tržištu.

Popularity: 41% [?]

Okej, dosta je bilo maltretiranja s glupim managementom koji ne razumije probleme razvoja softvera, radnih vikenda i maltretiranja s nečijim imbecilnim kodom, a sve za nekakvu crkavicu. Imam dovoljno ušteđevine da neću umrijeti od gladi ako sam nezaposlen šest mjeseci, a toliko se dobro razumijem u programiranje da ne samu da ću za šest mjeseci ako treba lako pronaći posao, već sam uvjeren da mogu vlastitim radom pokrenuti uspješan softverski biznis.

Otprilike ovo je samom sebi prije nekih pet mjeseci rekao Benji Smith, programer i vrlo inteligentan bloger, čest gost i na Joelovim discussion boardovima. Umjesto da se fokusira na prvu ideju koja mu padne na pamet, on je tijekom dvadeset i osam dana iznio na svom blogu isto toliko poslovnih ideja, a zatim ih prosijao kroz sito sastavljeno od poslovnih, tehnoloških i osobnih kriterija.

Vrlo je zanimljivo pročitati rezultate prve runde tog prosijavanja, kad je otpalo dvadeset ideja. Svaku je vrlo pažljivo proučio, te ih odbacio zbog vrlo konkretnih razloga — tih dvadeset “luzera” otpalo je zato jer su već realizirani, ili zato što jednostavno nisu imali dovoljno tržišnog potencijala, ili on nije imao dovoljno stručnog znanja, ili ga jednostavno nisu dovoljno “palili”.

Preostalih osam zatim je sveo na listu od pet, iz koje je odabrao jedan i bacio se na realizaciju. Međutim, od njega je odustao kad je malo proučio stanje pravnog sustava, jer je projekt imao element kockanja, koje je na američkom tržištu drastično regulirano; njegova odluka da odustane čak je došla i prije nedavne odluke vlasti da Amerikanci ne smiju sudjelovati u online kockanju, tako da je bio vrlo dalekovidan.

Ovu priču vam prenosim zato što mi se njegov proces razrade ideja čini vrlo dobrim za mnoge poduzetnike, ne samo u softverskoj djelatnosti. Pojednostavljeno, možemo ga svesti na sljedeće korake:

1. Napravite popis svih poslovnih ideja koje su vam pale na pamet. Ne razmišljajte o tome imaju li smisla ili nemaju, postoji li već adekvatno rješenje ili bilo što drugo — samo ih popišite, i neka ih bude što više. Ukradite ih ako treba od drugih poduzetnika, od prijatelja i rodbine, s televizije ili Interneta, ili ih smislite sami.
2. Prođite ideje, jednu po jednu, i rastrančirajte svaku do detalja. Pogledajte Benjijevu listu za inspiraciju, i dodajte vlastite razloge zašto bi ideja mogla biti loša, te za svaku od njih pitajte sami sebe ta pitanja. Je li problem koji ona rješava već adekvatno riješen? Imam li dovoljno znanja o tom području? Ima li stvar tržišnog potencijala? Imam li dovoljno entuzijazma za ovu ideju?
3. One koje prođu ovo sito još jednom proučite i rafinirajte svoj izbor na najviše pet-šest njih koje imaju najviše potencijala.
4. Odaberite jednu od njih i stanite iza svoje odluke. A prije svega, detaljno proučite sve što je iole vezano uz tu ideju: pravnu legislativu, tehnička rješenja, stanje na tržištu…

I za kraj, ukoliko vam naknadno stečeno znanje donese nove spoznaje zbog kojih ova ideja izgubi dio svoje vrijednosti, nemojte se libiti odustati od nje. To nije ništa loše, i ne predstavlja obilježje lošeg poduzetnika, naprotiv: dobar poduzetnik će se znati prilagoditi promjeni situacije i usmjeriti se na druge projekte s više potencijala.

Popularity: 52% [?]

Još prije nekoliko dana Vuk je ukazao na odličnu izjavu Gorana Radmana na temu sadašnjeg i budućeg stanja hrvatske IT branše. Iako je njegova dijagnoza vrlo perceptivna i točna, osobno me najviše dojmio sljedeći ulomak:

Prvi [veliki problem hrvatskog IT-a] je što se kod nas zazire od outsourceinga. Naime, u Hrvatskoj polovica IT stručnjaka radi u informatičkim odjelima u bankama, javnoj upravi i drugim velikim poduzećima. To znači da 50 posto hrvatskih IT potencijala nije na tržištu. Po Radmanu, to je dvostruka šteta jer ti ljudi zaostaju u odnosu na razvoj tržišta, a IT tvrtke gube jedan znatan dio poslova za koji bi se inače mogle boriti.

Iako i drugi problemi koje je naveo (preveliki udio države kao kupca, te naglasak na prodaji hardvera nauštrb softvera) predstavljaju uteg oko vrata razvoju IT sektora, ovaj gore predstavlja izravnu kočnicu bilo kakvom uzletu. Problem je što on ne vrijedi samo za velike organizacije koje Radman nabraja — iako zbog njihove veličine one najviše doprinose brojem developera — već i za brojne male tvrtke kojima informatika nije osnovna djelatnost, no ipak zapošljavaju programere za interni razvoj.

Prema razvoju softvera domaći se poduzetnici često odnose maćehinski, čak i kad svakodnevno poslovanje izravno ovisi o kvalitetnom radu njihovih programa. Navest ću primjer dviju tvrtki u kojima sam situaciju upoznao iz prve ruke.

Jedna od njih ima u svom vlasništvu desetak siteova, uključujući i jedan od najposjećenijih siteova u regiji koji nisu portali providera. Ti siteovi donose solidne prihode, i tvrtka danas ima tridesetak zaposlenih s vrlo dobrim plaćama za naše uvjete. No, iako tvrtka (i većina njenih siteova) postoji već pet-šest godina, tek je prije otprilike godinu dana zaposlen prvi full-time sistem administrator; a praktički sve sajtove je vlastoručno razvio jedan jedini programer, koji se pritom učio PHP-u od nule. Danas tvrtka ima niz problema sa svakodnevnim funkcioniranjem siteova, i rješava ih konstantnim angažiranjem individualnih developera kao kriznih vatrogasaca koji dođu, riješe aktualni problem, spreme novce u džep i odu. Sutra pak dolaze neki drugi programeri, koji se muče s kôdom svojih prethodnika (redovno nedokumentiranim i složenim po principu “drž’ vodu dok majstori odu”), te i sami pobjegnu čim su obavili posao. Rezultat takvoga rada je zbrda-zdola nabacan kôd, problematičan softver i gomila trikova kojima se djelatnici moraju dovijati kako bi održali funkcionalnost.

Drugi slučaj je jedna od najvećih domaćih tvrtki u svojoj branši, koja se pojavila na tržištu prije nekoliko godina s Web aplikacijom tada jedinstvenom za naše tržište, i do danas je izrasla do jednog od vodećih igrača u regiji, počevši čak kupovati tvrtke s puno dužim stažom i ugledom u susjednim zemljama. Iako danas velik dio njihovog poslovanja dolazi drugim kanalima, njihov Web site još je uvijek ključan faktor uspjeha, te u sastavu tvrtke postoji i razvojni tim koji se osim za site brine i za druge interne aplikacije koje koristi preko stotinu djelatnika. Ovdje postoji relativno dobar pristup organizaciji razvojnog tima, te konstantno ulaganje u programere i tehnologiju, no jedan detalj ukazuje na podcjenjivanje važnosti programerskih uvjeta, a izašao je na vidjelo tijekom razgovora s dva managera njihovog razvojnog tima. Taj dio razgovora je tekao otprilike ovako:

Ja: Pravilna organizacija radnog prostora developera vrlo je bitna … blablabla … Peopleware … blablabla … Developeri moraju imati vlastiti odvojeni prostor, a idealno zasebne urede. A ne da im se marketing po cijele dane pored uha dere na telefon …

Oni: [muk]

Ja: A gdje je kod vas smješten developerski odjel?

Oni: [muk]

Jedan od njih: Pa, ovaj… Odmah do marketinga…

Da ne zaboravim, svi djelatnici u njihovoj novoj, blještavoj poslovnoj zgradi sjede u nizovima, odvojeni samo tankim pregradama čija je jedina svrha da se gore lijepe slike djece i razglednice iz egzotilnih krajeva. Čak i klasični cubiclei bi ovdje bili napredak.

Naravno, u oba slučaja riječ je o tvrtkama kojima IT nije primarna djelatnost, no u obje tvrtke jako ovise o kvalitetnom radu softvera. Višednevni gubitak prihoda koje donose razne aplikacije u oba bi slučaja predstavljao težak udarac, a još veću štetu izazvao bi gubitak kredibiliteta i odlazak razočaranih klijenata u pravcu konkurencije.

Nažalost, u većini slučajeva ovakve tvrtke nemaju alternativu nego ili da osnuju vlastiti razvojni tim (prema kojem se onda ne znaju ispravno postaviti), ili da unajmljuju “vatrogasce” za rješavanje tekućih problema. Ono što našem tržištu nedostaje jest veći broj kvalitetnih outsourcing tvrtki, koje bi proizvodile custom-made aplikacije prilagođene potrebama klijenata i onda stale iza svog proizvoda, održavajući ga i unaprijeđujući. Takvih tvrtki ima, no one su orijentirane uglavnom na veće tvrtke i državne institucije, što je poseban paradoks imajući u vidu Radmanovu gore citiranu izjavu, a često su i usko specijalizirane na jedno područje ili čak samo jednoga klijenta. Odličan primjer takvog koncepta outsourcing tvrtke je ThoughtWorks — američka tvrtka s uredima u Kanadi, Velikoj Britaniji, Indiji, Kini i Australiji, a za koju radi legendarni Martin Fowler — koja proizvodi upravo takav, custom enterprise softver.

Preduvjet za tržišnu isplativost takve firme jest da i male tvrtke, kao i one veće, prestanu sa stihijskim zapošljavanjem i unajmljivanjem doučenih programera, te da prepuste stručnjacima da razviju softver prilagođen njihovim potrebama. Sve što je potrebno jest da imaju što jasniju ideju što bi takav softver trebao raditi, a za ostalo se trebaju pobrinuti stručnjaci outsourcing tvrtke.

Popularity: 63% [?]