Mikroprocessoren fylder 40 år: En snegl på 108 kilohertz

Intel skabte den første mikroprocessor den 15. november 1971, og i de efterfølgende 40 år har mikroprocessorerne udviklet sig eksponentielt.

I dag den 15. november, er det præcis 40 år siden, at den første mikroprocessor så dagens lys hos Intel lidt syd for San Francisco i det område, som i dag bedst er kendt som Silicon Valley, opkaldt efter netop mikroprocessoren.

Intels 4004 var reelt blot en kompakt regnemaskine, men teknologien har siden udviklet sig eksponentielt.

Den allerførste 4004 havde eksempelvis blot en clockfrekvens på 108 kilohertz ifølge Intel. I dag kan Intels processorer køre med over 4 gigahertz, altså en 40.000 gange højere frekvens.

4004 var mest en vigtig milepæl, fordi den var den første. De første kommercielle udgaver af 4004-processoren blev hovedsageligt brugt til at styre automatiske systemer som benzinpumper og lyssignaler.

4004 var avanceret efter datidens standarder med hele 2.300 transistorer klemt ned på en enkelt chip. Intel-ingeniør og medstifter Gordon Moore havde dog allerede i 1965 forudset, at det ville gå meget stærkt med at gøre mikroprocessorerne kraftigere.

Den berømte Moores Lov forudså, at antallet af transistorer på en chip ville blive fordoblet cirka hvert andet år.

Det gik ikke helt så hurtigt fra 1971 til 1974, hvor Intel introducerede 8080-processoren med 4.500 transistorer, men allerede i 1978 tog det for alvor fart med 8086-processoren med 29.000 transistorer.

Siden da er den eksponentielle vækst forsat. En pc-processor har i dag cirka én milliard transistorer.

Udfordringen var ikke blot at tilføje flere transistorer, men at blive ved med at presse fremstillingsteknologien, så transistorerne og ledningsbanerne på processorerne hele tiden blev mindre.

I 1971 arbejdede Intel med en skala på 10 mikrometer. Det var allerede et kæmpe spring, fra den første transistor var blevet skabt i 1947 på Bell Labs, som var så stor, at den blev samlet i hånden. I 2011 fremstiller Intel processorer på en skala på 32 nanometer.

Hvis en moderne pc-processor skulle have været fremstillet med samme teknologi som i 1971, ville den fylde et areal på 21 kvadratmeter.

Tilsammen betyder forbedringerne i mikroprocessorerne, at en moderne processor i forhold til 4004 er som sprinteren Usain Bolt i forhold til en snegl ifølge Intel.

I de 40 år, siden Intel første gang satte strøm til mikroprocessoren, har den haft enorm indflydelse på verden. Den gjorde computerkraft billigere og mere kompakt, og dermed kunne teknologien bruges overalt.

Der sidder i dag op til et halvt hundrede mikroprocessorer i en moderne bil, ligesom man finder dem i alt fra vaskemaskiner til lokomotiver og fra mobiltelefoner til MR-scannere.

Mikroprocessoren betød, at regnekraft ikke var noget, der var forbeholdt en stor, dyr kasse i maskinstuen hos regeringer og store virksomheder, men kunne ligge i skoletasken hos ethvert skolebarn.

Samtidig gjorde mikroprocessoren det også muligt at samle hidtil usete mængder computerkraft i ét samlet system og med tiden gøre det muligt at kortlægge menneskets gener og erstatte de atomprøvesprængninger, som mange protesterede over i 1971, med mere fredelige simuleringer af atombomber i bit-form.

Mikroprocessoren har dog også skabt sine egne problemer. Den hurtige udvikling betød, at mængden af elektronikskrot også er vokset eksponentielt, og der er dem, der hævder, at den moderne smartphone ikke har gjort noget godt for kommunikationen mellem mennesker.

Igennem 40 år har der siddet mikroprocessorer i næsten enhver ny teknisk opfindelse, og mulighederne for at bruge dem til eksempelvis at bygge stadig mere avancerede robotter, som kan hjælpe os, er ved at blive tydelige for enhver. I 1971 var en robot, der kunne støvsuge huset, ren science fiction.

Mikroprocessoren står også over for nye udfordringer. Intel og andre chipproducenter har en køreplan for at komme ned på 22, 18 og 14 nanometer, men derfra begynder ingeniørerne for alvor at løbe ind i kvantefysiske benspænd og finurligheder.

Hidtil er det lykkedes at overvinde udfordringerne med nye materialer og fremstillingsmetoder, men det er usikkert, om Moores Lov holder de næste 40 år.

Intel har dog også andre planer for fremtiden end blot at presse flere transistorer ned på en chip. Eksempelvis har de seneste år været præget af, at alle chipproducenterne har forsøgt at reducere den mængde strøm, som mikroprocessorerne skal bruge på en udregning. Selv hvis mikroprocessoren skulle ramme en kvantemekanisk mur, så er energiforbruget et område, som stadig kan forbedres.

Intel forventer eksempelvis over de næste 10 år at kunne forbedre energiforbruget pr. beregning med en faktor 300.

Vi kommer også til at se flere specialiserede processorer arbejde sammen. Allerede i dag indeholder en mikroprocessor flere specialiserede processorer, som egner sig til hver deres formål, hvad enten det er klassiske flydende kommatalsberegninger, flytning af data i hukommelsen eller vektorberegninger.

Hvis vi har lært noget af de sidste 40 år, så er det dog, at det er nærmest umuligt at forudsige, hvad en teknologi som mikroprocessoren vil blive brugt til i fremtiden, så længe regnekraften vokser eksponentielt. Når prisen på en regnekraft, som i dag kun findes i verdens kraftigste supercomputere, en dag koster så lidt, at alle har råd til den, vil det sætte gang i nye idéer til, hvad regnekraften kan bruges til.

Læs også Poul-Henning Kamps blogindlæg om 40-års fødselaren på ing.dk

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jens Madsen

Nutidens processorer er blevet hurtigere, fordi transistorerne er mindre, og kapaciteterne er mindre. En mindre transistor, kan arbejde hurtigere. Antallet af transistorer, har ikke betydet meget for klokhastigheden - men et stort transistorantal, kan dog klemme hastigheden en smule op.

Idag er processorerne 40.000 gange hurtigere. Selve elektronikken er blevet mindst 1000 gange hurtigere, på grund af de mindre transistorer. Det betyder, at processorerne selv, højst er blevet 40 gange hurtigere, grundet deres flere transistorer.

Umiddelbart skulle vi så tro, at så hurtigere processorer havde givet os en masse. Men sådan er det desværre ikke. Problemer kan normalt deles op i to typer: Løselige, og uløselige. De løselige problemer er stadigt de eneste der kan løses.

Derimod, har de hurtigere processorer, givet os en del mere ineffektiv kodning, og i nogle tilfælde, har det enda medført, at algorithmernes store O funktion er blevet dårligere, fordi det nu, er muligt at klare problemer der er store nok, med en dårligere store O funktion. Eller, med andre ord, så kan computeren ofte løse færre problemer end tidligere.

Den større hastighed, har primært betydet noget for grafik. Tidligere, var kun muligt med tekstbaserede computere, og simpel langsom vektorgrafik. Idag, har vi 3D grafik, raytracing, og mulighed for at kunne emulere virkligheden godt.

Jonas Høgh

Derimod, har de hurtigere processorer, givet os en del mere ineffektiv kodning, og i nogle tilfælde, har det enda medført, at algorithmernes store O funktion er blevet dårligere, fordi det nu, er muligt at klare problemer der er store nok, med en dårligere store O funktion. Eller, med andre ord, så kan computeren ofte løse færre problemer end tidligere.

Vrøvl. Hvis alle problemer skulle løses indenfor samme effektivitetskrav som før 40 år siden, ville langt de fleste der ernærer sig som programmører ikke have en chance for at være med. Og dermed ville masser af problemer ikke være løst, selvom de måske ikke blev løst optimalt.

Christian Nobel

Vrøvl. Hvis alle problemer skulle løses indenfor samme effektivitetskrav som før 40 år siden, ville langt de fleste der ernærer sig som programmører ikke have en chance for at være med. Og dermed ville masser af problemer ikke være løst, selvom de måske ikke blev løst optimalt.

Og så er sandheden nok nærmere et sted midt i mellem.

Rigtig megen programmering der laves nu om dage er alt, alt for ringe, hvorved man slet ikke udnytter de kræfter der i virkelig er i hardwaren.

Det kan ses på programmer der er 100 gange større end de var for ikke så mange år siden, uden de på nogen måde er blevet 100 gange bedre eller bare tilnærmelsesvis hurtigere, trods den 10000 gange kraftigere hardware.

Eller operativsystemer der jo egentlig burde kunne være instant on.

Der er mange ting der går galt, det være sig bevidstløs programmering med afsæt en et kæmpe overhead framework som f.eks. .Net, eller generelt dårlig programmering hvor man ikke engang imellem vasker tavlen ren, men bare læsser mere og mere på.

Eller det kan være det hvor der skal laves en relativ simpel embedded opgave, hvor man gud døde mig benytter et fuldt OS som Windows, inklusive 7 kabale for bare at lave en informationstavle.

Etc. etc.

Christian Nobel

Jeg mener bare at fordelene ved hurtigere hardware langt overstiger ulemperne ved den øgede "bloat".

Hvilket ud fra et sikkerheds og performance mæssigt synspunkt er en farlig vej at gå, bare at acceptere bloat fordi det gør ting nemmere.

Og hvis fordelen er, at en række amatører nemmere kan skrue noget spagetti kode sammen, så anser jeg ikke det som nogen gevinst.

Bevares, selvfølgelig skal man da have (og har også fået) gode udviklingsværktøjer, da en god compiler som regel gør et bedre arbejde end hvis man prøver at lave alting i maskinkode selv.

Det er ikke der jeg vil hen, men jeg vil absolut forholde mig til at "bloat" og lap-på-lap programmering er et kæmpe problem, hvor mange har mistet klarsynet.

Og det giver sig så til udtryk i de produkter hvor en "Hello World" på et LCD display bagved er sovset ind i et 200Mbyte framework - se f.eks. bankautomater som efter at være gået over til Windows er blevet 3 gange langsommere, eller Q8/F24's benzinautomater som er helt til grin.

Christian Nobel

Hvis ikke det var for hardwareudviklingen ville der slet ikke være noget der hed en bankautomat

Øhh jeg siger ikke at hardwareudviklingen er noget negativt, og jeg siger heller ikke at den ikke skulle være der.

Men det jeg siger er i al sin enkelthed, at der laves for meget dårlig programmering, fordi mange (ikke alle) programmører er dovne/inkompetente/ligeglade/... og derfor forfalder til at lade den hurtige/kraftige hardware kompensere for egen ineffektivitet og manglende kvalitet - og jeg vil gerne indrømme at jeg vil på ingen måde stille mig op på en piedestal, for jeg kan også selv falde i den gryde, så det er mere en konstatering af hvordan vi slet ikke udnytter hardwaren godt nok.

Og når man ser hvor meget Nasa i sin tid kunne vride ud af AGC'en, så tror jeg såmænd nok at vi selv med meget mere beskeden hardware alligevel havde fået bankautomater - og der ville næppe være færre udviklere, nok nærmere flere.

så jeg kan godt leve med at det tager 3 min. i stedet for 1 fordi en klaphat har installeret windows på dem.

Se der er jeg så slet ikke enig - dels er det p.. irriterende at vente, bare fordi softwaren og ikke mekanikken snegler sig afsted, dels kan det gøre mig nervøs fordi jeg kan betvivle sikkerheden i løsningen.

Jens Madsen

Bankautomater kørte med Christian Rovsings gamle computere, op til slutningen af 80'erne. Og det fungerede fint. Faktisk så fint, at man var meget nervøs ved at udskifte det. Der hvor udviklingen har givet noget, er primært indenfor grafikområdet. De fleste andre typer opgaver, f.eks. databaser ol. behøver stort set ikke computerkraft - derimod er harddiskens hastighed, og ofte også rammens størrelse vigtigt, for denne typer af opgaver.

Førhen, var det nødvendigt at overveje kompleksiteten af den software man udviklede, og det betød at der ikke var plads til programmørerne som bare var ligeglade. Enhver rutine og funktion, skulle svare indenfor relativ kort tid. Alt, skulle overvejes, ned i de mindste detaljer, for at gå op, kunne fungere hurtigt og effektivt. Store O funktioner var i fokus, og applikationerne blev udviklet til, at have et veldeffineret og besvisbart hukommelsesforbrug. Idag, er store O funktioner, måske ikke ukendte for programmører, men er noget der ikke bruges i praksis og betragtes akademisk for flertallet af programmører. Og ramforbrugets størrelse, som funktion af en opgaves kompleksitet, siger ikke programmørerne noget. Ram er der nok af. Mange programmører bruger ingen resourcer for at undersøge deres softwares forbrug af resourcer, og kan ikke opskrive ramforbruget, som funktion af opgavens parametre. Man har den opfattelse, at der jo nok kommer nogen der ryder op på et tidspunkt, eller også swappes det bare ud på harddisken, og så er det jo af vejen. Ellers, kan nok indstalleres en rengørringsassistent app. Så det er ikke noget, at bruge tiden på.

Jonas Høgh

Bankautomater kørte med Christian Rovsings gamle computere, op til slutningen af 80'erne. Og det fungerede fint. Faktisk så fint, at man var meget nervøs ved at udskifte det.


Tak, jeg er udmærket klar over vi har haft bankautomater i mange år. Jeg talte om udviklingen generelt. Ifølge en hurtig googlesøgning kom de første prototyper på bankautomater i slutningen af 60'erne, men de blev ikke "hvermandseje" med det samme. Men du kan måske sætte et årstal på, hvornår udviklingen skulle have stoppet, hvis du synes hurtigere CPU'er er en dårlig ting?

Førhen, var det nødvendigt at overveje kompleksiteten af den software man udviklede, og det betød at der ikke var plads til programmørerne som bare var ligeglade.

Det er ikke programmørerne, der er ligeglade. Det er deres chefer, der ikke prioriterer performance, fordi der er efterspørgsel efter softwaren alligevel. Og det er en god ting for alle set fra et økonomisk perspektiv. Markedet er blevet så meget større siden dengang, hvor det bogstaveligt talt var "rocket science" at programmere noget der i dag er langt mindre end en lommeregner, til at sende mennesker til månen.

Det hjælper ikke at ønske sig tilbage til dengang hvor alt software var skrevet af super hardcore eksperter. Der er alt for stor efterspørgsel efter software til at det kan lade sig gøre. Og vi skal være rigtig glade for at hardwareudviklerne har givet os værktøjerne til, at flere programmører kan være med. Ellers ville vi simpelthen være meget fattigere.

Jonas Høgh

Misforstår du med vilje?


Du har entydigt sagt, at hardwareudviklingen ikke er noget negativt, det har jeg ikke misforstået. Jens har derimod skrevet at "computeren ofte kan løse færre problemer end tidligere".

Har du noget empirisk bevis for det?


Nej, har du et for, at der ville være flere udviklere hvis hardware udviklingen havde været langsommere? (Jvf følgende citat:)

Og når man ser hvor meget Nasa i sin tid kunne vride ud af AGC'en, så tror jeg såmænd nok at vi selv med meget mere beskeden hardware alligevel havde fået bankautomater - og der ville næppe være færre udviklere, nok nærmere flere.

Christian Nobel

Nej, har du et for, at der ville være flere udviklere hvis hardware udviklingen havde været langsommere? (Jvf følgende citat:)

Nej, for det det drejer sig om er at der er et givent behov der skal opfyldes over tid, så mængden ville være mere eller mindre den samme.

I øvrigt dårlig karma at besvare et spørgsmål med et spørgsmål.

Og så bliver du ved med at køre i ring om at hardware udviklingen skulle være langsommere, men det er ikke det det drejer sig om, men at håndværket IMO er blevet (relativt) for dårligt.

Nikolaj Brinch Jørgensen

Det er ikke der jeg vil hen, men jeg vil absolut forholde mig til at "bloat" og lap-på-lap programmering er et kæmpe problem, hvor mange har mistet klarsynet.


Ja men dette er ofte et ledelsesproblem mere end det er relateret til noget der har med hardware og/eller software at gøre. Det er umuligt at lære, hvis man ikke må.
De projekter (og det er rigtigt mange) jeg kommer på, har rigtig meget af den kode du beskriver, der er så dårlig at det skriger til himlen. Det kan jeg se, og der er altid en del mennesker på projekterne der også kan se det, har set det, og har gjort opmærksom på det. Men der er ikke ledelsesopbakning til at få det ordnet.
Istedet "sparker man en død hval hen ad stranden" i et forsøg på at få monstret i luften, og bruger en hel masse energi på at kode udenom de fejl og spaghetti man selv har fremstillet.

Så du har en rigtig god pointe, en masse af den kode som i dag produceres kan slettes, og erstattes af meget mindre kode som gør det samme meget bedre.
Om det er hardware accelerationen der har medført, at verden er gået den vej ved jeg ikke, det er nok et sted midt i mellem, som du siger. Men fakta er, at der skrives rigtig meget rigtig dårlig kode, som aldrig skulle være skrevet, og refaktorering er den bekendte by i Rusland rigtig mange steder.

Nikolaj Brinch Jørgensen

Og når man ser hvor meget Nasa i sin tid kunne vride ud af AGC'en, så tror jeg såmænd nok at vi selv med meget mere beskeden hardware alligevel havde fået bankautomater - og der ville næppe være færre udviklere, nok nærmere flere.


En bankautomat skulle vel kunne kører fint på en C=64?

Men der er værd at overveje, hvor meget der skal bitnusses i forhold til bare at smide hardware efter problemet. Det må blive en afvejning af hvad der er billigst. I offshore sammenhænge, burde det være billigst at bitnusse, men det er så der hvor man, efter min erfaring, får den absolut ringeste kode fra - så man skal nok passe på med enten af offshore, eller lade dem nusse for meget.

Nikolaj Brinch Jørgensen

De fleste andre typer opgaver, f.eks. databaser ol. behøver stort set ikke computerkraft - derimod er harddiskens hastighed, og ofte også rammens størrelse vigtigt, for denne typer af opgaver.


Databaser behøver da i den grad computerkraft. Enten sidder du med meget små datamængder, eller også ved jeg reelt ikke hvad du baserer denne udtalelse på?

at algorithmernes store O funktion er blevet dårligere,


Nej den er d den samme. Quick-sort, binary search osv. deres store O funktion er da konstant. Den er ikke blevet dårligere.

Christian Nobel

Ja men dette er ofte et ledelsesproblem mere end det er relateret til noget der har med hardware og/eller software at gøre. Det er umuligt at lære, hvis man ikke må.

Der vil jeg så sige, med fare for at blive beskyldt for at pisse i egen pool, at problemet så sandelig også gør sig gældende for rigtig mange OSS programmer. Så det har også noget med egen disciplin at gøre.

Så du har en rigtig god pointe, en masse af den kode som i dag produceres kan slettes, og erstattes af meget mindre kode som gør det samme meget bedre.

Jeg oplever selv mange gange at på et eller andet tidspunkt, så har jeg programmeret mig op i et hjørne, hvorefter jeg smider det hele ud (undtagen de erfaringer om hvad jeg i hvert fald ikke skal gøre) og starter forfra fra scratch - det kan faktisk godt betale sig og så acceptere den viden man trods alt har fået som sunken cost.

Nikolaj Brinch Jørgensen

Det hjælper ikke at ønske sig tilbage til dengang hvor alt software var skrevet af super hardcore eksperter. Der er alt for stor efterspørgsel efter software til at det kan lade sig gøre. Og vi skal være rigtig glade for at hardwareudviklerne har givet os værktøjerne til, at flere programmører kan være med. Ellers ville vi simpelthen være meget fattigere.


Det er klart at der er kommet mange flere programmører, fordi efterspørgslen er blevet større, og udviklingsopgaverne er blevet meget større, og kompleksisteten af dem er blevet mange gange større.
Det er umuligt at sammenligne de batch jobs der i gamle dage udskrev bibliotekskort med de bibliotelssystemer der i dag kører rundt om på bibliotekerne. Der skal mange flere hænder til at lave et biblioteksystem i dag, hvor kortudskrivningssystemet måske blev klaret af 1 eller 2 dataloger påAårhus EDB central i gamle dage.
Programmering er også blevet mere tilgængeligt, og der er meget muligt at lave programmer og publicere dem selv, eller lave web apps som bare kan sættes i luften. Det kræver ingen uddannelse eller kvalifikationer.
Det gjorde det før, for inden mikrodatamaterne, var der kun store dyre maskiner, hvor man skulle have et job et sted, med den rigtige uddannelse i bagagen for at kunne få lov.
Med denne store mængde af programmører, er der selvfølgelig også en stor mængde dårlige. POg når nogle lande vælger at sprøjte dem ud, fordi der er et behov, uden at disse personer har nogen nævneværdige kompetencer udi i systemudvikling, udover et diplom, ja så er det farligt - og det er måske derhen Christian tænker.
Det er også sket her i DK, hvor store virksomheder har sendt malere, gartnere og andre faggrupper på små kurser for at de skulle lave software (små set i forhold til hvad en egentlig uddannelse af en programmør bør indeholde).

Jens har også ret i sin anskuelse af, at der er udviklere der ikke tænker på deres programmers ressourceforbrug. Jeg oplever nu at de fleste tænker i ressourcer og performance, men også at der er et stort gap, mellem det at tænke på det, og så have kompetencerne til at gøre noget ved det.

Alle faggrupper har dårlige håndværkere, og de er nok en procentsats, dvs. antallet vil stige, når hele den samlede mængde stiger. Men det er et ledelsesproblem, og et problem med uddannelsesinstitutionerne (for der er også kandidater fra de forskellige universiteter der bare ikke er gode nok til at programmere).

Jeg tror dog ikke det har nogen relation til hardware hastighed, men derimod en relation til markedsefterspørgslen til IT.

Jeg er personligt rigtig glad for at hardware er belvet meget mindre og hurtigere, se hvad en iPhone 4S/Samsung Galaxy SII kan i dag, i forhold til en mobil for 10 år siden. Det er sager :-)

At grafikområdet skulle være specielt. Nej - regnekraft er der blevet mere af. Så alt der benytter regnekraft (hvilket 3D graifk også gør - men 2D grafik gør f.eks. ikke - det er stadigt konventionelle mem-operationer), såsom forecasts af den ene eller anden karakter (herunder OLAP i RDBMS mm.), vejrudsigter, kemi, fysik osv. har fået et enormt boost.

Nikolaj Brinch Jørgensen

Der vil jeg så sige, med fare for at blive beskyldt for at pisse i egen pool, at problemet så sandelig også gør sig gældende for rigtig mange OSS programmer. Så det har også noget med egen disciplin at gøre.


Helt enig - se engang på Apache Maven projektet, eller endnu værre Apache Archiva og Apache Continuum (lavet af samme). Maven er den rigtige måde at gøre tingene på, og virker da også, men koden - ad!

Jeg oplever selv mange gange at på et eller andet tidspunkt, så har jeg programmeret mig op i et hjørne, hvorefter jeg smider det hele ud (undtagen de erfaringer om hvad jeg i hvert fald ikke skal gøre) og starter forfra fra scratch - det kan faktisk godt betale sig og så acceptere den viden man trods alt har fået som sunken cost.


Der er jeg enig, men jeg mener ikke det er en sunken cost, for i længden (TCO) har vi sparret en hel masse. Uha du skulle komme og se det jeg ser på nu, du ville løbe skrigende bort, eller begynde at råbe højt :-)

Christian Nobel

Der er jeg enig, men jeg mener ikke det er en sunken cost, for i længden (TCO) har vi sparret en hel masse.

Ja det var måske forkert at bruge udtrykket sunken cost, men mere at nogen gang er man nødt til at acceptere at man skal smide noget væk, istedet for at blive ved med at prøve at reparere på det (her taler vi om sunk cost).

Og helt enig, at over lang tid er det klart bedre at gøre denne erkendelse - personligt uden at vi kan tale om emperi, så har jeg oplevet at jeg måske har brugt 50 timer på en sag som er blevet så klyttet at det er til at kaste op over. Ved så at droppe det totalt og starte forfra får jeg lavet en god, hurtig og stabil løsning, og bruger måske 30 timer på det, istedet for at poste yderligere 50 i den oprindelige løsning og stadig ende med noget juks.

Jonas Høgh

Der er jeg enig, men jeg mener ikke det er en sunken cost, for i længden (TCO) har vi sparret en hel masse. Uha du skulle komme og se det jeg ser på nu, du ville løbe skrigende bort, eller begynde at råbe højt :-)

Jeg vil også erklære mig helt enig i dette. For lige at få definitionen af "sunk cost" på plads, så betyder det bare "penge, der er brugt, der ikke kommer igen". Og pengene vi har brugt på den dårlige kode, får vi naturligvis ikke igen, uanset om den rigtige beslutning fremadrettet er at starte forfra, refaktorere, eller køre videre "som vi plejer".

Nikolaj Brinch Jørgensen

Og helt enig, at over lang tid er det klart bedre at gøre denne erkendelse - personligt uden at vi kan tale om emperi, så har jeg oplevet at jeg måske har brugt 50 timer på en sag som er blevet så klyttet at det er til at kaste op over. Ved så at droppe det totalt og starte forfra får jeg lavet en god, hurtig og stabil løsning, og bruger måske 30 timer på det, istedet for at poste yderligere 50 i den oprindelige løsning og stadig ende med noget juks.


Dårlig kode ender ikke i juks, for det ender aldrig, der er altid noget mere der skal fikses, og folk sidder med flag i debuggeren og kigger på state og laver så "if-retteleser" baseret på deres state observationer, i stedet for at kigge fra helikopteren... :-)
Puha, når man ser dem der som hele tiden sidder og roder med at fikse defects i det samme kode konstant... Så er det altså her man skal træde ind og hjælpe, og sørge for at det kommer ordenlig på sporet.

Andreas Olsen

Der er jo gjort mange forudsigelser om computere gennem tiden:

Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and
weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and
perhaps weigh 1 1/2 tons

-- Popular Mechanics, March 1949 edition

Log ind eller Opret konto for at kommentere