Software projekt planer og parallel processering viser mange fælles træk. Feks skrev Amdahl i 1960’erne Amdahls lov, som på viser at de fleste algoritmer ikke opnår en lineær forbedring i køretid ved en tilsvarende stigning i antallet af processerings elementer. Altså en dobbelt så hurtigt CPU, udfører ikke algoritmen dobbelt så hurtigt – i mange tilfælde i det mindste.
I 1975 fik vi så brooks’s lov, som sagde ”tilføjelse af ressourcer til et forsinket software projekt gør det mere forsinket.
Egentlig udtaler de sig om det samme. Nemlig det faktum at der er afhængigheder i software, og at uanset hvad du finder på, kan du ikke optimere din plan ud over den kritiske sti, nemlig den tid det tager at skrive det stykke software som ikke kan paralleliseres i sin udførsel. Vores byggesten har i mange år været de samme, filer der kompileres – kalder hinanden på kryds og tværs og til sidst udgør et hele med den ønskede funktionalitet. Disse filer er en slags atomer, som på sin vis bliver det mindste det giver mening at arbejde på, for et menneske. Man har prøvet at lade flere mennesker arbejde på den samme fil, men det viser sig for det meste, at tiden med at koordinere arbejdet bliver højere end selve det at skrive softwaren. Størrelsen af atomerne i vores tilfælde filerne er delt op efter funktionalitet, hvad enten vi udvikler objekt orienteret eller i ren c. Funktionaliteten kommer fra beskrivelsen af domænet, altså virkeligheden.
Gustavsons lov fra 1988 redede parallel algoritmerne, og viste at jo der var noget at hente, hvis bare der var data nok at arbejde med. Men det reder desværre ikke vores projekt planer. Men den beviser at man lige så godt kan udvikle mere funktionalitet i den tid der alligevel bliver brugt på at udvikle den sekventielle del. Selvfølgelig forudsat at de ingen afhængigheder har til resultatet af den sekventielle del og dermed bidrage til et bedre og mere rigt produkt.
Netop derfor er vi glade når vi ser en software arkitektur som udgør et framework. Når først vi har et framework kan vi nemlig begynde at parallelisere vores opgaver i det uendelige. Web services er et godt eksempel – på hvordan alle glæder sig til at ”bare” at skulle lave nye services til et eksisterende framework og lave en mashup der trækker på de services der er nødvendige. Der er ikke noget nyt i det, ud over at vi går imod en større standardisering af vores løsninger, nemlig et fælles framework for hele verden. Men der er stadig afhængigheder mellem vores mash up og vores services, præcis som der altid har været, og vi skal stadig definere vores services, men vi bruger det som en IASP.
Nogle vil måske sige, hvad så med kreativiteten? – tja hvad skete der med industrien da man fik standarder på bolte, møtrikker og skruer? Jeg tror ikke man kan sige at den blev mindre kreativ, og materialerne bliver bedre og bedre og opfindelserne ikke mindre.
Ingen kommentarer:
Send en kommentar