Features en kwaliteit

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. Het aantal klanten loopt in de honderden en je hebt veertig mensen in dienst. Je programmeert al lang niet meer zelf. Het product is uitgegroeid tot drie miljoen regels code. En nog altijd hebben de 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 weing kaas gegeten. Je ooit zo overzichtelijke codebase is in spaghetti veranderd. Niemand durft de database nog aan te raken. Testen staat op een laag pitje. Er zijn helaas geen unit tests. Maar wel bugs. “Bij iedere bug die we oplossen, introduceren we ergens anders weer een nieuwe”, verzuchten de ontwikkelaars. En eigenlijk is ook de user interface aan vernieuwing toe. De klanten klagen over gebrek aan innovatie of stappen over naar een concurrent.

Herkenbaar patroon? Ik zie het helaas keer op keer terugkeren. Vaak bij kleine tot middelgrote organizaties. Ooit klein begonnen, maar onstuimig doorgegroeid. 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 rucksichtlos 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 vol enthousiasme en goede moed 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.

Tegelijkertijd is de druk om voortdurend nieuwe features te kunnen verkopen groot. Vaak zo hoog dat teams er voor kiezen het werken aan de kwaliteit van de code voor zich uit te schuiven. Begrijpelijk. “We hebben deze nieuwe feature al verkocht aan de klant,” stelt de 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.”