Waarom dagdromen we wel van de nieuwste testosteron-Lamborghini en nooit van een nieuwe Twingo-zonder-turbo? Kennelijk is de eerste leuker of beter. Terwijl beide toch voldoen aan alle eisen die worden gesteld aan een auto. Dit dromen heeft meer te maken met voorkeuren dan met eisen. Ook voor software geldt zoiets. Zo kan opensource altijd beter zijn, of juist niet. Al is het subjectief, schijnbaar is er een maatlat die aangeeft wat beter is. Omdat ik software altijd wil verbeteren, is dat een interessant fenomeen.
In software geldt zo‘n informele ’dit-is-beter-maatlat‘ niet alleen voor producten. Ook voor ontwikkelmanieren gelden sterke voorkeuren. Zo is Agile moderner en klaarblijkelijk daardoor beter. En al jaren geldt dat automatisch testen altijd beter is. Beter dan wat, vraag ik me dan af. De opdrachtgever is vaak duidelijk: het moet sneller en goedkoper, dan is het beter. Mijn vraag is opnieuw: hoe? Hoe maken we software beter, zowel het product als de manier?
Er wordt veel geschreven over Scrum en andere managementmethodieken. Die helpen, vooral om het ontwikkelproces efficiënter te managen. Ze zeggen echter weinig over het hoe. Met de invoering van Scrum lijkt de klassieke aanpak – analyse, design, coderen, testen – verouderd te zijn. Veel (beginnende) ontwikkelaars vragen zich daarom af hoe ze voor kwaliteit zorgen. Voor een ervaren, professionele topontwikkelaar speelt dat minder. Hij doet eerst een beetje van dit, dan een beetje zus en daarna komt er automatisch goede code. Maar omdat ik allergisch ben voor het woord ’automatisch‘ zoek ik verder. Ook omdat die automaat niet werkt voor aanstormend talent.
This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one for just €20 for the first year and enjoy all the benefits.