Hvorfor software sutter

Overskriften skal ikke læses således at jeg vil presentere en udtømmende liste, men jeg sidder her og græder ned i min morgenmad over hvor dårlige odds vi software udviklere stilles overfor.

Det er ikke vigtigt hvad det er for en ethernet-chip og den er såmænd helt OK, når man får den til at virke, men databladet er til at tude over.

Den første indikation på ugler i mosen er at et datablad for en ethernetchip med inbygget PHY ikke fylder 54 sider. Det kan simpelthen ikke lade sig gøre hvis man holder sig til en anstændig punktstørrelse.

På side 3 kommer den selvinkriminerende udtalelse: "Driveren og chippen blev udviklet sammen [...]". Med andre ord sad der to nörder og kodede hhv. VHDL/Verilog og C og de skrev ingen dokumentation.

Længere inde i databladet begynder så den direkte misvisende information.

Pakke descriptorer beskrives som havende indikator bit for første og sidste segment, men den indlysende håndtering af de miderste segmenter, uden nogle af disse bits sat, beskrives som "illegal", desuagtet at det er sådan chippen virker.

Af de to sølle grafiske representationer af kæder og ringe af descriptorer er begge lodret forkerte, i netop de felter de prøver at illustrere.

Der omtales bits man skal enable og disable, men deres registerplacering omtales ingen steder, andre bit er dokumenteret i forkerte registre og nogle er dokumenteret men findes ikke i hardwaren.

Hvad der sker i fejlsituationer er ikke dokumenteret og chippens to timere står det intet om, bortset fra hvilket register man enabler deres interrupt i.

Men I skal ikke være bange, vi systemprogrammører er vandt til lidt af hvert og også denne chip skal nok blive tævet på plads, så den virker hurtigt og pålideligt.

Men der er en årsag til at vi opfatter det som casus belli når I klager over mangle på drivere til den ny hardware i lige har købt.

  • Nej, jeg har ingen løsning der ikke involverer bastonade til de skyldige.

phk

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Andreas Ryge

at de med teknisk kompetance ikke kan skrive, og de der kan skrive ikke har teknisk indsigt. Spec'en er skrevet af en af de to grupper.

Her skal vi udviklere vel også lige kigge på os selv, og overveje hvor gode vi selv er til at dokumentere.

  • 0
  • 0
Karsten Nyblad

Jeg er langt hen af vejen enig. Undervisningen i at skrive henvender sig i alt for høj grad til humanistik indstillede børn, og den er pædagogisk helt forkert til naturvidenskabeligt indstillede børn. Stile er på en måde noget af det vanskeligste at skrive. Man beder børnene skrive om noget, der ikke interesserer dem, hvor de ikke har noget at meddele, og uden en klart defineret målgruppe. Sådanne tekster er nogen af de vanskeligste at skrive.

Jeg hører selv til dem, der fik 5 i dansk stil i gymnasiet, og når jeg snakkede med mine medstuderende på DTU, fik jeg det indtryk, at mange af mine medstuderende havde fået det samme. Jeg hadede at skrive stil, for jeg vidste jo godt, at det jeg skrev var noget lort. Jeg tror, de naturvidenskabelige uddannelser har mange som mig, for som student er det fristende at tro, at man kan klare sig som f.eks. ingeniør uden at kunne skrive. Først senere opdager man, hvilket et handicap det er. En af grundene til at jeg skriver debatindlæg, er, at jeg vil være bedre til at skrive.

Noget andet er så, at mange arbejdsgivere lader f.eks. programmører slippe afsted med at aflevere dårligt dokumenteret kode. Det er almindeligt, at folk konsekvent undlader at dokumentere deres kode, så en del af skylden skal også lægges på arbejsgivere, der tillader sådan noget, og som i det hele taget ikke har nogen kvalitetskontrol af de skrevne programmer.

  • 0
  • 0
Michael Rasmussen

Jeg tror, det skyldes ledelser med kortsigtede ledelsesstrategier, og at ovenstående betragtninger også gælder for test. Typisk er det sådan, at ledelser er ansat på en tidsbegrænset resultatkontrakt, hvorfor volumen er bedre end kvalitet. Gevinster fra god dokumentation og test høstes på det lange sigt, hvorfor ledelsen presser udviklere til at frigive kode/produkter før dokumentation og test er på plads.

Som jeg ser det, skal der ske et paradigmeskift i ledelsesstrategierne, før vi ser kode/produkter med udtømmende dokumentation og tilbundsgående test.

Derfor er det min påstand, at fri software er/har bedre betingelser for korrekt dokumentation og test, da det ikke er underlagt samme kortfristede horisont.

/Michael

  • 0
  • 0
Karsten Nyblad

"Derfor er det min påstand, at fri software er/har bedre betingelser for korrekt dokumentation og test, da det ikke er underlagt samme kortfristede horisont."

Tja, jeg synes der er utroligt meget open source kode, hvor dokumentationen er af Pommern til. At meget open source kode er godt aftestet skyldes mere, at dere er mange, der benytter beta-versioner, og at de fundne fejl bliver indrapporteret, fordi folk oplever, at fejlene rent faktisk bliver rettet.

Open source kode lider under, at folk hellere vil skrive kode end dokumentere, og at der ikke er nogen der gider dokumentere andres kode.

  • 0
  • 0
Casper Thomsen

Nu har jeg kun erfaring med open source-CMS, men her oplever jeg, at de generelt er ret dårligt dokumenteret sammenlignet med alternativerne.

Mit indtryk er, at bidragsyderne hellere vil bruge deres begrænsede tid på at tilføje funktionalitet end at dokumentere funktionalitet, og i et open source-projekt er der ingen, som kan slå dem i hovedet og tvinge dem til at gøre det anderledes.

Jeg har oplevet dels manglende dokumentation for brugen af et CMS, dels manglende dokumentation for andre udviklere, som vil ind bag koden og udvikle nye moduler.

  • 0
  • 0
Lasse Nielsen

At tænke på koden som dokumentation er lidt som at bruge landet selv som landkort: Ubrugeligt, ligegyldigt hvor "rigtigt" det er.

Og modsat landkortet, er koden ikke "i det mindste rigtig", for hvem ved hvad "rigtig" er når kodens funktionalitet ikke er dokumenteret.

Så kommer man til situationen hvor "det som koden gør" er specifikationen for hvad den skal gøre, og så er det pludseligt meget svært at rette og videreudvikle. Man kan ikke engang smide den udokumenterede kode ud og starte forfra, uden en ordentlig specifikation.

/L

  • 0
  • 0
Peter Juhl Christiansen

Ingen tvivl om at måden programører arbejder på langt fra er optimal, som jeg ser det er software udvikling/implimentering stadig et ungt fag.

Opgave med at forbedre stabiliteten af de ting vi laver ligger to steder, på den ene side skal undervisningen i at lave software lære folk gode måder at arbejde på, fx test dreven udvikling og hvad man ellers kan forestille sig.

På den anden side skal udviklere og IT firmaer være bedre til at vælge de rigtige værktøjer, fx har jeg set undersøgelser der viser at antallet af bugs oftes er færrer i java kode end i C/C++, (beklager jeg ikke kan referer mere precist). Dette skyldes tror jeg at mulighederne for at skyde sig selv i foden når man laver C/C++ er meget størrer, det er klart at en driver til en chip er vanskeligt at lave i andet end C, men der er så meget andet software derude.

Jeg er overbevist om at de folk der arbejder med udvikling af morgendagens programeringsprog er bevidste om at det handler om at lave værktøjer der gør selve kodnings processen effektivere og resultatet mere stabilt.

Jeg tror at dele af IT-industrien lidder af et Windows95 syndrom, der med forstået at det da er OK at software går ned, det kan jo ske...(og kunderne tror på det) Det må vi væk fra!! og tror også langsomt at brugerne og køberne af diverse programmer begynder at forvente at software VIRKER , og hvis ikke kræve kompentation. Og når det sker bliver det pludseligt dyrt at lave utestet og udokumenteret kode, også tror jeg også firmarene begynder at prioterer anderledes.

  • 0
  • 0
Log ind eller Opret konto for at kommentere