Bugs of honor, bugs of shame

Det er flaut med bugs. Noen bugs gjør meg flauere enn andre. Andre bugs er helt akseptable. I prosjektet mitt er vi stolte av at såpass få feil finnes av testere (eller av brukere), men det er noen som faller gjennom sikkerhetsnettet vårt. Her er noen av bugsene vi har hatt i det siste, fra den minst ydmykende til den verste:

  • Bug rapport: «Administrative kostnader» skal fjernes: Når vi beregner totalkostnaden til et veiprosjekt, inkluderer vi kostnaden av nyanlegg, ombygging, bruer og administrative kostnader. Når vi demonstrerte applikasjonen til brukerne våre, husket de plutselig at administrative kostnader er sjelden i bruk og burde egentlig fjernes fra applikasjonen. Endringen var enkel og det er usannsynlig at en bedre analyse på forhånd hadde kommet fram til samme konklusjon. Dette er den type feilrapport vi liker å få.
  • Bug rapport: Ikke-effektuerte utbetalinger skal telle mot totalt tilgjengelige midler: Når vi sjekket om det var tilstrekkelige midler for å utføre en utbetaling, glemte vi å ta med de utbetalingene som var registrert, men ikke utført enda. Tilstandsovergangen av utbetalinger fra registrert til godkjent til utført var litt mer kompleks enn vi hadde forventet, og enhetstestene sjekket ikke tilstrekkelig med varianter. Vi burde ha funnet denne feilen med enhetstestene våre, men dersom vi aldri får feil av denne typen, kan det være en indikasjon på at vi er for nøye med testingen vår. Så feilen er helt grei. Spesielt ettersom konsekvensene for brukeren ikke var spesielt store
  • Bug rapport: Perioder som starter i desember rapporterer IllegalArgumentException: Når vi beregnet neste måned, glemte vi å ta hensyn til at du kan ikke bare legge til én på månedsnummer. Neste måned etter desember er ikke måned 13! Dette var en slurvete feil og jeg tror den ble introdusert en gang når vi ikke parprogrammerte (fordi koden var så triviell, liksom!). Brukerne våre forstår at slike type feil kan skje, men vi må se nøyere på prosessen vår for å unngå slike feil i fremtiden.
  • Bug rapport: Layout ser rotete ut i Internet Explorer: For å unngå noen tekniske problemer når vi skrev enhetstester for HTML’en vi produserte, fjernet vi midlertidig doctype-definisjonen fra webside-malene våre. Så glemte vi å putte definisjonen inn igjen (jada, et nytt eksempel der vi ikke parprogrammerte). Sidene så fortsatt fine ut i Chrome og Firefox, som utviklerne brukte for manuell verifisering. Men i Internet Explorer så websidene direkte kaotiske ut. Den tekniske konsekvensen av feilen var triviell, men feilen kunne lett ha vært unngått, dersom vi vi hadde testet med samme nettleser som brukerne våre. Noen av brukerne våre fikk dette håpløse førsteinntrykket av applikasjonen mens de hjalp oss å teste. Det var skikkelig flaut. Dette vil vi ikke at skjer igjen!

Det er litt vanskelig å definere hvilke bugs som gjør meg mest flau. Noen viktige faktorer er hvor vanskelig ville det vært for oss å unngå feilen og hvor stor konsekvens feilen har. Men andre faktorer påvirker også hvordan vi oppfatter en bug. Av feilene på lista over, så er den jeg er mest flau over kun en kosmetisk feil. Men siden dette var noen brukeres førsteinntrykk av applikasjonen, var det mye mer problematisk enn de særtilfellene vi ikke helt støttet.

Hva synes du gjør en feil mer eller mindre akseptabel?

Principal Software Engineer i Sopra Steria Norge. Har jobbet i 15 år med utviklingsprosjekter, hovedsaklig i Java. Arrangør og initiativtaker i fagmiljøet rundt Smidige utviklingsmetoder i Oslo.

3 kommentarer om “Bugs of honor, bugs of shame

  1. Det som er litt artig er hvor følsomme den jevne utvikler er for å få feilrapporter.

    Noen kjente og kolleger jeg kjenner tyr altfor ofte til unskyldninger og «blame-game» (er det min feil at IE ikke respekterer standarder? Er det min feil at prosjektleder ikke har opplyst meg om den forretningsregelen?). Tenk så latterlig, unødvendig og uprofesjonelt det i grunnen er..

    Dere har et ydmykt forhold til feil, og det er bra! Å vise frem sine bugs er ydmykt, lærerrikt, ærlig og viser respekt for kunden.

  2. Vil gjerne slutte meg til det Thomas sier. Er veldig glad i åpenhet, og synes det er flott at dere står frem med buglisten. Den på listen som gav meg mest vondt i magen var garantert feilen med måned nummer 13. Den viser tydelig hvor banale og idiotiske feil som kan snike seg inn i kode, og dermed også hvor viktig det er med kvalitetskontroll (som parprogrammering) på selv den minste ting.

  3. Takk for gode kommentarer, begge to. Det er fint når antall bugs er så få at man faktisk kan gå gjennom dem og analysere dem med litt detalj.

    Vi hadde én feil i april (og noen endringer som vi klassifiserte som feil). Det viste seg at i deler av applikasjonen tok vi feil av kredit og debet. Her hadde vi ikke avstemmet nok med produkteier. Det som var litt bittert var at vi visste egentlig at vi ikke visste nok om hvordan kontoføringen skulle fungere. Så noe glapp. Nå har vi fiksa prosessen.

    Det viste seg også at for å «forenkle» logikken hadde vi satt «-beløp» i metoden som opprettet en regnskapspost. Dette var fordi i det første caset vårt skulle beløpet vi fikk fra bruker inn postes med negativt fortegn. Når vi senere jobbet med regnskapsføring forvirret dette oss voldsomt inntil vi trakk negasjonen litt nærmere brukergrensesnittet.

    Moralen: Kode som er litt funksjonell vrien bør ha så få skjulte mekanismer som mulig.

Legg inn en kommentar