Software maken is een ambacht

softwareambachtSoftware ontwikkelen is een ambacht. Dat weet niet iedereen, dat weten ervaren programmeurs, en dat weten mensen die Beautiful Code hebben gelezen, of Software Craftmanship, bijvoorbeeld. “Ambacht” betekent dat je vertrouwt op de kennis en ervaring van de “meester” programmeur, en een team van “gezellen” en “leerlingen”. Zo gaat het in veel open source applicaties, applicaties die soms al tientallen jaren bestaan en worden onderhouden. Dankzij de hoge kwaliteit van de software.

Tegenover software maken als ambacht, staat de formele benadering van “software engineering”. Dan heb je een analist die schetst wat er moet gebeuren, een ontwerper die de specificaties maakt, en een programmeur die de code maakt. Het voordeel daarvan is dat mensen uitwisselbaar zijn, en dat je het project kunt versnellen door er meer mensen tegenaan te gooien. Meer mensen betekent meer kosten, en als je budget een limiet heeft dan neem je dus niet te dure mensen aan.

Joel Spolsky merkte in zijn blog “Joel on Software” (dat wordt niet meer geupdate sinds Spolsky zijn handen vol heeft aan Stack Overflow) dat het verschil in productiviteit tussen programmeurs een factor 10 kan zijn. Yevgeniy Brikman bevestigt dat. Glass noemt zelfs een factor 28. Je kunt nog verder gaan, en Spolsky doet dat in zijn stukje ook, door het maken van software te zien als een kunst. Je kunt tien schilders een jaar in een atelier zetten, maar dan produceren ze nog geen Picasso. Je kunt tien leerling-timmerlieden bij elkaar zitten, je krijgt geen perfect kozijn. Je kunt tien leerling-programmeurs bij elkaar zetten, je krijgt geen perfecte code. Deze visie strookt met de opvatting dat het maken van software een ambacht is.

Lang geleden heb ik gewerkt met Gerald de Jong. Hij praatte over “beautiful code”, ik vond het een eye-opener. Het is een beetje in de lijn van één van mijn favoriete boeken, Zen and the Art of Motorcycle Maintenance. Dat boek raakt bij mij een snaar omdat ik als kind al gefascineerd was door technische dingen die mooi in elkaar zaten. Een wekker had vroeger allemaal koperen tandwieltjes die prachtig in elkaar pasten. Ik had een doos vol. Tot wanhoop van mijn moeder die regelmatig een nieuwe wekker moest kopen omdat ik, jong als ik was, de klokjes niet weer in elkaar kreeg. Als iets mooi gemaakt is, dan werkt het goed. Als een motor-monteur liefde heeft voor de machine, dan blijft de motor goed rijden. Als software mooi is, dan werkt het goed. Als je in een project werkt met goede programmeurs, en je maakt samen mooie software, dan wordt je gelukkig. Ik stel de schoonheid van de code gelijk aan het geluk van de programmeur. Wat goed uitkomt: een blije programmeur maakt mooie code.

Deze ideeën stroken niet helemaal met de wijze waarop de meeste software projecten worden uitgevoerd. In de software engineering methode, vaak een waterval-aanpak, wordt alles in regeltjes en voorschriften verpakt, wordt alles in kleine stukjes opgedeeld en kan niemand meer z’n talent tot uiting laten komen. In de Scrum aanpak wordt ook alles opgedeeld, het interactie-ontwerp wordt over de schutting gegooid, en de programmeur heeft het maar in code uit te schrijven. Daar wordt de ambachtsman (ambachtsvrouw, kun je dat zeggen?) niet gelukkig van. Eén van de dingen is dat de kwaliteit van de mensen in zo’n struktuur niet meer zichtbaar is. Het maakt voor een manager niet uit welke programmeurs aan het project werken, ze zijn uitwisselbaar, en liefst goedkoop.

Mijn ervaring (en die van McBreen, en van Spolsky, en van Wilson c.s.) is dat een klein team van goede programmeurs in korte tijd een beter systeem bouwt dan een groot team van middelmatige programmeurs. Je ziet dat in open source projecten. Een paar mensen stoppen hun ziel en zaligheid in een project, de library die ze maken wordt door iedereen gebruikt, en wordt tien jaar of langer onderhouden. Kijk naar de diverse Apache Commons libraries. Ieder Java project gebruikt ze. Als je naar de source kijkt, dan zit het prachtig in elkaar. Die libraries worden gemaakt omdat er programmeurs zijn die eer stellen in hun werk, die er voldoening uit halen om mooie code te maken, ook als ze daar niet voor worden betaald.

Mooie code is niet altijd wat je krijgt als je vaste tijdlijnen definiëert. Ik kom bij klanten die sprints van twee of drie weken plannen. In zo’n sprint zitten dan features van een app of een systeem die geen onderlinge relatie hebben maar die toevallig in de prioriteitstelling bij elkaar zijn genomen. Het is lastig om mooie code te maken als je twee weken de tijd hebt om op alle plekken van je code kleine of soms ingrijpende wijzigingen te maken. Het wordt nog lastiger als een “kleine feature” het eigenlijk nodig maakt om de hele architectuur anders te maken, maar dat kan niet want daar krijg je geen tijd voor. Het is alsof ze in een autofabriek in de eerste sprint vier wielen monteren, en in de vijfde sprint te horen krijgen dat de voorwielen moeten kunnen sturen.

In Facts and Fallacies of Sofware Engineering merkt Glass op dat onderhoud van een systeem 40% tot 80% van de totale kosten kan bedragen. Onderhoud kan dan twee dingen zijn: correctief onderhoud, d.w.z het repareren van fouten, en adaptief onderhoud, d.w.z. het toevoegen of wijzigen van functionaliteit. Kwaliteit van software is dus belangrijk: hoe hoger de kwaliteit, hoe minder bugs je hoeft te repareren en hoe makkelijker je functionaliteit dan toevoegen of wijzigen. Als gevolg hiervan vraagt een systeem van goede kwaliteit niet minder onderhoud, eerder meer. Immers, je kunt dan makkelijker en sneller nieuwe en veranderende wensen en eisen van de klant inwilligen.

Moet je als bedrijf dus extra investeren in de kwaliteit van een software systeem, om later makkelijker te kunnen wijzigen? Nee, ik vind van niet, en ik zal zeggen waarom. Software van hoge kwaliteit is niet duurder dan software van lage kwaliteit. Software van hoge kwaliteit is gemaakt door een klein aantal “meester programmeurs”. Software van lage kwaliteit is gemaakt door een groot aantal “leerling programmeurs”, of in het beste geval “gezel programmeurs”. En een klein aantal meesters is goedkoper dan een heel leger leerlingen.

Als een goede programmeur tien keer meer produceert dan een mindere, en bovendien veel betere code produceert, dan zouden de beste programmeurs ook tien keer zoveel moeten verdienen dan de programmeurs aan de onderkant. Helaas is dat niet zo. Dat jaagt mensen weg uit het vak. Toen ik een jaar of dertig was, zat ik aan het eind van de loonschal van programmeur (of engineer, of architect, of welke titel je eraan geeft). Wilde ik meer verdienen, dan moest ik consultant worden (en geen code meer maken), of manager. Dat is nog steeds zo. Bedrijven dwingen goede programmeurs om matige managers of ongemotiveerde adviseurs te worden, vanwege het salaris. Kijk ik naar collega’s van heel vroeger, dan zie ik dat er aardig wat uit de boot zijn gevallen, die aanvankelijk goed carrière maakten als programmeur, vervolgens (project-) manager werden, en daarna hun kennis zagen verouderen totdat ze bij een reorganisatie niet meer nodig waren. Ik ben in die fase ondernemer geworden, terug naar het programmeren, en na het faillissement van mijn bedrijf heb ik het programmeren weer opgepakt, als freelancer. Waarbij ik zie dat dertig jaar programmeerkennis in de freelance-tarieven nauwelijks hoger wordt gewaardeerd dan drie jaar kennis. Waardoor ik dus nu weer advies-opdrachten doe voor het geld en programmeer voor de voldoening.

Software maken is een ambacht, een kunst eigenlijk. Een programmeur maakt code in zijn of haar vrije tijd. Als ik een nieuwe programmeur aanneem, dan is dat altijd waar ik naar vraag: maak je geen software in je vrije tijd, dan is software maken niet je passie, en ik zoek mensen met passie. Toen ik voor het eerst met Martijn werkte, produceerden we vanaf de eerste dag veel code, en vooral mooie code. Sindsdien doen we meer projecten samen, omdat het fijn is te werken met goede mensen. Omdat je gelukkig wordt van het maken van beautiful code.

 

Software Craftmanship, Pete McBreen

Beautiful Code, Oram, Wilson

Hitting the High Notes, Joel on Software

Facts and Fallacies of Software Engineering, Robert L. Glass

Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s