Razlog je vrlo jednostavan, i ukratko ga je briljantno sumirao Donald Knuth u predgovoru knjige Scotta Roseberga „Dreaming in Code“:
Software development is hard!
Teško, složeno, komplicirano … koji god hard-sinonim stavite kao pridjev uz razvoj softvera, dobro ste ga stavili. Izvještaji Standish grupe o uspješnosti IT projekata, iako u zadnje vrijeme pokazuju određen pozitivne pomake, ni u kojem slučaju nisu pleasent reading za bilo koga tko se sprema u takvu avanturu, a lista propalih softverskih projekata, čak i ako ćemo se ograničiti samo na one s preko 100.000.000 „uništa“ utučenih dolara, valjda jedva stane na list papira! (evo jednog popisa koji sam pronašao). Od aerodroma u Denveru do FBI-evog Virtual Case sistema … primjera koliko hoćeš.
Zašto je tome tako kad danas svaka šuša zna napraviti web site ili neku jednostavnu aplikaciju za vođenje kafića?
E, upravo je u tome problem! Ili, preciznije rečeno, jedan od problema. Moderna integrirana razvojna okruženja (IDE) naizgled doista omogućavaju vrlo jednostavnu izgradnju čak i složenijih aplikacija a ne bi bilo pretjerano reći da im je to i ultimate driving force!
Definiraj par tablica u bazi, kreiraj konekciju, napravi Windows/Web formu, stavi SqlConnection/DataAdapter/DataReader/DataGrid, Ctrl+F5 i voila … gotovo (ovo je stvar iz Microsoftove perspektive, but you get the point 
.
I ja osobno mislim da je to prekrasno
Jer, kad se sjetim svojih početaka s Commodoreom VC-20 s 3 KB memorije (ali, imao sam „proširenje“ na cijelih 11 Kb!) i kako sam u čistom mašincu (čitaj, ukucavanjem mašinskih kodova u Basicu korištenjem DATA naredbe – nije bilo asemblera!) brljao po video memoriji „grafičke kartice“, na ovo što danas mladac od 13-14 godina može izvesti na PC-ju mogu samo reći – VAU .
Ali, ali, ali …
There is a dark side of the story here!
Koja izlazi na vidjelo iznošenjem jednostavne činjenice – nikad više kao u doba dok sam se „igrao“ s mojim Commodorcem neću toliko znati o tehnologiji koju koristim!!! (a doista je zanimljiva koincidencija da nešto slično tvrdi i Coding Horror CAR u svom postu , i btw. ja se s njim potpuno slažem da je car Dijkstra bio u krivu
Onog trenutka kad sam posve ovladao BASICom i mašincem za 6520 procesor (knjiga Dejana Ristanovića “Mašinac za 6520 i Z80″, jednog od careva davnašnjih „Računara“, mi i danas budi jedinstvene osjećaje 
), te kad sam nabavio specifikaciju za VC-20 (čitaj, popis i namjenu memorijskih lokacija – što bi danas rekli BIOS) svijet je bio moj.
Od tada pa danas, it was all downhill u borbi s složenošću sofvera!
Naravno, ovdje se mora reći da je to moja osobna percepcija/iskustvo i da sam svjestan da su ljudi dok sam se ja bakćao s video memorijom na VC-20 već gradili prilično složene IT sisteme (mainframe is the catch word here), ali vjerujem da će većini onih koji imaju bar 10-godišnje iskustvo u razvoju softvera biti jasno o čemu pričam. Tipična „aristotelovska“ priča – ne znam da li bih taj vremenski trenutak stavio u 40-te ili 50-te, ali prilično sam siguran da je davno bilo kad je netko mogao reći da „zna sve što se o kompjuterima ima znati“.
I, da se vratimo na ulogu modernih IDE sistema, u skrivanju te sve veće kompleksnosti IDE vendori su odradili vraški posao, a odrađuju ga i dalje (jel se ko sjeća Turbo Pascala, ili možda Visual Studia 6.0? – ma da sjećam, održavam još i danas .
Ali, problem je što je ta složenost ipak „samo“ skrivena! Ona je i dalje tu, i pomalja svoju ružnu glavu svaki put kad u nekoj third-party biblioteci ili komponenti (ili samom IDE okruženju!) iskoči bug, ili kad ju koristite na način na koji developeri koji su je pisali nisu računali. Kako je danas svakome jasno da potpuni in-house razvoj nije kredibilna opcija (za iole složeniji IT sistem) situacija može biti/postati prilično pipava.
Ipak, savladavanje složenosti nije nepremostiv problem, kao što cjelokupni dosadašnji razvoj ljudske civilizacije zorno ilustrira! Od Space Shuttlea do najnovijeg Airbusa (iako će netko ovdje sigurno primjetiti da su to dva odlična primjera kako složenost ljudi ipak nisu do kraja nadvladali grade se sve složeniji sustavi. Nažalost, softver je u tom fajtu sa složenošću suočen s jednim dodatnim problemom, od kojeg ne pate ostale inženjerske discipline s kojima se razvoj softvera često uspoređuje, a to je problem mijenjajućih zahtjeva (iliti na engleskom, a i bolje zvuči, changing requirements)!
Da bi posve shvatili s kakvim su calamityjem ovdje developeri softvera suočeni, povući ću paralelu s građevinom – područjem s kojim se izgradnja softvera često „analogizira“ (građevinari grade fizički, softveraši virtualno pa to valjda nekako „dođe na slično“).
Zamislite, na primjer, da Vas kao uspješnog poduzetnika i vlasnika građevinske firme, kontaktira naručitelj koji želi da mu sagradite fensi-šmensi neboder od 20 katova. Ništa lakše – nađe se arhitekt koji napravi turbo-gtx-injection dizajn, koriste se sve redom najmoderniji materijali, pazi se na energetsku efikasnost, naprave se nacrti i gradnja kreće. Sve se odvija po planu (dobro, ne baš, ali zadnjih dva mjeseca će se raditi i nedjeljom pa će se nekako stići), katovi se polako nizaju i svijet je u ružičastim bojama.
I onda jednog dana dolazi naručitelj i kaže:“Slušaj, znam da sam rekao da nam garaža neće trebati jer sam računao da ćemo iskoristiti ovo zemljište pored za parking, ali sad su se stvari promijenile i treba napraviti i garažu za par sto auta ispod nebodera“!
Što mislite, da li je ikad iti jedan građevinac dobio takav zahtjev od svog naručitelja?
Možda i jest, u nekoj specifičnoj situaciji and with lots of money to throw around, ali sam prilično siguran da bi reakcija svakog građevinca danas u Hrvatskoj bila ????????? Radi se naprosto o toliko očigledno glupoj ideji da vjerojatno nikome to ne bi palo napamet ni pitati!
Nažalost, kao što to vrlo dobro svaki developer zna, takvi zahtjevi su manje više normalna stvar prilikom razvoja softvera. (a izvrstan primjer klasičnog nerazumijevanja pogledajte ovdje).
„Ma to ti je samo dodati jedan gumbić na formu, ukucaš malo koda i to ti je to – ja ti to u dBaseu isprogramiram za jedno popodne“ (ovo je ako ste imali sreće pa za menadžera imali nekoga ko je u životu imao bar malo doticaja s programiranjem
Manje više svatko zna da građevina mora imati temelje i da jednom kad si svoj neboder „utemeljio“ i na tom temelju izgradio 10-ak katova, ići graditi garažu ako i nije nemoguće definitivno nije nešto na što bi se čovjek išao odlučiti laka srca.
A u softveru? Nema problema: „Pa to su sve samo neke điđe miđe po ekranu – nema tu tona i tona betona, čelika i zemlje za prevrnuti“. Na što je moj jedini komentar – što bi programeri dali da su stvari koje oni „prevrću“ prilikom udovoljavanja željama naručitelja tako jednostavne kao beton, čelik ili zemlja!
Jer, kako građevinac zna da nema smisla graditi garažu ispod već napola izgrađenog nebodera? Odgovor je jasan – građevinska statika je prilično uznapredovala znanost i prilično dobro će ukazati na sve probleme koje u izvođenju takvog poduhvata treba riješiti.
Zašto tako ne bi moglo i sa softverom?
E zato jer kod softvera ima na desetke, stotine i tisuće različitih „prijedloga za garažu“ koji se mogu smisliti, odnosno s kojima naručitelj može banuti pred developera! Stvar je još i gora zato jer je posve nerealno očekivati da se sve potencijalne „garaže“ unaprijed mogu identificirati (što bi Rumsfeld rekao, to su „unknown unknowns“ – btw. to je, barem po mom mišljenju jedan od najpodcjenjenijih komentara u povijesti – koliko je zbog toga ridikuliziranja čovjek proživio a rekao je briljantnu istinu, koja je istovremeno i očigledna na način na koji samo briljantne istine mogu biti očigledne . A da ne spominjemo beskonačno šire mogućnosti INTERAKCIJE među različitim dijelovima softverskih sustava (u odnosu na klasičnu građevinu)!
Jer, kad se nešto (fizički) gradi tijek je manje više poznat – nosiva konstrukcija, pregrade, instalacije i na kraju unutrašnje uređenje, i, što je u ovoj priči još i važnije, svaki element se može proračunati i prilično dobro definirati kako interagira s ostalim dijelovima cjeline. Rezultat takvog procesa je da se u konačnici većina izgrađenih konstrukcija vrlo malo (ako i ikako!) razlikuje od nacrta po kojem su napravljeni!
A Vi mi pokažite softverski sistem za koji vrijedi to isto (a da nije napravljen za američko ministarstvo obrane
Waterfall način razvoja je prošlost, a svi oni projekti koji počnu „napraviti ćemo to i to (gdje je „to i to“ definirano u otprilike par rečenica!) za 2,3 ili 5 godina i to će koštati 10,50 ili 100 tisuća/milijuna kuna“ su naprosto osuđeni na neuspjeh (gdje razina neuspjeha može biti različita – od potpunog neuspjeha i odustajanja od projekta pa do različitih nivoa probijanja budžeta i time-framea za izvedbu projekta).
Razlog tome je vrlo jednostavan – ne postoji softverski developer/dizajner/arhitekt koji za sistem koji ima više od 10, 20 ili 50 tisuća linija programskog koda može unaprijed predvidjeti sve tehničke začkoljice/probleme koji će se pojaviti, i što je još važnije, naknadne zahtjeve naručitelja koji će iskrsnuti prilikom izgradnje sistema. Takvog jednostavno nema, a ko vam kaže da je on taj, ili laže ili nema pojma (a vi se odlučite koaj od te dvije opcije je „bolja“ . Naravno, ovdje je bitno pripomenuti da gornja izjava vrijedi ukoliko imate „normalan“ budžet za razvoj svog softvera! Ako imate godišnje na raspolaganju 500 milijardi dolara koliko ima Pentagon, onda možete sebi priuštiti 10,20 ili 50 analitičara/dizajnera/arhitekata koji će doista detaljno proroštati problem!
Za sve nas ostale smrtnike ostaje činjenica da je promjena u zahtjevima naručitelja neminovna i osnovno pitanje kod razvoja svakog softvera je kako se prilagoditi toj činjenici. Lamentacije tipa „zašto se ti naručitelji konačno više ne odluče što žele“ su u biti kontraproduktivne i esencijalno pogrešne!
Pogrešne zato što upravo u mogućnosti promjene leži najveća snaga softvera kao takvog! Jer, bilo da do promjene dolazi zbog naknadne pameti naručitelja, bilo da do nje dolazi zbog promjene poslovnih prilika na tržištu i pojavljivanja nove business opportunity, promjena je „dobra“ zato što rezultira, odnosno može/treba rezultirati, poboljšanjem softvera i generiranjem većeg profita od njegove izrade.
Ono što softver u osnovi razlikuje od građevine je što pruža neograničene mogućnosti isprobavanja i testiranja! A kako testiranje može pomoći u savladavanju “promjenjive prirode” softvera, u jednom od sljedećih postova …
Filed under: Razvoj softvera općenito | Tagged: promjenjivi zahtjevi, složenost softvera
S velikim entuzijazmom se nadam da ću uspijevati pratiti ono što će ovdje pisati
! Jer ja više volim čitati o nečem o čemu znam malo, nego stalno istu slamu mlatiti.
Turbo Pascala se sjećam, i Fortrana, Basica naravno. Sjećam se i sklapanja domaćih Orlova (da sjećam, i lemilicu držala!). Pa se sjećam ogromnih Borlanda koji su zauzimali 2-3 sobe … dobro je bilo
Krv sam starome popila želeći naučiti SVE, a on mi je uvijek odgovarao da to meni ničem ne služi, da ne trošim svoje i njegovo vrijeme uzalud i da evo mi knjiga, ako baš nemam zadaće ili lektire 
))))
Sad imam pitanjce: ostala sam paf kad sam vidjela da klinci u osnovnoj na početku informatičkog opismenjavanja imaju zadatak neš’ naučiti o Basicu. Pita me mala koji će joj to vrag?! Odgovor je, naravno, razočaravajući. I fakat se pitam – ima li to smisla prežvakavati u 21. stoljeću ako ćemo imati u vidu da bi početni cilj trebao biti početno informatičko opismenjavanje KORISNIKA. Kaj ti misliš?
Željezo se kuje dok je vruće
, tako da je moj stav da nikad nije PRERANO za početi učiti programirati.
Ali, u toj dobi isključivo na FAKULTATIVNOM nivou!
A informatička pismenost (znači, znanje KORIŠENJA računala) je za današnje generacije obavezna i skoro da bih rekao da će im biti od veće koristi od matematike
. Ipak, skeptičan sam koliko se to može “naučiti” u školi s obzirom da ima osnovaca koji o korištenju računala znaju debelo više od svojih profesora 
.
Inače, BASIC kao prvi jezik uopće nije loš izbor
.
mislim da nedostaje link
@loodin – thx. popravljeno.
I je na fakultativnom nivou, sam početak u 5. osnovne. Uglavnom se to gradivo zbrlja, umjesto toga igraju igrice (moje informacije iz “konkretne” ruke).
))) i to joj je, naravno, totalno lame i kaj bi s tim kad postoji Blender i 3D!
))))))
Klinka i ja smo gledale HNOS programe unaprijed i zaključile da je sad u 4. (bez školske informatike) najmanje na nivou 7. razreda. S druge strane, kad gledaš čemu jahati isključivo na korisničkim programima (čitaj Microsoft), što to zapravo znači … Recimo, imaju u 6. montiranje video sadržaja u Movie Makeru (to je bila neka spika prepucavanja sa starijim klincima kako se nešto napravi i hint za “istraživanje”). Jbg, klinka sad koristi Uleadov daleko složeniji software, taj mali pomoćni programčić nismo pošteno niti otvarale. Dalje: radi svoje projekte za koje su uobičajeni plakati u Powerpointu. Ali doslovno sama, tražeći sadržaje na netu, filtrirajući ih i sklapajući u novu cjelinu. Ja sam na žalost morala intervenirati jer učiteljica ne vjeruje da nisam radila ja nego dijete i dalje inzistira na hameru i ljepilu. Nema veze kaj klinka ima stick oko vrata, mobilni software i zna se uštekati i pokrenuti bilo gdje – uz to zna i o čemu priča. Zabavlja ju to i jednostavno zna. A učiteljica je potpuno informatički nepismena.
S druge strane – pokušala sam joj objasniti da “razgovarajući” s računalom pomoću Basica možeš postići da po ekranu gmiže zmija
Stvarno me zaintrigiralo to pitanje tko koga, kada i kako nečemu (čemu?) treba poučavati, osobito na tako dinamičnom području.
E da, još jedan kuriozitet: djetešce nervira software na hrvatskom (imam to na jednom računalu – zabunom). Ako nešto ne razumije, provjeri na netu u rječniku ako nisam dostupnija ja – i onako je stalno online! Dvostruka korist, ali ne smijem glasno rogoboriti protiv hrvatskog nam materinjega posvuda
Moram još, sad na temu tvoje teme
Imala sam čast i sreću upoznati jednog predivnog, genijalnog programera koji nam je radio CSH software imajući samo opću sliku što bi taj trebao izvršavati. Sve detalje niti naručitelj niti involvirani budući korisnici nisu znali, ali stvar je trebalo napraviti i dorađivati u hodu. Apsolutno svaki “nemogući” zahtjev taj je čovjek naknadno odradio, a samo s naše strane bilo je barem 10 “genijalnih” ideja. Ja se tom tipu iskreno i duboko divim (i zavidim mu na čeličnim živcima)!
Pa eto, makar ste se “poštenog” posla uhvatili. Eeeeeeee, profesore, svaka čast
. Ma ima po meni i druga strana medalje zašto propadaju IT projekti. Razlog je često u menagementu (”Piscis primum a capita foctat”). Pa dosta ljudi ne shvaća da je menadžment postao zapravo svojevrstna znanost ovih dana i nikako da se ljudi prihvate ozbiljnije toga kod IT projekata. Uzmite cijenjeni FER tu za prvi primjer… Treba uvijek postojati neka osoba s vizijom i tu viziju treba gurati do kraja, a ne lako ćemo… (bolest od koje najviše pate programeri, koji i sami često podcjenjuju složenost projekta). Ja bih osobno ocijenio to kao jedan od glavnih krivaca propadanja. Okrivio bi još i “zastarjele” tehnike programiranja i definitivno osvijetlio obraz tehnikama agilnog programiranja koje dokazano pale kod takvih dinamičnih situacija kao što je softver po narudžbi.
Eeeeee moj Zvone…
Ima jedna stvar a to je da projekt kojeg se programira manje od 2,3 ili 5 godina jednostavno nije dovoljno izazovan
I tkogod da se uhvati takvog projekta, vrlo brzo će ustanoviti da “nije u šoldima sve”, nego je pitanje toga da svi koji na tome rade imaju ideju što bi na kraju trebalo ispasti – ako ne vide trebaju imati povjerenja u ostale.
A kad se i prihvatiš takvog posla, ono što je najvažnije jest da on bude u “containable steps” – tkogod da je naručitelj/financijer ili štogod treba biti svjestan da izmjene može raditi u točno određenim trenucima tokom razvoja, a tkogod da vodi taj projekt mora predvidjeti dovoljno (najmanje duplo više nego što korisnik na početku traži) takvih trenutaka.
Umjesto garaže dat ću ti drugi primjer – radiš keramičku vazu i na početku imaš jaaaaaako rijetku glinu. I ako i naručitelj u nekom trenutku dođe sa (načelno potpuno razumnom tvrdnjom) da “vaza mu treba za to da drži vodu a on sad eto ima viška” jasno je da će doljevanje te vode u tu glinu upropastiti cijeli projekt. Ali projekt će isto tako propasti ako se vaza nastavi raditi po starom, sa oslikavanjem, patinom i prekrasnom filigranskom drškom sa strane – jer ipak voda curi i ako vaza stigne prekasno nikome neće trebati.
Da se vratim – ti se zahtjevi ne mogu predvidjeti, ali se može predvidjeti njihovo postojanje. I besmisleno je analizirati kakvi bi mogli biti (ako su predvidivi treba ih odmah i ukalkulirati), pa projekt treba napraviti tako da teži idealnom a realizirati ga najbolje moguće u danim okolnostima – što znači da je glavna stvar odredti što je realizirani projekt a što nije.
Ovo je dooobro
Sjetio si me na mog Commodorea +4 koji nije bio ni za što drugo nego za strojni kod i basic 
))))))))) Mogu se pohvaliti čak i da sam bio godinama betatester, pa i osvojio nekoliko knjigica glavnog genijalca koji stoji iza tog projekta 
)))
A što se tiče razvoja softwarea, ja se za sada ipak postavljam kao naručitelj… i valjda programeri s kojima radim imaju najmanje problema… rijetko kada im dajem “genijalne ideje”
Ima tu i dobrih komentara. Kod dugotrajnih projekata se jako teško fokusirati na bit. Razvodni se taj fokus, jer ako nemaš sistemca sa vizijom, onda se kao kod slučajnog sađenja trave stvori cijela šuma, a svaka vlat ode na svoju stranu.
I klinci… Mastermind… pa zar još netko koristi Blender
Zvone…eto ti jedan savršen primjer, Blender. Nastao kao Linuxovo dijete. Pa kupljen od korporacije, a glavni programer kada je vidio dokle je to dovelo (i koliko je teško ratovati sa gomilom običnih plaćenika (programera) bez duše)… ponovno očistio kod, i osnovao nekakvu zakladu za razvoj
Ovaj blogec je bookmarkiran
OK Zvone, počeo si s ambicioznim pitanjem
Ali, to je pitanje koje nema odgovora jednostavno zato što je krivo postavljeno.
(Evo i duže verzije odgovora
Uh. Kako je to dobro rečeno – projekti ne uspjevaju jer su teški. Nevjerojatno kako jednostavno, a tako istinito. Nema tu velike filozofije. Napraviti nešto veliko iznimno je teško. I točka.