Sumrak sw. industrije

Dimke ustao na levu nogu opet? :D

Ontopic: Prvo bih zamolio developere da razumeju da ne želim njihov software u mojoj startup listi (niti da se tamo opet samovoljno postave kada se ručno pokrenu), da ne želim njihovih 8 dodatnih ikonica u context menijima windowsa, da ne želim da mi trpaju kojekakve cfg, dll i ini fajlove u windows, system32 folder, da ne želim da instaliram fucking Ask toolbar (OK za freeware aplikacije, ali brate mili, Nero Trial - softver koji se plaća, mi nudi da instaliram Ask toolbar!) i sl. Takođe ne želim da imam 10 upgrade programa koji čekaju u pozadini da dobiju otvorenu vezu ka internetu kako bi počeli da sisaju još exe fajlova za update, niti da mi flash zauzima 80% CPU usage-a na 2.1GHz mašini zbog 2 flash reklame, a kamoli da mi Adobe Reader zabaguje ceo browser dok ne učita barem 50% PDF fajla. Gracias unapred. O ostalom ćemo kada se reši ovih par problema... ;)

Potpis

A man is smart. People are stupid.

@Nedeljko Tvoji stavovi nedvosmisleno pokazuju da si matematičar

Oduvek je postojalo prepucavanje između ETF-ovaca i PMF-ovaca. Mi, sa ETF-a kažemo da matematičari pišu softver koji daje tačne rezultate u beskonačnosti, dok nas uče da progrem treba da da rezultat za života programera koji ga je napisao.

Jedna anegdota koju nam je pričao profesor Jozo Dujmović

Jozo razgovara sa svojim kolegom sa PMF-a

Kolega: dođi do mene da vidiš moj novi Prolog interpreter.
Jozo: Odlično, dolazim, a odakle ti Prolog za PDP 11/70?
Kolega: Ma ja sam ga napisao!
Jozo: Strava, a u kom programskom jeziku?
Kolega: u LISP-u.
Jozo: A odakle ti LISP?
Kolega: Ma napisao sam ga u PL/I.
Jozo: Auuu, pa to mora da radi jako sporo....
Kolega: Nema veze, ako ti treba brži Prolog, kupi brži kompjuter...

Zabole me ko je sa kog fakulteta, ali stav koji si napisao zastupaju ljudi koji ne razumeju ulogu matematike. Gde to leba ti ima osnovu? U kojoj praksi? Matematičari pišu nezaustavljive programe(????????). Pa, i zaustavljivost programa i složenost izračunara su takođe matematički pojmovi. Bjarne Straustrup je matematičar. Donald Knut, poznat po nekim najefikasnijim mogućim algoritmima za ono što rade je matematičar. Ma, daj.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Jako cenim matematičare kada su u pitanju teorijski doprinosi programiranju.
Mislim da je Knut rekao jednom za jedan svoj softver (možda baš TeX, koji je dugo bio benčmark svim piscima Pascel kompajlera): "Ja ne kažem da je moj program ispravan, ja sam to dokazao"

Jedino što napadam u tvojim stavovima, da budem jasan, to je tvoja vizija da će u budućnosti korektnost programa biti dokazivana, a ne testirana. Možda, ali samo ako ga matematičari budu pisali i za to budu imali beskonačan broj matematičara i beskonačno vreme za pisanje...

Djoko, mislim da tu malo gresis, ali programi koji budu imali matematicku ispravnost zaista nebi imali potrebu da se stalno ispravljaju zato sto nesto ne funkcionise, jer vecina stvari bi se znala unapred. Mislim da tako moze da se odrede gomile mogucih flow putanja kojim bi program mogao da ide i samim tim unapred da se preduhitre mnoge potenciajlne greske, sto se danas radi u runtime-u.

@djoka_l

Nise stvar u tome da li neko ceni ili ne nekoga, već u tome koja je uloga matematike u drugim ljudskim delatnostima. Dakle, stvar je u tome šta se iz nje može korisno izvući.

Pa, ispravnost flipera ne mora da bude dokazivana, ali če ispravnost nečega trebati da bude dokazivana. Od nekih programa zavise lak i ljudski životi. U ostalim sferama je na korisniku da proceni koliko mu je bitna sigurnost, a koliko da ima gomilu opcija, za koje nikada i ne sazna.

Da, AutoCAD nikada nije mogao da bude napisan, jer su za to bili potrebno beskonačno vreme i beskonačno mnogo programera. Ma, daj molim te, pozdravi svoje profesore, a mene mani tih priča.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Pokušao sam da pronađem citat koji sam imao na umu, ali mi ne uspeva. Zato ću ovo reći na pamet, a ako neko može da navede izvor, neka me ispravi.

Ovu krizu sw industrije vidim kao prirodan ciklus u ekonomiji. Mislim da sam u nekoj knjizi Pitera Drakera video analizu u kojem on identifikuje stepenice u razvoju nekog proizvoda:

1. Inovacija: neko izbaci potpuno novi proizvod koji nema konkurenciju na tržištu.
2. Imitacija: masa proizvođača ponudi kopiju novog proizvoda sa sličnim karakteristikama
3. Zreo proizvod: Na tržištu opstaje deo proizvođača koji su u stanju a izbace sličan proizvod sa sličnim cenama i sličnim performansama.
4. Integracija: novi proizvod više nije nov, pa počinje da se pakuje čime mu se dodaju karakteristike koje nije imao originalni proizvod. Na primeru vokmena - na početku je mogao samo da reprodukuje muziku kada ga je Sony izbacio na tržište. Dok nije nestao sa tržišta dodat mu je FM/AM prijemnik, diktafon, sat, budilnik...

Situacija na tržištu sw je sada da je većina komercijalnog softvera stigla u poslednju fazu. Sada, na primer, teško može da se proda procesor teksta kao posebna komponenta. Jedino prolaze na tržištu sw office paketi u koje je spakovan tekst procesor, spreadsheet, baza podaka, spellin checker, mail klijent...

Po toj priči bi trebalo da su proizvođači u frci, a korisnici prezadovoljni. Pročitaj inicijalni post, pa vidi gde imaš bezbednosne propuste.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Ima i drugi deo priče o ovim fazama.
U vreme inovacije, prvi proizvođač može slobodno da odredi cenu. Pojavom imitatora cena pada i ostaje niska u ostalim fazama. Na kraju, kada dobiješ proizvod tipa 3 u 1 nikada nemaš isti kvalitet kao kada bi imao tri posebna proizvoda.

Evo nešto sa mog razvojnog servera. Ovo je samo deo softvera (procedure u bazi) dok je ceo paket mnogo veći.
Koliko bi trebalo vremena da se matematički dokaže da je ovih 4.5 miliona linija PL/SQL koda ispravno...

Uz odgovarajuci algoritam i hardware vrlo malo...

Koliko programer godina treba da se napiše tig 4.5 miliona linija? Dok kucaš linije, kucaš i formulacije onoga što bi one trebale da zadovoljavaju isto kao što bi pisao testove. Koliko programer godina treba da se napišu testovi za tih 4.5 miliona linija?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Evo druge matematike: 100 programera dobijaju mesečno 600 zahteva za izmenom funkcionalnosti. U proseku, po jednom zahtevu programer ima vremena 3-4 dana da uradi analizu, napiše novu specifikaciju, izmeni korisničko uputstvo, napiše program. uradi unit test, da QA izvrši integracioni test, da se rešenje implementira i da se uradi test implementacije, a onda da se uradi regresioni test...

Pa?

Interesantno mi je to da se taskovi odrede raspodele i onda se uradi estimacija koliko ce sve to da traje. Sta ako estimacija nije tacna, mislim ako managment trazi neki feature i traze u nekom razumnom roku (razumnom za njih) da se uradi nesto to ne znaci da je i moguce. Pa bas me briga sto imam 3, 4 dana da uradim nesto, ako je to nemoguce onda je nemoguce, tu ne pomaze direktiva, nego vreme i ponovo analiza.

@negyxo I ti si neki teoretičar? Da li održavaš softver koji ima 650 komponenti sa 25,000 modula? Inženjer ima tri varijable sa kojima računa: cilj zadatka, vreme i cenu. Mogu je da pišem teoreme i dokazujem da je softver matematički korektan, ali koilko mi vremena za to treba i za koje pare to mogu da prodam. Kada izađete iz kule od slonovače, onda shvatite da se za ograničeno vreme i sa ograničenim sredstvima ne može postići savršeni kvalitet.

Evo problema. Otkad programeri sve ovo rade?! Pa šta onda imaš za posledicu poslije ovakvog završenog posla? Niti program radi, niti je testiran kvalitetno, niti imaš valjan QA, niti korisničko uputstvo...

Potpis

I ♥ ♀

Ovaj post je zlata vrijedan!

Ne nego radim na projektu koji je presao sa desetine hiljada linija koda na stotine a kada je i to postalo malo sada se broji u milionima

Ja ovo pricam bas zato da ovakve stvari ne bi postojale. Gde imas par miliona linija napisanog code-a koji niko ne zna sta radi. Svi po malo dodaju i testiraju. Lepo je to, zatvoris se u svoj kontekst i samo skidas task sa sebe i teras dalje. E vidis, ja jedva cekam dan kada ce kompjuteri kroz razne alate moci da verifikuju ispravnost code-a, pa da vidim onda iracinoalne stavove "moze to tako".

Evo ti jedan link, bar da vidis o cemu se radi, nadam se da ces shvatiti.

http://blogs.msdn.com/cyrusn/archive/2005/04/27/412444.aspx

Procitaj i komentare. Interesntno mi je to sto se neki kunu da im je bolje da znaju za gresku u runtime-u nego za vreme compile time, ej a nikakvog argumenta!

Da se vratim na temu, nema smisla razgovarati o matematici i paskalu.

Nije to samo sumrak software industrije nego globalne ekonomije.

Sve je posledica "amerikanizacije" svijeta tj. ovog wild-west kapitalizma u kome je u prvom, ponekad i jedinom, cilju izbaciti proizvod na market. Za kvalitet, korisnost, lakocu upotrebe, resource management i ostale nekada vazne stavke se brine naknadno, naravno samo ako se musterija izdere dovoljno jako da kompanija procjeni da ce da je izgubi ako nesto ne promjeni.
Ako imas monopol, ne moras da brines ni za to, samo izbacuj i po 20+ razlicitih proizvoda u istoj liniji :)

Sto se tice bloatware-a, mislim da se tu malo pretjeruje. Adobe PDF reader je definitivno jedan od najgorih slucajeva ali ne bi taj primjer koristio da opisem vecinu softvera kao bloated. Da, 99% korisnika je potreban samo light-weight reader da jednostavno otvore pdf fajl i to je to a ne da download-uju AIR i jos gomilu kojekakvih budalastina ali kada se radi o ERP sistemima i nekim malo vecim projektima koji su namenjeni kompanijama, rijetko cete naci bas tako ekstreman primjer, sa sve Adobe Acrobat SpeedUp u startup-u :)

U ovakvoj ekonomiji, ne samo softverskoj industriji, non-stop dolazi do ukrupnjavanja, ima par ogromnih (ginarmous?) kompanija koje vedre i oblace, kad neko digne glavu ili ga otkupe ili poklope nekim smijesnim (patent) tuzbama ili EULA glupostima. Tih par velikih igraca odredjuju sta i kako, nama ostalima ostaje da se kao suncokreti prilagodjavamo, nadajuci se da cemo jednog dana biti u stanju nesto promjeniti.

Neko je napomenuo nedostatak kvalitetnih programera. Ovo je na zalost velika istina a problem je sto moze da bude samo gore. Trenutna fabricka proizvodnja je u neprekidnoj potrebi za automatizacijom i robotizacijom, kompjuteri zamjenjuju radnu snagu ali jednostavno ne postoji XXXX broj programera koji su spremni da isprate to. Dolazi do losijeg kvaliteta i svega o cemu smo vec pricali, svako se zamajava da moze da dizajnira i programira aplikacije, ponekad i mission-critical.

Dobro bi bilo da je problem samo u softverskoj industriji, on je mozda izrazeniji tu za nas koji smo u svemu tome ali je itekako prisutan u cijeloj ekonomiji i uopste, u drustvu.

Da ne pominjemo moralni sunovrat, big brother/celebritism, lazne vrijednosti (cash is king) itd itd.

Tema je dobra ali zaista mislim da nije problem samo u softveru nego i u ostatku i ima mnogo dublje korjene.


Pokusacu posle da pronadjem par linkova, imao sam ranije priliku da procitam par disertacija na tu temu.

Potpis

http://www.pro-transport.com - The most advanced trucking software on the market

Ja ne smatram da sam izašao iz okvira teme, jer se raspravlja o rešenju problema sa početka teme.



Ovde je potpuno nejasno šta je pisac hteo da kaže.



Ma, nemoj. Ti si ovde jedini softveraš, a svi ostali su "teoretičari". Kad si već pomenuo teoriju, čemu ona uopšte služi? Je li to neko tupljenje profesora za gnjavažu studenata ili ima neki značaj i koji? Neću biti zadovoljan odgovorom "da, naravno da ima", a da ne kažeš u čemu je značaj. Želim obrazložen odgovor.

Kada već pričaš o vremenu, šta ćemo sa ovim



Dakle, koliko je vremena potrebno za zadatke koji su označeni zacrnjenim slovima? Sve to se zamenjuje novom metodologijom. Dakle, nema samo novog posla, već neki stari poslovi otpadaju. Dakle, neki stari poslovi se zamenjuju novim, kao kada kupiš kombajn - nećeš više raditi ono što kombajn radi, ali ćeš imati nove probleme (kombajnu pukne guma npr.). E, kad se sve sabere i oduzme, onda se vidi da li je nabavka kombajna isplativa ili ne.

Što se pisanja specifikacija tiče, upravo je to ono što treba zapravo da uradiš u novoj metodologiji, samo što će ovaj put ta specifikacija biti mašinski čitljiva i podesna za automatsku obradu. Dakle, do sada si pisao specifikacije čitljive za čoveka, a sada specifikacije čitljive mašini i čitljive čoveku onoliko koliko je izvorni kod softvera čitljiv čoveku. Ne, kažem, ostaje potreba za specifikacijama samo za ljude, tako da sam u tom smislu preterao. U ostalom ne.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Samo da se nadovezem na Nedeljka ovde.

Upravo je ovo poenta, pisanje code-a koji ce sam kompajler, tool,whatever razumeti, jer na taj nacin onda programeri dobijaju big brother-a koji ce kontrolisati sve moguce putanje izvrsavanja (i tu dolazi na scenu matematika) i ukazivati na greske i nelogicnosti. Do sada su programeri pisali mnogo implicitnog code-a, tj. ako je nesto pisalo u specifikaciji onda je to pretoceno na code iz koga, uglavnom, je bilo tesko razumeti specifikaciju, programer recimo implicitno zna da je Person.Age > 0, ali to striktno analizirajuci software se ne vidi.

Sorry, malo sam zarđao u matematici, ali mi se čini da predikatski račun prvog reda nije odlučiv (ili kompletan ili šta već) tako da ne može svaki iskaz da se proveri. Kako bi onda funkcionisalo opisivanje programa predikatskim računom i njegovo dokazivanje? Unapred se izvinjavam ako sam nešto lupio, pitanje je da li zaista postoji matematički metod kojim se može testirati program, a koji radi za bilo koju realnu kompleksnost programa...