Nieuwe features en kwaliteit

0

Stel. Je wordt wakker met een goed idee. Je pakt je laptop en begint te programmeren in de taal die je het beste ligt. Visual Basic for Applications. PHP. Javascript. Niet heel veel later is je applicatie klaar. Je toont de applicatie aan een vriend wiens probleem ermee is opgelost. Je eerste tevreden klant is binnen.

Vervolgens geef je her en der wat enthousiaste presentaties en de klanten snellen toe. Veeleisende klanten die graag nieuwe features aan je product toegevoegd zien. Met veel plezier bouw je ze in. En niet veel later release je een splinternieuwe versie van je product. En die trekt weer meer klanten aan. Al snel kun je het werk niet meer alleen af. Dus begin je een eigen bedrijf.

Nu is het twaalf jaar later. Je hebt veertig mensen in dienst die honderden klanten bedienen. Je programmeert al lang niet meer zelf. Het product is uitgegroeid tot drie miljoen regels code. En nog altijd hebben klanten nieuwe wensen en eisen.

Alleen, het toevoegen van nieuwe features gaat steeds moeizamer. Ontwikkelaars zijn gekomen en gegaan. De meeste komen vers van school en hebben van architectuur weinig kaas gegeten. Je ooit zo overzichtelijke codebase is in spaghetti veranderd. Testen staat op een laag pitje. Er zijn helaas geen unittests. Maar wel bugs. “Bij iedere bug die we oplossen, introduceren we ergens anders weer een nieuwe”, verzuchten de ontwikkelaars. Klanten klagen of stappen over naar een concurrent.

Herkenbaar patroon? Ik zie het helaas keer op keer terugkeren. Vaak bij mkb-bedrijven die onstuimig doorgroeiden. Pas als het water ze aan de lippen staat, trekken ze aan de bel. Gelukkig kan ik vaak nog helpen het tij te keren. Door rücksichtslos het roer om te gooien. Bijvoorbeeld door een nieuwe post-agile werkwijze te introduceren, geautomatiseerd testen, een vernieuwende software-architectuur zoals microservices of continuous delivery. Of allemaal.

Code breekt niet als iemand enthousiast aan iets nieuws begint. Code breekt pas twaalf jaar later als er door Jan en alleman aan is gesleuteld. Maar code breekt vooral doordat er gedurende die periode een verkeerde balans is ontstaan tussen het toevoegen van features en het bewaken van kwaliteit.

Het toevoegen van features kost tijd. Maar ook het bewaken van kwaliteit vergt tijd. Denk aan het verwijderen van dode code, het schrijven van automatische tests, het inrichten van build pipelines of het vervangen van eigen geschreven code door frameworks.

De verkoopdruk is vaak zo hoog dat teams het werken aan de kwaliteit van de code voor zich uit schuiven. Begrijpelijk. “We hebben deze nieuwe feature al verkocht aan de klant,” stelt Sales, “nee verkopen is geen optie.” Tot het te laat is en de software ononderhoudbaar blijkt. Ik begrijp heel goed dat het verleidelijk is om altijd meer te willen verkopen. Maar verlies de kwaliteit van je product nooit uit het oog. Kwaliteit hoort intrinsiek te zijn. Features zijn voor nu. Kwaliteit is voor de features van later. Of zoals Aristoteles zei: “Kwaliteit is geen daad, maar een gewoonte.”