Min 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!
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.
