De ce e programarea grea?

As vrea sa subliniez ca nu trebuie neaparat pus semn egal intre manager si factor de decizie.

Apoi, despre practici "asa nu" s-ar putea da multe, multe exemple... Si nu neaparat despre firme de apartament, se practica la case mari de tot.

Nici nu am pus semnul egal. Totusi programatorii (experimentati) sunt cei mai in tema referitor la complexitatea software-ului, in timp ce managementul tinde sa faca presiuni asupra lor, deseori rezultand in subestimari grosolane.

IMO firmele mari sunt mai putin tentate de mitul falsei economii a programatorului ieftin si prost, fata de una de apartament. Insa nu este o regula, si nici nu am date/studii care sa dovedeasca asta.

 TS030, on 09 iunie 2013 - 19:40, said:

Programatorul care dă estimează în minus sub presiune e probabil începător şi îşi va înţelege foarte repede greşeala. Nu, cred că putem elimina cazul ăsta, orice programator cât de cât experimentat va estima instinctiv cu marjă de cel puţin +10%. Dacă cel care a cerut estimarea alege s-o ignore e problema lui şi chestiile de genul ăsta de obicei nu sfârşesc bine pentru el.

Dar de ce să umbli la estimările de dezvoltare când există metode mult mai simple de a obţine reduceri masive de timp? Elimini toate celelalte etape în afară de dezvoltare şi gata. Fără prototyping, fără testare, proiectare redusă la minimum (o face unul mai experimentat "din mers"). E mai simplu şi pentru estimarea costurilor, pentru că nu mai trebuie să-ţi baţi capul cu costuri colaterale pentru activităţi abstracte şi poţi estima direct la salariul programatorului pe unitate de timp. Ca la săpat de şanţuri, N oameni x H ore = M metri cubi.

TS030 said:

Nu cred că-i nicio diferenţă între o firmă de apartament şi una cu pedigri, dacă abordarea e tâmpită. În ambele cazuri echipele sunt de mărime similară sau se aplică formule de management din agricultură, ca mai sus.

Unii încearcă dar na, pana mea, şi managementul ăsta cere totuşi o abordare cultă şi experienţă, nu poţi să-l faci pe genunchi. Mie mi se pare o carieră cel puţin la fel de dificilă precum programarea, dacă nu şi mai dificilă, pentru că măcar calculatoarele sunt tâmpe şi fac doar ce le spui, oamenii sunt cei complicaţi.

Într-un fel e interesant să vezi ce specii de "agile" produc spontan firmele/echipele care încearcă (şi sunt lăsate) să facă ceva. Uneori se ating abordări chiar simpatice şi aproape-productive, precum  minimum viable product. Sigur, în absenţa unei metodologii corecte de dezvoltare software tot o ciorbă iese, dar măcar se încearcă integrarea ei cu restul prânzului.

Intre firmele mari si cele mici exista totusi o diferenta: cele mari au supravietuit suficient cat sa creasca

 m3th0dman, on 09 iunie 2013 - 11:59, said:

Meh. Fals. Sunt destule known-bugs ale unui processor cand se ajunge in faza de livrare.

Poate usor offtopic, se pare ca informatica e grea pentru multi care se apuca de ea... acu' cu agitatia despre bac am descoperit ca se pot vedea rezultate din anumiti ani trecuti si descoper cu stupoare ca majoritatea absolventilor de profil mate-info nu au curaj sa dea bacul la info ci mai degraba la biologie, chimie, fizica (din 34 de absolventi mate-info cat am numarat eu pana m-am plictisit, doar 5 au dat la info)... pt curiosi: http://examene.calif...2/B/page_1.html pe alta parte mi se pare foarte bizar... chiar asa de grea sa fie info pt. unii?

Edited by MrReason, 10 June 2013 - 00:53.

Majoritatea colegilor mei de la profilul info erau acolo pentru ca nu era nici uman nici real, nu pentru ca era info. Ideea era sa scape de latina si sa faca mai putina mate si fizica. Unii au dat din lac in put pentru ca nu aveau inclinatie spre info, dar de bine de rau s-au descurcat. Iar bacul l-a dat fiecare pe criterii proprii, unii la materii la care urmau oricum sa dea admiterea, altii la ce aveau chef. Ar trebui mentionat si ca pana la un moment dat info nu era materie eligibila pentru bac (nu stiu cum e acum). Si atunci ce putea alege unul care facuse info "pe bune"? Engleza? Deci nu te uita stramb la materiile de bac ca nu e neaparat logica pe care o crezi.

Exista "greu" si exista greu. Problema reala - nu vorbim de antitalente, genii neintelese si lenesi care nu invata pentru bac - este complexitatea, asa cum am spus mai devreme. Complexitatea asta face ca multe alte lucruri, precum codul prost scris sau "mici" schimbari sa aiba un cu totul alt impact decat cel la care s-ar astepta un outsider.
Ca sa revenim un pic si la intrebarea ta, programarea nu se preteaza la toceala si nici nu poti copia.

 The0nly0ne, on 09 iunie 2013 - 11:47, said:

Explica-mi si mie, faci hardware pentru software sau software pentru hardware?

Edited by MarianG, 10 June 2013 - 08:28.

De doi ani lucrez exact in contextul spus de initiator, numai ca rezultatele au fost exact pe dos: HW-ul a fost cel care, prin revizii succesive, a intarziat livrarea finala. Cheia este sa ai arhitecti foarte buni si cu multa experienta. Daca arhitectura software este corect gandita, exista o separare clara intre module, cu specificatii clar precizate si bine gandite, atunci sunt mici sanse ca proiectul sa fie fail, dpdv software, in ideea in care nu are componente sau constrangeri revolutionare ce nu au mai fost abordate niciodata. Ca exemplu pentru asta, in firma noastra, in proiectul embedded, s-au respectat aproape perfect estimarile in conditiile in care in timpul asta s-a scris de la 0 un RTOS complet si s-au dezvoltat si aplicatiile necesare pentru proiect. Asta cu doi seniori/arhitecti si 5 programatori juniori.

In contrast, s-au facut 7 revizii hardware, dintre care doar 1 sau 2 din cauza schimbarilor de specificatii. Partea rea la hardware este ca orice schimbare necesara, fie ca este facuta pentru a se remedia sau a se adauga ceva, dureaza cateva saptamani si costa sume importante de bani. In contrast, la software, daca ti-ai facut corect design-ul la inceput, cele mai multe lucruri le poti adauga fara un overhead costisitor.

 MrReason, on 10 iunie 2013 - 00:29, said:

E vorba mai mult de ceea ce vor urma. Cei care dau la medicina o sa sustina bacalaureatul la fizica sau chimie, in principiu. Cei care dau la Politehnica vor da bacalaureatul la fizica, deoarece se da admitere la fizica, iar cei care vor la drept/ASE, in marea majoritate a cazurilor dau la biologie.
Initial eu am vrut sa dau la informatica, insa am ales fizica, deoarece urma sa dau examen de admitere la fizica, iar subiectele de la bacalaureat de fizica iti acordau mai multa libertate in rezolvare decat cele de informatica.

 MarianG, on 10 iunie 2013 - 08:27, said:

DA!

Dacă-ți răspunzi singur la întrebarea: "Câți programatori încep lucrul la un proiect pornind de la o hârtie?", ai să afli răspunsul.

Edited by aeleden, 10 June 2013 - 15:59.

"The primary challenge of every software development team is to engineer the illusion of simplicity in the face of essential complexity."

 The0nly0ne, on 09 iunie 2013 - 10:38, said:

Scrierea de software inseamna sa ghicesti (sau sa cunosti) toate starile masinii pe care va rula programul tau. Asta inseamna, cu alte cuvinte, ca ai un automat cu un numar incredibil de mare de stari, si tu trebuie sa le tratezi pe toate, fara a afecta semnificativ performantele. Buffer overflow? Tre' sa prevezi. Date corupte la intrare? Prevezi. RAM corupt? Nimeni nu-si scrie software-ul cu asa ceva in minte, pentru ca e considerata o stare de exceptie, nu una in care programele ar trebui sa ruleze.

Pe scurt, scrierea de software e ca matematica pura daca vrei sa fii exact in ceea ce faci.

 Myrmidon, on 09 iunie 2013 - 22:44, said:

Depinde de procesor; putem lua ca exemplu clasic bugul FDIV din Pentium 1 care returna greșit o împărțire în virgulă flotantă din 9 miliarde și nu era aproape nimeni afectat. Inițial cei de la Intel n-au zis nimic deși știu, apoi s-a aflat și au zis că schimbă dacă pot userii dovedi că-s afectați de bug. Apoi a ajuns știre și au zis că le schimbă pe toate... datorită pierderii de imagine s-a estimat c-au pierdut aprox. juma de mld $, mult mai puțin decât dacă le-ar fi schimbat de prima dață și mult, mult, mult mai puțin decât dacă produsul nu s-ar fi lansat cu bug.
Nu cred că are rost să mai vorbim de procesoarele critical - mașini, medicină, avionics etc.

 m3th0dman, on 10 iunie 2013 - 18:44, said:

?

Quote

Si cam care ar fi procesoarele alea magice ?