allan ebdrup bloghoved ny

Fokus på softwarekvalitet? Du gør det forkert

Kan det virkelig lade sig gøre?

Hvad nu hvis du kunne levere endnu højere softwarekvalitet og samtidig gøre det hurtigere?

Kvalitet af software er en svær størrelse at kvantificere, fordi kvalitet kan anskues og måles på rigtig mange måder. Derfor vil jeg ikke forsøge at definere, hvad kvalitet af software er.

I stedet vil jeg præsentere en overordnet strategi, der er løsningen på en vifte af softwarekvalitets-problemer, uden at du går ned i leverancehastighed. Vi er faktisk selv gået væsentlig op i hastighed ved hjælp af strategien.

Brændt barn skyr ilden

Hvis vi lader det at brænde sig på ild være en metafor for det at blive ramt af dårlig software kvalitet, så kan man reagere forskelligt på at blive brændt.

Illustration: Privatfoto

Brændt barn skyr, som vi ved, ilden. Barnet har faktisk fundet en opskrift på at opnå den perfekte softwarekvalitet.

Hvis du for eksempel har et problem med, at der sker regressioner (fejl), når du deploy'er nye features til produktion, så vil barnets reaktion være at holde op med at lave nye features. I stedet vil 'det forsigtige barn' kun lave fejlrettelser, og således til sidst ende i en situation hvor der aldrig er problemer med regressioner.

Barnets forsigtighed findes også i mindre drastiske udgaver, i udviklingsafdeliger med ensidig fokus på kvalitet. Symptomerne er:

  • Længere og grundigere test-faser
  • Tungere og mere kompleks udviklingsproces
  • Mere tid brugt på analyse
  • Flere møder
  • Gates og kontroller der skal udføres
  • Længere tid mellem releases
  • Svært at få taget beslutninger

Når jeg holder foredrag, om hvordan vi deploy'er til produktion ti gange om dagen, kommer der desperate udviklere fra store dansk virksomheders IT-udviklingsafdelinger op til mig, og fortæller at de bruger 80% af deres tid på møder, mens de kun bruger 20% af deres tid på rent faktisk at udvikle.

Det er 'det forsigtige barns' virksomhed i dets værste variant.

Det er ikke sjovt at være udvikler i den type virksomhed. Udviklere vil udvikle, ikke holde møder. Mange af de gode medarbejdere smutter. De gode, der bliver, holder man på med meget høje lønninger og andre dyre tiltag, der skal få udviklerne til at holde ud at være virksomheden.

Virksomhedens strategi er håbløs. I en verden hvor udviklingen går hurtigere og hurtigere og konkurrenterne står på spring for at snuppe dine kunder, dur det ikke at levere langsommere og langsommere.

Du skal være en vildhest

Vildhesten har fundet en måde at overleve en steppebrand.

I stedet for at løbe væk fra steppebranden, løber vildhesten imod den og gennem den og sådan overlever den. I eksemplet med problemer med regressioner når en ny feature deploy'es til produktion, vil vildhestens strategi være at deploy'e til produktion oftere.

Hvis det gør ondt, så gør det oftere. Det er den stategi, du skal bruge, for at få løst dine problemer med softwarekvalitet. For kun ved at gøre det der gør ondt værre, kan du overvinde det og komme ud på den anden side.

Hvis du for eksempel har en manuel smoke-test, som er tung og langsom, så beslut at udføre testen ti gange så ofte, som du gør i dag. Det vil tvinge dig til at gøre den mindre tung og automatisere dele af den.

Ensidigt fokus på kvalitet er direkte skadeligt

Hvis din virksomhed siger, at der skal være fokus på kvalitet og lader det stå alene, så er det 'det forsigtige barn', der taler. Fokus på kvalitet skal ikke stå alene.

Hvis fokus på kvalitet står alene, vil du få indført kvalitets-kontroller, der gør dig langsommere. Alle bliver mere forsigtige og begynder at overanalysere. Der kan nemt komme en tendens til at overvurdere risici. Det bliver svært for den enkelte at tage ansvar, fordi det involverer flere og flere mennesker, gates og kontroller.

Det ironiske er, at jo langsommere du leverer, jo mere daler din kvalitet. Martin Fowler mener ligefrem, at det er en eksponentielt stigende kurve. Jo langsommere, jo mere gør det ondt.

Ensidigt fokus på kvalitet er ikke bare uambitiøst, det er direkte skadeligt.

Du skal gå efter at levere bedre kvalitet hurtigere

Det mål vi har sat op i vores udviklingsafdeling er, at vi skal levere bedre kvalitet hurtigere.

Det er meget vigtigt, at vi ikke skal levere hurtigere ved at stresse, overarbejde og knokle mere. Det skal gå hurtigere ved, at vi arbejder mere intelligent.

Bedre kvalitet alene er ikke svært. Det problem har det forsigtige barn løst og samtidig kørt virksomheden i sænk.

Men at levere bedre kvalitet, og samtidig gøre det hurtigere uden at knokle mere, se det er svært! Og det er de svære udfordringer, der er de sjoveste.

At levere bedre kvalitet hurtigere kræver at alle i udviklingsafdelingen bidrager til at opnå dette fælles mål. Det er en vision og et fokus, vi skal dele og arbejde hen imod sammen, ellers vil det ikke lykkes.

Tjekliste for kvalitetsforbedringer

Når vi vurderer en ny måde at højne vores softwarekvalitet på, holder vi den op mod en tjekliste af røde flag. Tjeklisten af røde flag er ting vi ved, gør udviklingen langsommere, hvis vi gør mere af det. Tjeklisten er:

  • Manuelle processer som:
    • Manuelle tests
    • Kodereviews
  • Møder
  • Ventetid eller køer
    • Afhængigheder af andre afdelinger
    • Afhængigheder af kollegaer
  • Handovers, at videregive ansvaret for en opgave til en anden person
  • Gates - ting du skal gøre
  • Grim kode - spaghetti
  • Mere kode, højere kompleksitet
  • Stort scope af opgaver

Vi siger ikke, at alle tingene på listen er forbudte. Vi er for eksempel store tilhængere at kodereview.

Vi har dog ændret vores udviklingsprocess, så kodereview ikke er obligatorisk, men udvikleren i stedet selv vurderer, hvornår der er brug for det. Således har vi reduceret mængden af kodereview uden at gå på kompromis med kvaliteten. Kodereview er på listen, fordi det er en dyr manuel process. Derfor har vores reduktion af kodereview sat vores leverance-hastighed i vejret.

Enhver ændring af vores udviklingsproces holdes op imod listen. Hvis der er røde flag, vil vi forsøge at gøre noget ved det.

Hvis vi for eksempel indfører en afhængighed af en anden afdeling, prøver vi at fjerne afhængigheden ved at tage noget ansvar.

Fordelingen af ansvar, med tilhørende beslutningskompetence, er en meget stor del af nøglen til at levere hurtigere og med bedre kvalitet. Udfra tjeklisten følger det, at det er en kæmpe fordel at gøre den enkelte udvikler mere autonom, og samtidig, på niveauet over det, gøre det enkelte team mere autonomt.

Sig nej til tiltag, der nedsætter din leverancehastighed

Hvis vi har et forslag til at forbedre vores software-kvalitet, ved en ændring af vores udviklingsproces, kan man groft sige, at:

  • Hvis ændringen gør os langsommere, er vi slet ikke interesserede.
  • Hvis ændringen gør, at vi kan levere med samme hastighed, men med bedre kvalitet, er vi mildt interesserede.
  • Hvis ændringen gør, at vi kan levere hurtigere, med samme kvalitet, er vi ret interesserede.
  • Hvis ændringen gør, at vi kan levere hurtigere og med bedre kvalitet, så har du vores fulde opmærksomhed.

Resultat indtil videre

Vores fokus på kvalitet og hastighed har betydet, at vores udviklere i dag kan bruge op til 90% af deres tid på at kode og levere og kun 10% af deres tid er reserveret til møder. Vi leverer med en hastighed på 140% ifht for et år siden. Samtidig registrer vi 44% færre bugs.

Den enkelte udvikler har fået meget mere ansvar og beslutningskompetence. Ændringerne er blevet godt modtaget af langt de fleste udviklere, men det har også været en svær omstilling for enkelte. Vi har lavet ændringerne langsommere end dem der er helt fremme i skoene gerne ville have og hurtigere end de mere konservative ville have. Sådan må det nødvendigvis være.

Det gode ved strategien er, at vi alle kan stå sammen om den. Selvfølgelig vil ledelsen gerne have højere kvalitet hurtigere. Men for mig er det nærmest vigtigere, at det bare er meget sjovere at være udvikler i en virksomhed, hvor du kan få noget ansvar med tilhørende beslutningskompetence, og bruger tiden på at udvikle og levere i høj kvalitet.

Arbejder du selv i en virksomhed, der er 'et forsigtigt barn' eller en vildhest? Hvor meget af din tid går rent faktisk med at udvikle?

Kommentarer (56)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Peter Andersen

men udvikleren i stedet selv vurderer, hvornår der er brug for det. Således har vi reduceret mængden af kodereview uden at gå på kompromis med kvaliteten.

Risikerer I ikke at I sætter ræven til at vogte høns ved at lade udvikleren afgøre om hans kode er af en kompleksitet og kvalitet der gør at review er nødvendigt?

Det er lang tid siden at jeg mødte en udvikler der lavede fejl, al kode der kommer ud af en udvikler er jo som bekendt fejlfri. ;)

  • 3
  • 3
#2 Peter Stricker

Vores fokus på kvalitet og hastighed har betydet, at vores udviklere i dag bruger 91,2% af deres tid på at kode og levere og kun 8,8% af deres tid på møder.

Og de sidste 50% bruges på tidsregistrering :-)

Jeg er meget imponeret over præcisionen i ovenstående, men stiller mig tvivlende overfor korrektheden.

  • 4
  • 1
#4 Frederic Gos

Fed artikel. Tænk hvis langt flere forstod hvad det er du skriver hva?

For mig at se er det også meget et spørgsmål om psykologi. Hvis man giver ansvaret til udviklere at afgøre om noget skal kodereviewes, vil de også være mere 'ansvarsbeviste' og ha et sjovere job. Hvis de så dummer sig engang imellem, kan det så også være at de tænker mere over det en anden gang. Det er jo en balancegang, og det er tilladt at lave fejl.

Jeg er stor tilhænger af kodereviews, bare ikke altid.

I et continuous delivery scnenarie er 'ship 10 gange om dagen' vigtigere end at en fejl sniger sig ind i ny og næ. Man kan jo bare trykke på 'go back to previous release' knappen. Hvis al dette er automatisk ofc.

  • 2
  • 0
#5 Allan Ebdrup Blogger

Og de sidste 50% bruges på tidsregistrering :-)

Jeg er meget imponeret over præcisionen i ovenstående, men stiller mig tvivlende overfor korrektheden.

Vi laver ikke tidsregistrering.

Tallet er kommet frem ved at tælle mødetiden sammen over to uger, og ja nu du siger det er præcisionen lidt fjollet. Vi kalder det 90% af tiden på at levere. Jeg tager imod din feedback og retter det.

  • 2
  • 0
#7 Allan Ebdrup Blogger

Får jeres udviklere ingen frokost? Må de ikke gå på toilettet? Må de ikke tage en kop kaffe?

Som jeg skriver i blogindlæget:

Det er meget vigtigt, at vi ikke skal levere hurtigere ved at stresse, overarbejde og knokle mere. Det skal gå hurtigere ved, at vi arbejder mere intelligent.

Ja, de får frokost. Ja, de må gå på toilettet, Ja de må tage en kop kaffe.

De må også tage en smøg, tage et spil bordtennis, gå en lille tur og trække frisk luft osv.

  • 3
  • 0
#10 Allan Ebdrup Blogger

Risikerer I ikke at I sætter ræven til at vogte høns ved at lade udvikleren afgøre om hans kode er af en kompleksitet og kvalitet der gør at review er nødvendigt?

At udvikleren selv bestemmer om der skal laves kodereview kræver at udvikleren går op i at levere kvalitet. Vores udviklere tager i høj grad ansvar for at levere kvalitet. Kodereview er en integreret del af den måde vi arbejder på. Og vi er alle opmærksomme på at et kodereview højner kvaliteten, ligemeget hvem du er.

Vi laver faktisk kodereview af det meste af vores kode stadigvæk. Men der er simple ændringer hvor det springes over. Og som noget nyt er der også, i meget få tilfælde, begyndt at blive lavet to eller flere kodereviews af samme ændring, når ændringen er kritisk. Det bliver gjort fordi et kodereview ikke er et handover mere, du assigner ikke et kodereview i et system.

Det er lang tid siden at jeg mødte en udvikler der lavede fejl, al kode der kommer ud af en udvikler er jo som bekendt fejlfri. ;)

Det er meget langt fra den kultur vi har, at tænke sådan. Vi lærer alle nye ting hver dag af at lave kodereview.

  • 1
  • 0
#12 Allan Ebdrup Blogger

Den store præcision fik mig til at læse mere ind i sætningen - tidsregistrering og KPI'er. Men faktisk peger resten af bloggen jo mod en meget mere laid back tilgang til tingene.

Og tak for at du siger det, så jeg kan rette det til, så det ikke bliver misforstået.

Ja vi har faktisk lavet alle ændringerne ud fra "sund fornuft" og ikke kørt med målinger undervejs. De tal jeg har gravet frem af vores systemer, er faktisk nogle jeg har gravet frem efter vi har lavet ændringerne. Fordi når jeg fortæller om hvad vi har gjort, er det den slags tal som folk efterspørger. Det er ikke nogle tal som vi styrer efter.

  • 3
  • 0
#13 Martin Jünckow

Det er et rigtig interessant emne og desværre er mentaliteten rigtig meget i "det forsigtige barn" kategorien desto større virksomheden er - faktisk er det mit indtryk (jeg arbejder i en mellem-stor virksomhed) at man ligefrem ser op til de store virksomheders over-bureaukratiske processer og betragter det som værende at man bliver mere "professionel" desto mere man nærmer sig disse.

Det er få som tør gå imod strømmen, sætte sig ned og overveje om der er en anden vej - en vej der ikke betyder 80% overhead på at skrive en linje kode og 80% mere før denne linie kode er deployed til produktionsmiljøet.

Det er et emne jeg længe selv har fundet interessant og forsøgt at forbedre for vores team så meget som det nu tillades (vi er desværre underlagt nogle enterprise processor af investorene som sætter visse begrænsninger).

Vil blot sige at jeg synes du får sat ord på nogle ting jeg ud fra min erfaring kan relatere til, men aldrig selv har fået sat i system på helt samme måde - der er noget rigtig god inspiration at hente i måden I tænker tjeklister og evaluering af nye tiltag på jeg tror jeg kan bruge fremadrettet, så vil blot benytte lejligheden til at sige tak for et godt indlæg der giver stof til eftertanke :-)

  • 2
  • 0
#14 Poul-Henning Kamp Blogger

Jeg kunne egentlig godt tænke mig at høre om Allan ville være passager i et moderne fuld-computeriseret fly, hvis udviklerne af fly-by-wire softwaren "deploy'er til produktion ti gange om dagen" ?

Hvad med en robot-hjerteoperation hvor softwaren opdateres halvejs ?

Nej vel ?

Grunden til at Allan kan ride sin kæphest ud over stepperne, vildt skydende om sig til alle sider, er at web-apps ikke er særligt indviklet software og sjældent indebærer livsfare for nogen.

Skal vi gætte på at mindst et deployment af de ti daglige handler om at det forrige måske ikke var helt gennemtænkt ?

Når jeg bruger en utrolig masse tid (dog ingen møder, det er et et-mandsfirma :-) på kvalitet, er det fordi jeg ikke kan deploye 10 gange om dagen, faktisk har jeg overhovedet ingen kontrol over hvor eller hvornår min software bliver deployet og derfor kan jeg ikke lave hovsa-rettelser på samme måde som Allan kan.

Noget af det bedste software nogensinde produceret var rumfærgens. Nettoproduktiviteten var i omegnen af en sølle linie kode per medarbejder per dag, til gengæld var den eneste fejl de nogensinde har haft live for åbne TV over hele jorden da den forhindrede den første opsendelse ("The bug heard around the world").

Software er ikke bare software og Allans metoder er kun relevante for et meget lille hjørne af det samlede felt.

  • 11
  • 2
#15 Martin Jünckow

PHK: Enig i at der er mange former for softwareudvikling, med meget forskellige krav til kvaliteten og at der ikke findes én måde at gøre tingene på der virker i alle henseender.

Men specielt når vi taler udvikling af inhouse business-software, så er der få der tør stille spørgsmålstegn ved det overhead man introducerer i forsøget på at fremstå mere "professionel" og det gør det ikke bedre at management sjældent rigtig forstår sig på udviklingsprocessen, men de forstår sig på alle de ting som kan måles på - hvilket betyder komplicerede ticket-systemer, tidsregistrering, en masse frem og tilbage for at sikre at enhver ticket der kræver udvikling har approval fra ledelsens side, handover til Q&A afdeling, deployments håndteret af IT afdelingen (som igen kræver tickets) osv. osv.

Det er ikke realistisk for alle systemer at kunne opnå 10 daglige deployments (jeg tror vi har omkring 2-3 ugentlige for vores inhouse Business Intelligence løsning, hvilket vi betragter som temmelig godt), men mange kunne have stor gavn af at stoppe op og overveje al det overhead man har fået introduceret i processen. Om det virkelig er gavnligt og om effekten af det virkelig er positiv nok til at retfærdiggøre det. Det tror jeg egentlig også er den pointe Allan forsøger at drive igennem.

Den virkelighed jeg oplever i mange større virksomheder er at man agerer som lemminger, man kigger på hvad de andre store virksomheder gør og så kopierer man det ud fra tankegangen at hvis de andre gør det, så bør vi nok også gøre det - eller endnu værre: Hvis de store gør det, så har de helt sikkert gennemtænkt det, derfor bør vi også gøre det.

Denne lemming-tankegang er grunden til det mange steder er gået så galt og at process-overheaded overhovedet ikke matcher vigtigheden af den software som produceres. Hvis det er livsvigtig software, software til rumraketter eller software som i dit tilfælde er en vigtig komponent for en stor del af de største websites - ja så stilles der selvfølgelig store krav til kvaliteten, men der produceres edderrødme også meget software som er langt eller meget langt fra at være kritisk på det niveau og hvor udviklingsprocesserne og overheaded slet ikke står mål med produktet.

  • 2
  • 0
#16 Frederic Gos

Wow Poul-Henning, du er godt nok en forstokket gammel mand.

Hvorfor kan du ikke læse imellem linierne og forstå hvad artiklen handler om? Dit argument, hvis man tager det for gode varer, betyder bare at software ALDRIG kan deployes.

At hive ekstreme tilfælde hvor menneskeliv er på spil er jo noget fis. Og nej det er ikke et 'meget lille hjørne af det samlede felt'. Det er en ret stor delmængde i dag. Det eneste du har ret i er at ja, web egener sig rigtigt godt til continuous delivery, men det betyder ikke at nogle af metoderne kan bruges andre steder.

Og hvorfor skriver du web-apps per definition er simple? Det er jo noget vås.

Hvad skal der til før man deployer?

  • 3
  • 4
#18 Poul-Henning Kamp Blogger

At hive ekstreme tilfælde hvor menneskeliv er på spil er jo noget fis. Og nej det er ikke et 'meget lille hjørne af det samlede felt'. Det er en ret stor delmængde i dag.

Det er utroligt relevant, for intet sted i Allans artikel forholder Allan sig til hvad det faktisk er han laver og et eller andet sted derude risikerer vi at der sider en Cand Polit eller Cand Merc og ser lyset uden at forstå forskellen.

Og hvorfor skriver du web-apps per definition er simple?

Jeg skrev ikke noget om at de "per definition" er simple, det er dine ord.

Men faktum er at de er det, det er derfor så mange skodprogrammører kan overleve i den branche og det er derfor det går rivende galt for dem når de undtagelsesvist bliver sat til at lave noget der ikke er simpelt.

Og lad mig gætte, du fatter slet ikke hvad min overskrift taler om, vel ?

IT branchen har en grim tendens til at rende efter den ene vækkelsesprædikant efter den anden, bare i min tid i branchen har 4GL sprog, 5. generations computere, Objektorienteret programmering, Prototyping, Pair-programming, Agile, Scrum og meget andet været LØSNINGEN! for efter et par år at fizzle ud fordi det mestendels var buzzwords.

Allan har nogle valide pointer, men formen af hans præsestation er ikke ret let at skelne fra annoncer for helsekost og fodmassage bag i husstandsomdelte reklameaviser.

Wow Poul-Henning, du er godt nok en forstokket gammel mand.

Du har ret i at jeg har brugt mange år på at modbevise den påståede ældre-visere korrelation, dog ikke med noget stort held må jeg erkende.

Men 30 års erfaring gør faktisk mig netop i stand til at "[...] læse imellem linierne og forstå hvad artiklen handler om" og giver årsag til at brokke mig når når et paradigme der kun har relevans i et meget lille hjørne af IT bliver solgt som om det er LØSNINGEN! på alle problemer, overalt, til alle tider.

Fordi: There is no silver bullet.

  • 6
  • 3
#20 Allan Ebdrup Blogger

Jeg kunne egentlig godt tænke mig at høre om Allan ville være passager i et moderne fuld-computeriseret fly, hvis udviklerne af fly-by-wire softwaren "deploy'er til produktion ti gange om dagen" ?

Der er ikke nogen grund til at stirre sig blind på det med at deploy'e ti gange om dagen.

Metoden jeg beskriver brugt på fly-by-wire ville nærmere være at finde en manuel kvalitetssikringsaktivitet, der er tung og "smertefuld" at få udført, og så gøre den ti gange så ofte.

Hvad med en robot-hjerteoperation hvor softwaren opdateres halvejs ?

Nej vel ?

Man vil selvfølgelig ikke opdatere robotten midt i en operation.

Hvis du skal deploy'e oftere skal det være fordi du har haft "smerte" ved at deploy'e. Det kunne fx være at robotten blev "ukampdygtig" fordi noget gik galt da softwaren skulle rulles på. I sådan en situation kunne man fx rulle software på en gang om dagen. Man kunne så bare lade det være det samme software, uden opdateringer, der blev rullet på. Det vill sikre at man fik løst problemet med at rulle software på.

Skal vi gætte på at mindst et deployment af de ti daglige handler om at det forrige måske ikke var helt gennemtænkt ?

Kvalitetssikringen før deploy i ens process kan skrues op og ned efter de krav der er. Men ja vi deploy'er bugfixes. Og ja vi har den luksus at vi kan reagere hurtigt når der er en bug.

Når jeg bruger en utrolig masse tid (dog ingen møder, det er et et-mandsfirma :-) på kvalitet, er det fordi jeg ikke kan deploye 10 gange om dagen, faktisk har jeg overhovedet ingen kontrol over hvor eller hvornår min software bliver deployet og derfor kan jeg ikke lave hovsa-rettelser på samme måde som Allan kan.

Det er åbenlyst at som et-mandsfirma er du ikke den primære målgruppe for blogindlæget. Alt det med møder og ansvar giver sig selv for dig.

Du kan måske dele hvad din største "smerte" er i din kvalitetssikring? Så kan vi se om det giver mening at tænke over hvad der skulle til, hvis det skulle gøres mere.

Software er ikke bare software og Allans metoder er kun relevante for et meget lille hjørne af det samlede felt.

Det er klart at der er forskel, og jeg fortæller bare om hvad vi har gjort. Men jeg er ikke enig i at metoderne kun kan bruges på et lille hjørne. Hvis du ser ud over det med at deploy'e ti gange om dagen, vil jeg mene, at det kun er et lille hjørne af software, hvor metoden ikke er relevant.

  • 2
  • 1
#21 Peter Andersen

Jeg skrev ikke noget om at de "per definition" er simple, det er dine ord.

Men faktum er at de er det

Dengang jeg læste på DTU og kodede en del i min fritid var jeg overbevist om at jeg skulle ud og lave "rigtig" programmering. Var det ikke harware-nært, så var det ikke "rigtig" programmering. Jeg så ned på "webudviklere" fordi det jo var pisselet og trivielt sammenlignet med at få et stykke (begrænset) hardware til at opføre sig som jeg nu ønskede det. Når det blev rigtig hardcore måtte jeg igang med assembler - og jeg var fandens hård til det. Jeg var en rigtig programmør - ikke sådan en wannabe "webprogrammør".

Da jeg blev færdig blev jeg ansat i en virksomhed der laver "webprogrammering", i starten var jeg meget skeptisk - det var jo bare "webprogrammering", det som sinkerne på bagerste række havde beskæftiget sig med under mit studie.

Nu her en årrække efter, så kan jeg love dig for at jeg tog fejl. Jeg oplever næsten dagligt problemstillinger og kodeudfordringer som er fuldt ud på højde i kompleksitet og omfang med de hardware-nære problemer jeg oplevede før. At du har samme tilgang til "webprogrammering" som jeg havde dengang jeg var ung og naiv - det kunne muligvis tyde på at du bør komme med fra dit elfenbenstårn bygget af ML, COBOL og ALGOL og møde den virkelige verden.

Når du så står med en række integrationer der bare ikke vil makke ret, så tror jeg du vil få øjnene op for at "webprogrammering" er noget andet end du forestiller dig. Hvis jeg bare kan omstille en enkelt person til at forstå at "webprogrammering" ikke bare er forsimplede kodeopgaver, så betyder det at jeg - i det virkelige liv - (der hvor "webprogrammering" kan gøre en forskel for tusinde mennekser) måske ikke vil rende imod disse højpandede tåber.

..Men jeg kan måske tage fejl? Der findes måske stadig fossiler der mener at det er "rigtig" kode når man skal lave en tidssynkroniseringsmekanisme (alene) hjemme kl. skidt om natten foran krystalapparatet anno 1975.

  • 4
  • 2
#22 Poul-Henning Kamp Blogger

kodede en del i min fritid var jeg overbevist om at jeg skulle ud og lave "rigtig" programmering.

Nu forholder det sig sådan at jeg har lavet stort set alt hvad man kan lave indenfor programmering i min karierre, fra administrativ databehandling over robotter, real-tidssysteme, web-apps, netværksprovisionering, netværksovervågning, printerdrivere, kryptering og ja, kerneprogrammering.

Når jeg skriver at web-apps er simple, mener jeg det: De kører i et utroligt programmørvenligt, reproducerbart og velisoleret miljø, der er masser af gode værktøjer til at teste og debugge med og der er stort set ingen støj - i modsætning til stort set hvad som helst der har forbindelse til en fysisk måling af en art.

Der er enorme klasser af problematikker man simpelthen ikke kommer i nærheden af i det miljø.

Og det er fint nok, til gengæld slås folk der laver kirurgiske robotter ikke med browser-compatibilitet -- hver have sine roser og tidsler.

Og ja, jeg har faktisk også arbejdet i et miljø præcis som det Allan beskriver -- for 15-20 år siden :-)

Men min pointe står stadig: Hvis vi skal have en intelligent diskussion om softwarekvalitet og dens rette prioritering, bliver vi nødt til at være nuancerede om hvad det er for et IT miljø vi taler om.

  • 5
  • 0
#23 Poul-Henning Kamp Blogger

Det kunne fx være at robotten blev "ukampdygtig" fordi noget gik galt da softwaren skulle rulles på. I sådan en situation kunne man fx rulle software på en gang om dagen. Man kunne så bare lade det være det samme software, uden opdateringer, der blev rullet på. Det vill sikre at man fik løst problemet med at rulle software på.

Det er den slags jeg ville forvente foregik i leverandørens test-laboratorie, ikke ude på Slagelse Sygehus :-)

Jeg har ikke noget problem med dine foreslag som sådan, bare folk husker og er klar over at de kun relaterer sig til et bestemt hjørne af IT brachen...

Det jeg opponerer imod er de store absolutte udtryk og sving med armene, der efterlader indtrykket af en mand der har set lyset og nu slet ikke kan se nuancer mere...

  • 2
  • 0
#24 Allan Ebdrup Blogger

Det jeg opponerer imod er de store absolutte udtryk og sving med armene, der efterlader indtrykket af en mand der har set lyset og nu slet ikke kan se nuancer mere...

Ja vi har jo alle en form i vores blogindlæg, du har din "IT-skepsis"-facon. Det her er min facon.

Når jeg skriver et blogindlæg udelader jeg altid nuancer som jeg gerne ville have haft med, og siger "Det må vi tage i kommentarerne". Ellers bliver blogindlægene alt for lange (Rumfærge software var fx på listen denne gang).

Du skal ikke tage det som andet end at jeg brænder for det jeg skriver. Jeg er fuldt ud parat til at snakke om nuancer - jeg lærer så meget af at snakke med andre om de her ting. Det er derfor jeg blogger og holder foredrag, for at lære noget af dialogen. Også for at finde ud af hvad jeg egentlig selv mener.

Til mine foredrag siger jeg altid, at det her er bare mine erfaringer, og det hele skal tages med et gran salt.

Ikke desto mindre er mit håb at jeg kan rykke noget i folk og kickstarte dialogen, så vi alle lærer noget.

  • 5
  • 0
#25 Poul-Henning Kamp Blogger

Ikke desto mindre er mit håb at jeg kan rykke noget i folk og kickstarte dialogen, så vi alle lærer noget.

Jeg ville nok fokusere på noget lidt andet: "Tør du ?"

Jeg har mødt rigtig mange steder hvor man nærer en næsten panisk frygt for softwaren og ikke tør gøre noget som helst andet end det man plejer at gøre, af frygt for hvad der vil ske.

(Det eneste stykke hardware jeg har set folk have samme holdning til er UPS'en, hvor rigtig mange også er panisk rædde for at tage kniven for at se om den faktisk virker...)

En stor del af frygten er at hvis nu der sker noget forkert, får man bare endnu mere arbejde ud af det, så hellere holde sig på "dydens" smalle sti.

Kombineret med at de færreste software projekter har en egentlig releaseprocess, langt mindre en veltestet og ofte brugt releaseprocess, så havner man nemt hvor du beskriver: Deployment er et mareridt.

Dine argumenter handler alle om denne frygt, uden overhovedet at nævne den med et ord, selvom den, ihvertfald i min optik, er root-cause for de fleste problemer.

Er softwaren noget skod er frygten naturligvis velbegrundet og dermed kommer vi tilbage til det du gjorde til overskriften: Kvaliteten.

Der er langt mindre grund til at være bange for kvalitetssoftware.

  • 1
  • 0
#26 Hans Henrik Jakobsen

Jeg må give PHK ret denne gang.

Alt for ofte bliver der sat de forkerte folk til udføre en opgave. En ingeniør virksomhed ansætter ikke en el-ingeniør til at lave mek-kontruktioner.

Det sker igen og igen inden for IT-branchen og når ikke kan få det til at virke, ja, opfinder man en ny metode at udføre opgaven på.

En anden ting der sker er ledelsen begynder at blande sig i hvilke og hvordan software nede i organisationen skal implementeres og fungere. Det har de bare ikke forstand på.

Ofte oplever jeg at medlemmer i et team har ikke nogen som helt idé om hvad det software som de laver skal bruges til eller hvilken værdi en specifik funktion har. Og så ender vi i en uendelig løkke af møder. Og her er det både "kunde" og "leverandør" der fejler.

Software er en opgave som skal udføres af specialister inden for det område som opgaven berammer og ikke af specialister i et sprog eller en metode.

Herefter kan der nogle gange leveres 10 gange om dagen og andre en gang om måneden eller året.

  • 1
  • 0
#27 Allan Ebdrup Blogger

Jeg ville nok fokusere på noget lidt andet: "Tør du ?"

Ja, jeg er meget enig med dig i. Det handler også om at turde gøre noget. Det er både det jeg mener med 'det forsigtige barn' der er blevet bange for ilden og ikke tør lege med den, og den "smerte" du skal gøre værre, ved at gøre det oftere.

Der er langt mindre grund til at være bange for kvalitetssoftware.

Helt sikkert. Min påstand er så, at hvis der er noget du er bange for at gøre, fordi du ikke er sikker på kvaliteten af din software. Så:

1) Nogle bliver "panisk angste" som du skriver, og gør det de er bange for mindre og mere omstændigt. Det gør problemet værre. 2) Det, at tvinge dig selv til at gøre det meget oftere, vil være en effektiv måde at få bedre softwarekvalitet (i mange tilfælde). Selvfølgelig ikke bare hovedkuls gøre det oftere. Det skal gøres oftere, men på en måde man kan stå inde for. At gøre det meget oftere tvinger dig til at gøre noget ved de undeliggende problemer. Tage fat om nældens rod og rive til.

  • 2
  • 0
#28 Janich Rasmussen

Det lyder nu som en noget mere moderne tilgang til webudvikling end mange andre virksomheder praktiserer, men jeg er ret enig i grundprincipperne.

Det virker dog mærkværdigt at mindre kontrol og review giver færre fejl. Er det simpelthen fordi fejlene ikke bliver fundet på denne måde? Eller var referencen på de 44% for brugerrapporterede fejl?

Og i tillæg ... hvordan håndterer I reelt set fejl, deployet til produktion? Med debug og test i prod, eller måske genskabelse i et kontrolleret testmiljø?

  • 0
  • 0
#29 Allan Ebdrup Blogger

Det er i ganske få tilfælde vi har brugt mindre kontrol, som ved kodereview. Her handler ændringen mindst lige så meget om at den enkelte udvikler har ansvaret og ikke kaster det "over hegnet" til en reviewer pr automatik.

At du som udvikler beder om et review, men stadig står assignet til opgaven, helt til den er i produktion. Har betydet at vi aldrig ser problemet med at en opgave hænger i en review kolonne i et taskboard i flere dage.

Ændringen har betydet, at alle udviklere er blevet meget sødere til at lave et review med det samme. Ikke noget med at vente til jeg lige er færdig med det jeg sidder med først. Og det har vist sig, at være en meget mere effektiv måde at arbejde på.

Selvfølgelig kan man sig nej til at lave et review hvis man er dybt begravet i noget. Men så er det udvikleren der beder om review's ansvar at finde en anden der har tid. Og det fungerer faktisk gnidningsfrit.

Det virker dog mærkværdigt at mindre kontrol og review giver færre fejl.

At deploy'e ofte kræver selvfølgelig at vi automatiserer vores kontroller. Du kan ikke gøre ting manuelt. Så vi har nærmere fået mere kontrol. Den er bare automatisk og kører derfor meget oftere.

Er det simpelthen fordi fejlene ikke bliver fundet på denne måde? Eller var referencen på de 44% for brugerrapporterede fejl?

Fejlene bliver helt sikkert fundet. Referencen på 44% er både fejl fundet af QA, fejl fra fejlloggen i produktion og fejl rapporteret af brugere. Med over 300.000 registrerede brugere får vi hurtigt fejlrapporter ind hvis der er noget der ikke virker.

Og i tillæg ... hvordan håndterer I reelt set fejl, deployet til produktion? Med debug og test i prod, eller måske genskabelse i et kontrolleret testmiljø?

Vi - Genskaber normalt fejlen på udviklerens maskine. - Laver en test der er rød, pga fejlen. - Retter fejlen så testen bliver grøn. - Deployer til produktion. Enhver deploy til produktion bliver altid automatisk kørt gennem vores fulde testsuite før det kommer i produktion.

Der er selvfølgelig varianter af dette hvor fejlen skal genskabes i et test miljø som ligner produktion. Vi kan tilføje mere logging i prod. Og en enkelt gang har jeg ringet til en sød ældre herre i Australien for at genskabe problemet på hans computer.

  • 2
  • 0
#30 Troels Henriksen

Jeg vil stille spørgsmål til om disse metoder overhovedet giver programmel af god kvalitet. Når jeg tænker "god kvalitet", så tænker jeg ikke "virker det overhovedet?" - det antager jeg er så triviel en forventning, at det ikke er noget man behøver nævne, og der findes allerede mange teknikker der kan hjælpe. Der er naturligvis ingen sølvkugle, som nævnt ovenfor.

Når jeg tænker "kvalitet", så tænker jeg på om dokumentationen er dækkende og forståelig, om koden er robust og effektiv, om den er begrænset i features til det essentielle, og om dens abstraktioner, begreber og interne logik er rationel, forståelig og sammenhængende. Jeg vil langt hellere have indsigt i hvordan disse problemer kan løses, for det kan nok ikke klares med et cronjob der rsync'er ti gange om dagen.

Når kokke snakker om hvordan man laver en god burger, så fokuserer de forhåbentligt ikke primært på hvordan man undgår at den er giftig.

  • 3
  • 0
#31 Finn Christensen

Når kokke snakker om hvordan man laver en god burger..

Kokke snakker ikke om burger, men mange ikke-kokke har da selvfølgelig en naturlig interesse i at lege med ikke-mad.

Sådan er der også med it-arkitekter, udviklerne og driftsfolk - vi er som mennesker hverken ensartede kloner, eller lige seriøse eller 'gode' rent fagligt.

Den sidste selvlærte udvikler med oprindelse som damefrisør eller cykelsmed sidder garanteret endnu derude, og laver selv i dag fremragende arbejde på højt niveau, men han er undtagelsen.

  • 0
  • 0
#32 Allan Ebdrup Blogger

Når jeg tænker "kvalitet", så tænker jeg på om dokumentationen er dækkende og forståelig, om koden er robust og effektiv, om den er begrænset i features til det essentielle, og om dens abstraktioner, begreber og interne logik er rationel, forståelig og sammenhængende. Jeg vil langt hellere have indsigt i hvordan disse problemer kan løses, for det kan nok ikke klares med et cronjob der rsync'er ti gange om dagen.

Du har fuldstændig ret i at dette blogindlæg kun handler om en bestemt vinkel på kvalitet, og det kan ikke stå alene. Men jeg vil fastholde, at det jeg skriver om også har en stor indflydelse på din softwarekvalitet.

Du kan fx kigge på denne forskning fra Microsoft Research http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx Der viser at organisationen omkring koden er den vigtigste faktor de fandt ifht kodekvalitet.

Jeg er helt enig med dig i, at de andre aspekter af kodekvalitet du beskriver er mindst lige så interessante og vigtige.

  • 0
  • 0
#34 Allan Ebdrup Blogger
  • 0
  • 0
#35 Ulrik Suhr

Enig, havde håbet på et andet syn på udviklingen og muligheder for højne kvaliteten og derigennem forbedre hastigheden.

Tror principperne man kunne diskutere er indeholdt i SOLID tangegangen. Jeg syntes også det med simple navngivning og CQS giver en rigtig god kvalitet når man skal finde fejl 6+ måneder senere (dette kan dog ikke stå alene). Eller så simple ting som nye features skal medfølges af test, så derved overdrager man ikke opgaven og glemmer vigtig information. Den er faktisk så godt dokumenteret at den kan testes under hele udviklingen!

Artiklen definere ikke kvalitet, men prøver at argumentere for denne. Det er hvad andre debattører referere til som helsekost argumentationer. Jeg er desværre ingeniør og vil selvfølgelig stille spørgsmålet.

"hvorfor deployer i kun 10 gange når du siger det har en gavnlig effekt?" Jeg ville argumentere for i er nogle dovne hunde og ingen respekt har for jeres brugere når i "kun" deployer 10 gange....

Måske er det rigtige tal 50 eller 100. Her kommer så hvad risiko er for bruger/udvikler. Hvad koster en fejl at rette hvordan er data med fejl at rette etc. Uden det er 50 gange vel et bedre tal?

Tror jeg tager det med fra artiklen at man skal deploye så ofte som man kan uden det koster da man derigennem får så ny kode så muligt (derigennem nok også bedre kode).

  • 0
  • 0
#36 Allan Ebdrup Blogger

"hvorfor deployer i kun 10 gange når du siger det har en gavnlig effekt?" Jeg ville argumentere for i er nogle dovne hunde og ingen respekt har for jeres brugere når i "kun" deployer 10 gange....

Hvor mange gange man deployer om dagen er ikke så vigtigt. Det der er vigtigt er at du kan deploy'e med ro i sindet, uden nogen form for frygt, lige når du har lyst.

Vi har haft en løs regel om at når man deployer skal man holde øje med produktion in 15-30 minutter. Ikke noget med at deploy'e og så smutte ud af døren.

Her til morgen talte vi faktisk om at fjerne den regel, fordi vi efterhånden er holdt op med at følge den. Der er jo ikke grund til at have en regel der ikke bliver fulgt.

Jeg tror på det er gavnligt, at du har så meget styr på din kvalitet, at du tør trykke på deploy-knappen, og mens der rulles ud, pakker du dine sager sammen og tager på weekend.

  • 0
  • 0
#37 Michael Zedeler

Hvad gør vildhesten hvis den kommer til at deploy'e et modul, som ved en fejl sender rykkere til samtlige kunder på et produkt, de ikke har købt og bagefter sletter produktionsdatabasen?

Jeg ved godt at det er en smule fortænkt, men er det alle ændringer som i ruller ud på den der super-agile måde?

Ellers et godt indlæg, men det kunne være rart at få kastet lys over hvad man gør med de ændringer, der kan få himlen til at falde ned, hvis de går galt.

  • 0
  • 0
#38 Allan Ebdrup Blogger

Hvad gør vildhesten hvis den kommer til at deploy'e et modul, som ved en fejl sender rykkere til samtlige kunder på et produkt, de ikke har købt og bagefter sletter produktionsdatabasen?

Der ligger vel implicit i dit spørgsmål at vildhesten på en eller anden måde skulle have større sandsynlighed for at dit skrækscenarie sker, end det forsigtige barn. Men min påstand er at sandsynligheden for at det du beskriver sker er større hos det forsigtige barn.

Alt der har med databasen at gøre er dækket af grundige automatiserede tests hos os.

Men hvis de ting du beskiver sker er der ikke nogen forskel på hvordan vildhesten og det forsigtige barn håndterer situationen.

Det er vel noget med at alle dem der har fået rykkeren skal have en undskyldning og databasen skal hentes fra en backup.

  • 0
  • 0
#39 Allan Ebdrup Blogger

Jeg ved godt at det er en smule fortænkt, men er det alle ændringer som i ruller ud på den der super-agile måde?

Jeg skal måske lige præcisere. Vi har selv været meget bange undervejs. Men det vi har gjort er, at gøre noget ved vores frygt, ved at automatisere kvalitetskontroller og tage alle mulige forholdsregler. Vi er meget grundige.

Vi har massere livrem og seler, backups til flere steder, hvis databasen ryger har vi 3 forskellige måder at lave recovery på.

Når vi migrerer data til en ny datamodel, tester vi meget grundigt, og tager backup og logger alt der foregår. Vi har bygget et opensource modul til migreringer af data, som logger og som håndterer alle mulige edgecases og concurrency problemer på en meget grundig måde. Forholdsvis simpelt, men det er med livrem og seler. Vi har open sourcet det her: https://github.com/e-conomic/mongopatch

Vores automatiserede test dækker hele vores API og forretningslogik meget grundigt. Disse ting er dækket grundigt, fordi det er dem der laver ændringer i databasen. Vi er også bange for korrupt data, vi har håndteres vores frygt med automatiserede tests.

Vi går med livrem og seler når vi deployer. ALT der deployes skal gennem hele testsuiten. Også selv om produktion er helt nede og du gerne vil fikse det hurtigt - du får ikke lov at ligge din rettelse på der får produktion op igen, uden at den er kørt igennem hele testsuiten. Så må vi tage de ekstra 4-5 minutters nedetid. Hellere det end at risikere at rulle et bugfiks på der korrumpere data.

Selv om du er en "vildhest" skal du gøre tingene grundigt, ordentligt og på en måde du kan stå inde for.

  • 1
  • 0
#40 Ulrik Suhr

Ok så ja jeg er enig, men det har ikke så meget med en "vild hest" at gøre i min verden. Jeg er enig om man ikke skal vælge at deploye så lidt så muligt, men det er kun fordi man har en release strategi som er solid. Vi har den samme ide her. ved fejl laves en test som dækker denne og din indrulles i testsuiten. TC serveren får så de rettelser som kommer og hvis dine rettelser slipper igennem testsuiten rulles de ud til maskinerne som benytter programmet.

Jeg laver egentlige release versioner så tit så muligt, men reelt så rulles der nok en ny patch på brugernes maskine 1-2 gange dagligt. Det sker ved opstart eller login at deres maskin script tjekker om der er kommet nye versioner som skal installeres.

Så jeg er 100% enig, men sådan tror jeg også de fleste analytiske Ingeniører er. Jeg er villig til at arbejde hårdt i mange timer for at løse et problem på en måde så det enten løses automatisk næste gang eller ved et knaptryk :).

sidder lige nu med en opgave hvor programmet har fået en rettelse for (sikkert lang tid siden) som gør det langsommere at starte nogle dele at softwaren. I stedet for at løse problemet lige med det samme opretter jeg 2 tasks. 1. selve info om hvad skal rettes og hvor jeg tror buggen er. 2. oprette et script som monitorere gennemløbstid for typiske test og reportere til udviklerne hvis der sker drastiske negative ændringer.

Skal dette test script så stoppe udrulningen eller skal den kun give besked. Det er så det jeg bokser med i dag :)

  • 1
  • 0
#41 Allan Ebdrup Blogger

Skal dette test script så stoppe udrulningen eller skal den kun give besked. Det er så det jeg bokser med i dag :)

Vores erfaring er, at sådan nogle checks altid skal stoppe udrulningen. Advarsler (warnings) duer ikke, så kan man lige så godt lade være med at have checket.

Hvis det så sker at der kommer brok over checket, fordi det er rødt hvor det ikke burde være det, skal man enten fjerne det helt, eller forbedre det, så det er så godt, at man kan stole på at rød er et problem der skal fikses.

  • 1
  • 0
#43 Allan Ebdrup Blogger

Enig, men det kan jo være denne faktisk er en godartet "fejl" dvs. en beregning tager længere tid fordi der er inkluderet flere betingelser :). Det er hvad der oftest sker når de opdager en beregning er for simpel eller der er kommet nye parameter man kan regne på.

Jeg tror ikke et check der ligger "på vippen" til at blive rødt og en lille ændring kan gøre det rødt dur. Desværre giver det nok kun mening at fange "bøffer" hvor tingene er blevet meget langsommere med den slags checks.

Giver det ikke mening at jeres brugere har en "smertetærskel" for opstartstiden og sætte checket til denne tærskel?

Den løbende performance give nok mening at måle og analysere kontinuerligt som du var inde på. Men det vil jeg nok måle i "produktion". Måle og monitorere hvordan tingene performer på brugernes maskiner med et log-tool af en slags hvor du kan trække rapporter og grafer. Og så have en monitor på kontoret der viser grafen hele tiden.

  • 0
  • 0
#44 Jn Madsen

Vil lige give mit pip med. Jeg pipper med 29 års erfaring i tele og data.

I telekommunikation og netværksbranchen snakker vi 99,999%'s oppetid. Fejl er utænkelige og katastrofale,- man tester og afprøver.

Ja,- når jeg sidder og leger med mine hjemmesider eller min Apache server,- så er det kun sjovt og ligegyldigt når det ikke virker.

Men der er ingen der griner når 112 eller et stort hospital mister al tele og datakommunikation. Det er tæt livslang exkommunikation og bandlysning at fumle der. Der er ingen der "prøver sig frem" eller "satser på ...".

Ikke alle kunder tager fejl med et skuldertræk. Nogle kunder betaler for,- og kontrollerer en gang i sekundet om tingene virker. 1 sekunds nedetid straffes med bøder og skal redegøres for i tommetykke dokumenter. Servicevinduer varsles mange uger i forvejen.

Det er nok noget med hvor vi branchen vi står, når vi taler om kvalitet.

  • 3
  • 0
#45 Allan Ebdrup Blogger

I telekommunikation og netværksbranchen snakker vi 99,999%'s oppetid. Fejl er utænkelige og katastrofale,- man tester og afprøver.

Det er da super, jeg kan ikke se at der er noget af det jeg skriver der siger at man ikke skal kunne gøre det. Hvis du ser modstrid i det jeg skriver mod at have 99,999%'s oppetid, så må du gerne dele hvad det er.

Det kunne være spændende hvis du skrev lidt om hvordan i kvalitetssikrer :-)

  • 0
  • 0
#46 Jn Madsen

Det er da super, jeg kan ikke se at der er noget af det jeg skriver der siger at man ikke skal kunne gøre det. Hvis du ser modstrid i det jeg skriver mod at have 99,999%'s oppetid, så må du gerne dele hvad det er.

Det kunne være spændende hvis du skrev lidt om hvordan i kvalitetssikrer :-)

Hehe,- jeg ser da rigtigt mange gode ting i det du skriver. Min kæphest er "Work smarter, not harder", jeg arbejder bare i en del af IT verdenen, hvor der bare ikke må ske fejl. Man tester og afprøver konstant. Man tager aldrig noget nyt ned af hylden og smækker det i produktion.

En lille ændring det ene sted, kan sende "chockbølger" ind i snesevis af andre IT-systemer, eller lave ged i den for titusinder (eller flere) af kunder.

Så man ender i "Lav det rigtigt første gang, det er det nemmeste og billigste".

I meget store komplekse systemer,- jeg kommer fra en verden hvor produktionen er afhængig af flere hundrede systemer,- og hvor ingen enkeltperson er i nærheden af at have end-to-end overblik,- der undgår man bare ikke at bruge tid på møder, tests, prototyper og alt det andet.

Men det er en dynamisk proces, man leder jo konstant efter hjørner at skære og andre genveje. Der er ingen der ønsker at spilde tid og penge. :-)

  • 1
  • 0
#48 Allan Ebdrup Blogger

I meget store komplekse systemer,- jeg kommer fra en verden hvor produktionen er afhængig af flere hundrede systemer,- og hvor ingen enkeltperson er i nærheden af at have end-to-end overblik,- der undgår man bare ikke at bruge tid på møder, tests, prototyper og alt det andet.

Nu må du rette mig hvis jeg tager fejl. Men jeg ville gætte på, at i ser enhver manuel test som en risiko. En test der ikke er automatiseret, kan jo udføres forkert. Kræver jeres 99.999%'s oppetid ikke, at i har automatiseret meget store dele af jeres kvalitetskontrol?

Jeg ville også gætte på at TDD vil være godt til jeres udvikling. Microsofts forsking som jeg henviste til, viste at TDD giver højere kvalitet, men er 15-35% langsommere.

  • 0
  • 0
#49 Peter Stricker

TDD giver højere kvalitet, men er 15-35% langsommere

Undskyld, jeg igen tager fat i en lille detalje om nogle procentsatser. Men man skal godt nok have god styr på sine estimater for at kunne måle et så lille udsving.

Det ser ud til, at satserne er udtryk for en mavefornemmelse, snarere end et emperisk studie, hvilket rapporten påstår at være. I slutningen af rapportens abstract står der:

Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

(min fremhævning)

Og i tabellen Outcome measures (tabel 3, nederst på side 297) står der:

Increase in time taken to code the feature because of TDD (%) [Management estimates]

(min fremhævning)

Men all right, hvis vi alligevel tager de 15-35% for pålydende og regner med at det er den tid der er brugt inden man begynder at rette fejl, så lyder det faktisk som et ret godt resultat. Selv om rapporten desværre ikke nævner noget om, hvor lang tid man efterfølgende har brugt på fejlretning.

  • 1
  • 0
#50 Jn Madsen

Hmm ...

Jeg vil sige at det meste sker ad hoc. Mange rutinerede hoveder, der har set tingene 100 gange før, de stikker snuden sammen og finder ud af hvad der i det konkrete tilfælde er det bedste.

Om det er ud fra den ene filosofi eller den anden,- det er ikke så vigtigt. Man stoler på folks vurderingsevne. Dem der gentagne gange vurderer forkert,- de er der bare ikke mere.

Det er et miljø der er blottet for floskler, store tanker og hypoteser. Meget jordnære arbejdsgange med folk der kender deres systemer bedre end deres familie der hjemme :-)

Selvfølgeligt. Nogle systemer testes efter de gamle standartiserede metoder,- nogen gange er der standart proff-of-concept,- men ellers er det ad hoc. Hvordan får vi fyldt hullet? Hent en skovl og ham med de store overarme.

  • 0
  • 0
#51 Jn Madsen

Selv om rapporten desværre ikke nævner noget om, hvor lang tid man efterfølgende har brugt på fejlretning.

Den er sjov. Gennem årene har man netop set dette utallige gange.

En eller anden chef "super-duper-optimerer" efter sidste nye hotte principper. Efter implementationen drukner alles postkasser med powerpoint shows og mails med begejstrede beretninger om den uforlignelige succes. Man må også Google hvert 3' ord,- alle de nye smarte termer har man slet ikke styr på.

Der nævnes ikke et ord om det vognlæs møg fejlretningen måtte tage hånd om.

  • 0
  • 0
#52 Allan Ebdrup Blogger

Men all right, hvis vi alligevel tager de 15-35% for pålydende og regner med at det er den tid der er brugt inden man begynder at rette fejl, så lyder det faktisk som et ret godt resultat. Selv om rapporten desværre ikke nævner noget om, hvor lang tid man efterfølgende har brugt på fejlretning.

Ja, jeg har ikke kunnet fremdrive bedre forskning i TDD. Men de resultater stemmer meget godt overens med hvordan vi intuitivt bruger TDD.

Når noget er "algoritmisk" og bare skal være rigtigt bruger vi TDD. De fleste andre ting skriver vi test til efter og under udviklingen. Jeg oplever TDD som givende højere kvalitet, men langsommere. (ikke videnskabeligt målt overhovedet)

  • 0
  • 0
#53 Jesper Louis Andersen

Nu må du rette mig hvis jeg tager fejl. Men jeg ville gætte på, at i ser enhver manuel test som en risiko. En test der ikke er automatiseret, kan jo udføres forkert. Kræver jeres 99.999%'s oppetid ikke, at i har automatiseret meget store dele af jeres kvalitetskontrol?

De 99.999% kommer af mange forskellige ting. Først og fremmest, så opnås den høje kvalitet ved at du ikke presser dine udviklere til at levere hurtigere, men at levere mere korrekt. Det betyder at ting tager den tid som ting tager og at man ikke "forhandler" om hvor en eventuelt deadline placeres.

Koden du skriver er konstrueret således at den indeholder failsafes, overvågning, analyse og meget andet. En stor del af eksekveringen handler om at verificere korrektheden af det der sker. Og stoppe i tide. Man kan så starte systemet fra en kendt, sikker tilstand efterfølgende. Det hele sker naturligvis automatisk.

Systemet er distribueret. Det medfører at der er redundans, hvis uheldet er ude og en fejl, hardware eller software, tager en delkomponent ud af drift. Som oftest har dette temmeligt stor indvirkning på hele systemets udformning og det skal tænkes ind fra dag 1 hvorledes kommunikationen foregår. Du kan ikke frankensteine det her ind senere.

Den anden ting er en seriøs fokus på test. Det handler ikke bare om at skrive unit-tests og få 100% coverage, eller om at programmere med TDD. Det handler om at du har et team der er dedikeret til at skrive testkode og testværktøjer. Det er formentlig over 60% af dine udviklere der sidder i denne rolle.

Du benytter alle værktøjer der findes: unit testing, statisk verifikation (lint, findbugs, valgrind, coverity), test-generering (model checking, quickcheck), matematisk bevisførelse (muligvis mekaniseret/maskinstøttet).

Dit system indsamler løbende metrikker for hvordan det opererer og de benyttes til at finde fejl før de opstår i produktionen. Ofte kan den rigtige metrik afsløre et problem længe inden katastrofen indtræffer.

Du hyrer virkeligt gode sysadmins til at overvåge dit system. En stor del af de 99.999% kommer af folk der ved hvad de gør og kan lugte at det ryger langt tid før det egentlige problem indtræffer. Analyse af sådanne systemer afslører som regel at de hele tiden er på vippen til katastrofen og at det er sysadmins der redder systemet.

  • 2
  • 0
#54 Allan Ebdrup Blogger

Tak fordi du deler hvordan i gør Jesper. Spændende læsning. 60% af udviklerne der er dedikeret til at skrive testkode og testværktøjer. Det giver mening.

Det betyder at ting tager den tid som ting tager og at man ikke "forhandler" om hvor en eventuelt deadline placeres.

Vi arbejder næsten heller aldrig med deadlines. Min erfaring er, at deadlines bør undgås hvis de overhovedet kan. De får folk til at tage de forkerte valg og arbejde "uintelligent".

Du kan skære i forretnings-scope og ændre på hvad vi skal arbejde på lige nu. Men udviklingen er færdig når den er færdig.

  • 0
  • 0
#56 Morten Jensen

For en god ordens skyld, så er det ikke hvad jeg gør, men hvad jeg ved andre virksomheder gør. Virksomheder hvor 99.999% oppetid er en realitet.

Hvilken branche tænker du specifikt på dér? Jeg møder forbavsende få der har kendskab til formelle metoder (fx. model checking og maskinstøttet theorem proving) og endnu færre der anvender det kommercielt.

Jeg skriver realtidskritisk embedded software, og til kompliceret eller kritisk kode bruger jeg bounded model checking til statisk at verificere at koden overholder en specifikation. Jeg bruger selvfølgelig også klassiske tools til statisk analyse ala lint og clang-analyzer.

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