Dacă am definit o problemă bună, soluţia optimă obţinută este cea mai bună, în sensul că maximizează bine ceva sau minimizează bine ceva.
Dacă problema a fost prost definită, vom obţine o soluţie optimimă care maximizează prost ceva sau minimizează prost ceva.
Voi da trei exemple ca să vă tăvăliţi pe jos de râs.
Exemplul nr. 1: unii doreau să optimizeze transportul de sfeclă, folosind algoritmul clasic al problemei de transport. Ei au zis că transportul către fabricile de zahăr se face cu trenul. Pe hârtie soluţia optimă era superbă. Realitatea a generat situaţii conform cărora transportul a impus ca sfecla de la vagoane să fie dusă cu tractoarele la fabrică pentru că nicio fabrică de zahăr nu avea linie ferată internă. Au apărut şi situaţii în care sfecla nu a mai fost luată din apropiere, ci de la distanţe mari. Per total, cheltuielile cu transportul au depăşit cu mult cheltuielile care se făceau înainte de optimizare. S-a optimizat o problemă care nu avea nicio legătură cu cea ce se petrecea pe teren. Ha, ha, ha.
Exemplul nr.2: un tip obraznic şi lăudăros a zis că se ocupă el de creşterea producţiei la o mare uzină de maşini. S-a dus pe teren, a luat durate de operaţii, a luat fond de timp, a făcut un model de programare liniară şi a rezultat că producţia creştea de vreo 5 ori, ceea ce i-a făcut pe cei din uzină să rămână cu gura căscată. Respectivul,
- nu luase în calcul duminicile,
- considera că utilajele lucrează 24/24 fără reparaţii,
- piesele nu au timpi tehnologici de pregătire,
- muncitorii nu au pauză de masă,
- uitase că algoritmul simplex este pe continuu, programarea numere întregi este altceva.
Simplismul de o vulgaritate rar întâlnită l-a pus pe tip într-o postură extrem de nefavorabilă, deşi multe dintre lucruri i s-au spus când a mers să publice un articol, căci prostul dacă nu este fudul, nu e prost destul.
Exemplul nr.3: viza optimizarea transportului pe conducte a produselor petroliere. Cel care se ocupa de modelare era un tip teoretician care nu se cobora să stea de vorbă cu cei din producţie, aşa cum nu discuta nici cu colegii săi. A făcut un model superb. A dat o soluţie şi când s-a trecut la experimente s-a dovedit că este o catastrofă, doar din faptul că pe conducte când se schimbă transportul de combustibil, o cantitate destul de importantă este contaminată şi pentru a reduce pierderile, schimbarea de sortimente nu se face cum zice soluţia optimă care nu ia în calcul contaminarea, ci cu totul altcumva.
Calitatea optimizării nu trebuie luată în derâdere câtuşi de puţin dacă cei ce optimizează la nivelul de producţie software sunt cu capul pe umeri şi fac lucrule aşa cum trebuie, fără a privi simplist problema de rezolvat. Dacă de folosesc algoritmii euristici şi se pleacă de la variante, se obţine o soluţie mai bună decât soluţia cu care se pornise iniţial. Am mai zis eu undeva că este bine să vorbim despre îmbunătăţirea calităţii şi nu despre optimizare.
Dacă vorbim despre optimizare, calitatea optimizării depinde de:
- sistemul de ipoteze de la care se porneşte,
- anvergura procesului, căci una este lucru pe textul sursă şi alta pe tot ciclul de dezvoltare,
- timpul necesar pentru a construi variante şi a selecta pe aceea care se dovedeşte mai bună,
- capacitatea echipei de a propaga experienţa pozitivă şi controlul evoluţiilor pozitive.
După părerea mea, trebuie început cu lucruri mici şi treptat-treptate trebuie avansat pentru a obţine performanţă sporită. Ambiţia de a porni cu mai multe funcţii obiectiv în paralel, este cotra-productivă şi de aceea a urmări maximizarea duratei de execuţie este suficientă.