Av : Karl Dickson | 2010-05-10 21:04

KvalitetstetraederMin känsla är att man idag i de flesta sammanhang, på goda grunder, sätter time-to-market framför kvalitet. Men när bör motsatsen gälla? Vilka system, eller delsystem, är så kritiska att de inte får innehålla buggar? Det är självklart en gråzon, men när krävs det idag riktigt robusta och felsäkra system?

När jag pratar med jämnåriga och äldre utvecklare, aktiva utvecklare som varit i branschen under hela 90-talet, händer det ofta att frågan om kvalitet dyker upp. De flesta verkar vara eniga om att kraven på kvalitet har minskat de senaste 15 åren. Till förmån för fler funktioner, kortare cykler och snabbare leveranser.

En hypotes som jag har är att detta bland annat beror på att vi har vant oss vid buggiga system och att det därför inte riktigt lönar sig att konkurrera med kvalitet. Och att vi har vant oss har säkert många orsaker.

Några orsaker som jag kommer på är:

  • Vi har blivit vana vid att webben är buggig med brustna länkar och servrar som inte alltid svarar etc.
  • Öppen källkod och olika gratisprogram har fått ett stor genomslag. Jag tycker att det är helt fantastiskt på många sätt – ett mynt med en stor härlig framsida. Men myntet kanske har en baksida också – gratisprodukter kan man inte gärna klaga på. Det är det där med att ”skåda given häst i munnen”. Vilket leder till låg kvalitet och bristfällig dokumentation i många gratisprogram. Vilket också har vant oss vid lägre kvalitet.
  • Billigare distribution (webbappar, Java Webstart, etc.) har gjort att man kan släppa buggiga system tidigt och sedan lappa vartefter felen upptäcks av användarna. Vilket också har vant oss vid buggiga system.
  • Mobiltelefonin har slagit igenom, och vi har härdats med dålig täckning och många avbrutna samtal. Fördelarna med mobiliteten har fått oss att acceptera en kvalitet som hade varit långt ifrån acceptabel när vi bara hade fast telefoni.

Och om användarna vänjer sig vid dålig kvalitet är det också svårt att konkurrera med kvalitet.
Vad kostar kvalitet? Finns det en konflikt mellan kvalitet och lättrörlighet? Eller handlar det om olika typer av kvalitet? Kräver kvalitet gedigen arkitektur? Och kräver kvalitet gedigen dokumentation? Utöver kommentarer i koden? Och utöver testprogram?

Finns det några utvecklare där ute som själva känner att de sitter i projekt där kvalitet faktiskt prioriteras framför många funktioner och snabba leveranser? Hör av er och berätta!

Bokomslag - Varför är det så ont om Q?
Trivia: Hasse Alfredssons bok med titeln ”Varför är det så ont om Q?” har mig veterligen ingenting med Quality att göra. Det är en barnbok som slutar med att Q-hunden stoppar i sig alla Q eftersom bokstaven liknar en katt bakifrån.

Bloggar etiketter:

5 kommentarer to “Varför är det så ont om Q?”

  1. Ponts Bergöö skriver:

    ”– Ha, din förbultade underdogg! Vill du vara så förbankat ambivalent och städa upp här inne, sa Boven till Q-hunden.”

    Det finns branscher där Q är A och O. Själv jobbar jag med medicinteknik och där kan en bugg inte bara vara skillnaden mellan liv och död utan också äventyra hela företagets existens. En konkurrent hade ett fel i sin implanterbara defilibrator som inte bara orsakade en patients död, utan den började också ge ifrån sig elchocker och varningssignaler under begravningen. Resultatet blev naturligtvis ett enormt skadestånd och en total badwill som nästan fick företaget i konkurs.
    Men även i min bransch och bland mina kollegor så finns det ett enormt driv att bli klar snabbt, fatta snabba beslut och en otålighet att ständigt gå vidare. Jag tror att det i mycket sitter inne i huvudet på utvecklaren. En föreläsare på JFokus häromåret sa att det finns statistik på att en programmerare har tålamod att leta efter något man behöver i mindre än en minut innan man ger sig på att skapa egna lösningar. Inte konstigt att ett genomsnittligt mjukvaruprojekt har mer än 80% kodduplicering. Men jag har under mina år aldrig varit med om att en projektledare eller chef har sagt till någon programmerare att skynda på och tumma på kvaliteten.
    Så vad beror det på? Kanske är det en speciellt otålig personlighetstyp som dras till programmeringsyrket. Eller så är det tekniken och hantverket i sig självt som lockar fram begäret efter omedelbar behovstillfredsställelse. Eller någonting helt annat, jag vet inte. Men något jag vet är att all förändring måste börja med mig själv och min egen attityd. Om jag signalerar att jag inte vill skriva fulkod så är det få som kommer att kräva det av mig. Nu har jag inte jobbat med webben så jag vet inte riktigt hur det går till där. Men jag har en känsla av att kvalitet prioriteras högre i den inbäddade världen.
    Jag skulle kunna mala på här om hög moral och det kategoriska imperativet. Men det är ju så att hög kvalitet inte alltid är det bästa beslutet. Trots det försöker jag alltid följa Kent Becks goda råd. ”Lämna alltid koden i ett lite bättre skick än du fann den.”

  2. Karl Dickson skriver:

    Oj! Från Q-hunden till Kant! :-)

    Jag håller med dig om att det är svårt att sätta några tydliga riktlinjer för kvalitet. Liksom att det är mycket sunt att hålla den tekniska skulden under kontroll.
    Det är också mycket roligt att höra att det finns utvecklare som känner att det ställs krav på kvalitet. Det vore roligt att höra om fler exempel från andra domäner än medicinteknik. I vilka domäner är Q A och O?

    Jag tror att arbetsgivare som månar om kvalitet verkligen skulle kunna tjäna på att marknadsföra detta. Det skulle leda till en bättre matchning av utvecklare och arbetsgivare. För om man hårddrar och generaliserar en smula så är det väl så att i alla vissa utvecklare (läs personlighetstyper) lutar mer åt eftertanke och kvalitet än andra som kanske lutar mer åt att vara otåliga och fatta snabba beslut. Fast egentligen kanske det är så att de flesta arbetsgivare egentligen har behov av en lagom mix av ”eftertänksamma” och ”otåliga”.

    För att återgå till min ursprungliga spaning så är i alla fall fortfarande min känsla att vi generellt över den senaste 15-årsperioden har sett en förskjutning mot snabba beslut på bekostnad av kvalitet.
    När det gäller not-invented-here så finns det också två sidor som är kopplade till kvalitet. Jag är en förespråkare av återanvändning och ett viktigt argument för återanvändning har varit just kvalitet. Kod som används av många och i många sammanhang testas hårdare och får därför högre kvalitet. Det som jag nu tycker mig märka är de många ramverk som finns alltmer följer den allmänna tendensen till att funktion och snabba leveranser får hög prioritet på bekostnad av kvalitet. Och bristfällig kvalitet i ramverk som används av många gör att låg kvalitet sprids som ringar på vattnet. Men oj så mycket vi kan producera på kort tid!

  3. Ponts Bergöö skriver:

    ”Den tekniska skulden” är ett exempel på hur jag i all välmening ska motbevisa en av dina bi-teser Karl. Den att ”Varför är det så ont om Q?” inte har med Quality att göra. Den handlar om ”Tjuven” som aldrig har fått något namn och vill stjäla alla bokstäver i hela världen för att han är så avundsjuk på alla som har ett namn. När han väl får ett namn på slutet så blir han snäll, även mot Q-hunden.

    Och det är just precis det som alla stora programmeringsgurus, så som Kent Beck, Martin Fowler, Gang of four och Eric Evans sysslar med. De ger namn åt kvaliteter och företeelser inom programmering. Och det är först när vi har namn som vi kan diskutera och åtgärda kvalitetsproblem. Designa kod handlar ju också till stor del om god namngivning. En mycket väsentlig del av ett mönster är dess namn. Och Eric Evans har byggt upp en hel skola, Domain Driven Design, kring att det är viktigt att man skapar ett gemensamt språk, ubiquitous language, för domänen.

    Det finns ju även väl etablerade skolor för hur man skapar balanserade team med hjäp av att matcha olika namngivna personlighetstyper. Och det finns fyra grundläggande typer som bör representeras, Producer, Processor, Relator och Motivator. Det går tillbaks till C.G. Jungs teorier som är runt 100 år gamla.

  4. Karl Dickson skriver:

    Jag skrev ju att boken ”mig veterligen” inte hade något med kvalitet att göra. Nu vet jag alltså bättre! :-)
    Undrar om Hans Alfredsson vet att hans bok har med kvalitet att göra? :-)

    Hur som helst håller jag med dig helt om att namn är viktiga. Mycket viktiga! Jag gillar alla författarna (deras böcker) som du nämner mycket och är en varm förespråkare av t.ex. designmönster. Jag var förresten med och utvecklade en av landets första kurser om designmönster när GOF-boken fortfarande var ny i mitten av 90-talet.

    När det gäller det där med olika skolor för att kategorisera mänskligheten i några få olika personlighetstyper är jag dock lite mer skeptisk. Oavsett om det är Jungs eller något annat så tror jag att de förenklar för mycket. Däremot tror jag att de kan vara mycket användbara för att inspirera till en diskussion om våra lik- och olikheter. Och det är något som är viktigt i de flesta team. Diskussionen och medvetenheten alltså.

    Blev inspirerad och gjorde just ett test på http://www.humanmetrics.com/cgi-win/JTypes1.htm. Den här gången blev jag INTJ. Vore kul att göra testet om en vecka och se vad jag blir då. :-)

  5. Ponts Bergöö skriver:

    Självklart kan man fånga in en hel människa i ett tvådimmensionellt diagram. Som alla modeller har ett värde bara om man har användning av den. Om inte annat så föder den intressanta diskussioner.

Lämna en kommentar

*
css.php