Når man ikke engang kan få så simpelt et projekt til at virke, står det måske endda lige så galt til med hardwareudviklerne, eller hvad mener i?
Jeg mener ikke, at det ser helt så dårligt ud indenfor HW som indenfor SW. Problemet med software - tror jeg - er at man har "overeffektiviseret". For mange år siden, blev det accepteret, at en programmør kun skrev 10 liniers kode per dag (gennemsnit). Dengang, var pålideligheden ligeså god ved software som hardware. Men, det tog tid. Programmørerne skulle lave mere, og på kortere tid. Man begyndte at opfinde "optimeringsmetoder", og ikke alle var lige gode. I den sidste ende, blev resultatet at genererer flere linier på kortere tid, uden der blev opnået reelt mere. Og derved, blev softwaren samtidigt mere uoverskueligt, og dårligere. Effektivitetsproblemet, blev altså løst, ved at gå bort fra, at holde det simpelt.
Dette er ikke helt sket indenfor HW - sikkert fordi at man her stadigt kæmper med at presse hardwaren ned på chipsene. Indenfor hardware, er det trods alt begrænset, hvad det er muligt, og ofte kan en enkelt hardwaremand overskue det komplette design i en FPGA. I modsætning til software, hvor der ikke er besparelser ved at gøre tingene simpelt, så er der indenfor hardware næsten altid store besparelser forbundet med at lave et simpelt design. Det muliggør, at FPGA'erne kan blive mindre, eller chip arealet mindre. Og dermed, en mindre pris - eller et mindre strømforbrug. De hardwaremæssige features, er ofte forbundet med, at tingene fylder så lidt som muligt, og er lavet så effektivt som muligt - hvilket oftest også indebærer at det gøres simpelt. Det, at gøre det simpelt, er indenfor hardware næsten et studie - og det er langt mere enkelt, at gøre det "besværligt". Forenklingen, er en videnskab. Netop derfor, så arbejdes der med tingene, og fejlene opdages, inden at man er kommet igennem udviklingsprocessen.
Omkostningerne i forbindelse med udvikling af hardware, har en stor del af æren, for at hardware er mere pålideligt. For få år tilbage, kostede det milliarder, når noget ikke fungerede - f.eks. hvis man udviklede chips. Det gjorde, at man udarbejdede metoder, som gjorde at man kunne opnå tingene fungerede. Og ikke, som indenfor software, hvor man bare skulle producere endnu flere linier. Indenfor hardware, var det kvaliteten som var væsentligt - meddens det indenfor software, var kvantiteten. De samme programmer, blev større og større, sløvere og sløvere, og udfra en hardwaremands synspunkt der gør alt op i teknisk formåen, så blev softwaren faktisk dårligere, samtidigt med den blev mere volumeniøs. Indenfor hardware, holdte man på KISS princippet, og ikke mindst, at optimere tingene mest muligt. Dem, som var programmør dengang at processorerne kun havde 1K ram, og programmerede alt i maskinkode, bliver i dag betragtet som "dumme" indenfor software branchen. Indenfor hardware branchen, er det stadigt den type kvalifikationer som bruges: At få tingene til at fylde lidt, gøre det kompakt, lave det så svar tiden er meget lavt, og at opfylde tekniske kvalifikationer, såsom så kort svartid som muligt, og så lavt strømforbrug som muligt. Der er ofte en sammenhæng indenfor hardware, så designs der er lavet optimalt, såvel giver kort forsinkelse, som lavt trømforbrug, og stor mulig beregningshastighed, og derfor satses der på at forenkle tingene, og gøre komplekse ting simpelt, så det også er til at overskue. Indenfor hardware, er man beskyttet af patenter, og det har sandsynligvis også være med til at gøre det muligt. Indenfor software, har man i nogle tilfælde brugt "mega-syndromet" til at beskytte sit software, og det måtte helst ikke være overskueligt, for så var det for nemt at se, hvordan indmaden var lavet, eller at man havde stjåldet den. Software er for længst blevet så stort, at du ikke kan debugge den binære kode. Indenfor HW, kan man offentliggøre sine ting, fordi man tager patent, og behøver derfor ikke, at gøre så meget for at øge indpakningen.
Patenter, er derfor nok også lidt en årsag til, at man har kunnet holde skansen indenfor HW. Finder du, noget optimalt indenfor hardware, har konstruktionen kunnet sælges, uden at først skulle krypteres og gøres megastort og uforståeligt fordi man havde patent.
Den største del af æren for hardwarens pålidelighed, tror jeg er de store udgifter, når det ikke fungerer, og fordi at hardware traditionelt ikke kunne gøres om. Derfor er man indenfor hardware langsommere og grundigere, for at sikre sig tingenede fungerer - meddens man indenfor software, havde tendens til at sælge softwaren før den var afluset, og tænkte at fejlene kunne man jo bare rette med opdateringer.
Indenfor hardware, gør man meget ud af tekniske specifikationer, som svartider, og strømforbrug. Der findes ingen komponenter, uden sådanne data opgivet. Det betyder, at du kan sætte komponenterne sammen, og sikre svartiden. Indenfor software, findes ikke "tekniske specifikationer". Mange softwarefolk ved ikke hvad det er. Det nærmeste de kender til svartid, er "typisk" svartid, som betyder forsinkelsen, som kan overholdes i 50% af tilfældende. Indenfor hardware, er svartid garanteret svartid - og det er den svartid som overholdes i 100% af alle tilfælde. Der findes ingen teoretisk mulighed, for at den garanterede svartid overskrides, sålænge at de krav, der stilles til forsyningsspændingens stabilitet mv. opfyldes.
Indenfor hardware, sætter man som regel store krav, til at de ting der bruges fungerer. Inden, at du går i gang med at anvende en komponent, så vil den pågældende komponent være blevet testet af leverandøren, og de står inde for, at den fungerer. Du bruger kun komponenten, hvis du ved den fungerer. Man gør ikke - som indenfor software - anvender komponenter, som alle ved ikke fungerer og er fyldt af fejl. Hvor indstillingen indenfor software, er at der ikke findes software der dur, og man derfor må tage det bedste man kan finde, så er indstillingen indenfor hardware, at tingene skal fungere, og at fejlene skal udbedres, inden komponenterne bruges. Et produkt som windows, har derfor ingen hardwaremæssig relevans. Man ved, at der er fejl i. Det var ved at ændre sig, dengang at Intel kom med deres Intel bug - men på grund af IBM stod hardwarebranchen først. Hardware skal fungere, og Intel blev tvunget til, at skulle erstatte alle fejlende processorer, hvor kunden brokkede sig.
Fremgangsmåden indenfor hardware, er derfor at man tjekker sine ting først. Er man ikke 100% sikker på, at det fungerer - så sætter man sig enten bedre ind i det, indtil man er 100% sikker på det, eller man dropper det. Når man ved at det virker, og hvordan det virker, så kan man bruge det. Og man tjekker sine egne ting først, så man er 100% sikker på at det fungerer, inden man lader det gå videre. Som regel sker det på to måder: Dels, får man givet tests, som det skal kunne gå igennem, og som også tjener til at belyse, hvordan produktet skal fungere i den sidste ende. Og, man laver selv tests, og tjekker dækningsgraden for disse tests. Det er således ikke nok, at bare lave et par tests, som ser ud som om de fungerer.
Og endeligt, så vil dem, der herefter skal bruge de komponenter som man har lavet, også starte med at teste dem, således at de sikrer sig, at de såvel har forstået hvordan funktionen er, og har godkendt den, samt indset - forhåbentligt - at komponenten fungerer. Og ellers, sendes den retur. Man lader normalt dem der oprindeligt har stået for udviklingen rette fejlene, i stedet for at lade nye der ikke har forstået funktionen rette fejlen. Indenfor software, sker mange fejlrettelser, fordi at brugerne (som fikser koden), ikke har forstået funktionen, af den oprindelige kode, og derfor fikser den til eget behov. Det kan så medføre, at den nye kode ikke mer virker, i ældre software.
Jeg tror, at problemet indenfor software, skyldes "effektivisering". Det vil hjælpe på softwarebranchen, hvis der tillades at bruge længere tid på programmeringen og test af såvel andres som egne komponenter, som at der bruges længere tid på forenkling og at få overblik - det vi kunne kalde indeffektivitet. Det kan også hjælpe, at trække vejret dybt indimellem. Gøres softwarebranchen mere ineffektivt, og sættes krav til FÆRRE kodelinier per dag, så tror jeg, at kvaliteten øges.
