Ontwikkelaars, architecten én testers van software moeten meer als team optrekken, vindt James Whittaker, software architect bij Microsoft. Hij heeft die teamgeest sterk aangezet in Visual Studio Team System 2010. Het doel is betere software te (laten) creëren, hoewel bugs volgens Whittaker onuitroeibaar blijken.
James Whittaker was in Nederland om tijdens de Eurostar-conferentie een keynote te verzorgen. Het was voor Computable dè gelegenheid om met hem van gedachten te wisselen over softwareproductie en -kwaliteit.
Waarom verliet u drie jaar geleden de comfortabele positie van professor om bij Microsoft te gaan werken?
"Ik heb tien jaar gewerkt aan het Florida Institute of Technology. Daar heb ik me vooral beziggehouden met methoden om het testen van software te verbeteren. Voor Microsoft deed ik – samen met studenten – al veel consultingopdrachten op het vlak van beveiliging en testen. Als er een plek is om mijn ideeën zinvol in praktijk te brengen, dan is het wel bij Microsoft."
"Visual Studio is waarschijnlijk het enige product in de wereld dat kan helpen betere software te maken. Wij bieden het gereedschap dat de meeste mensen gebruiken om software te schrijven. Als je bugs wilt voorkomen, dan moet je juist daar wezen waar ze worden gecreëerd."
U verwierf bekendheid met boeken als ‘How to Break Software' en ‘How to Break Web Software'. Heeft u nu voor Microsoft de handleiding ‘How to Write Unbreakable Software' geschreven?
Lachend: "Eigenlijk heb ik dat boek ooit geschreven, maar ik kon er geen uitgever voor vinden. Software kraken is trouwens veel makkelijker dan onbreekbare software schrijven."
Wat komt er bij kijken om betrouwbare programmatuur te schrijven?
"Ik wou dat ik dat wist. Natuurlijk kunnen we beter materiaal afleveren dan we nu doen, maar perfecte software; dat zit er niet in. Mensen maken helemaal niets dat perfect is. Er storten nog steeds gebouwen in, noem maar op. Software bestaat ook nog maar zo kort. Pas de laatste twintig jaar hebben we genoeg data in het leven geroepen om patronen te kunnen herkennen. Je zult zien dat de onderdelen die we in Visual Studio bouwen, gericht zijn op die historische onvolkomenheden."
Welke onvolkomenheden pakt Visual Studio Team System 2010 aan?
"Er zijn twee patronen: eentje van de programmatuur zelf; zeg maar: de bugs. En een patroon in de manier waarop software tot stand komt. Het spreekt vanzelf dat wij met Visual Studio ons op het proces richten. Zo hebben we geleerd dat de watervalmethode niet erg efficiënt is om software te schrijven. Wij gebruiken zelf Agile als methodiek."
"Waar wij echt veel aandacht aan hebben besteed, is de oplossing van het ontwikkelaar-tester-pingpong effect, waarbij een tester een fout ontdekt en het programma terugstuurt naar de ontwikkelaar met het bug-rapport. De ontwikkelaar is vervolgens niet in staat om de fout te reproduceren, omdat hij toch in een andere omgeving werkt en op een andere machine, waarna hij de code weer terugstuurt naar de tester zonder er iets aan te hebben gewijzigd. Dit kan zo wel een paar keer heen en weer gaan."
"Dat pingpong-effect maken we ongedaan door in Visual Studio de mogelijkheid in te bouwen de omgeving van de tester als virtuele machine in de vorm van een bestand naar de ontwikkelaar te sturen. Die kan dus werken in precies dezelfde omgeving als de tester werkt. Dat versnelt het productieproces en – misschien belangrijker nog – verhoogt het werkplezier van de betrokkenen, want een ontwikkelaar wil creatief zijn, wil zijn tijd niet besteden aan het zoeken naar bugs. Terwijl de tester met zijn handen wil werken, testcases wil bedenken en uitproberen; ook hij wil zich niet bezighouden met het reproduceren van bugs. Dit is ons lab management product. Wij zijn de eersten die deze mogelijkheid voor het gehele proces van softwareproductie toepassen; voor architecten, ontwikkelaars en testers. Teamwerk is ons uitgangspunt, evenals application lifecycle management."
Microsoft staat vaak in een kwaad daglicht als het om bugs gaat. Hoe geloofwaardig zijn de inspanningen van het Visual Studio team?
"Ik ben de laatste om te zeggen dat Microsoft geen fouten maakt. Sterker nog, in mijn blog ‘If Microsoft is so good at testing, why does your software suck?' ga ik hier vrij open op in. Punt is dat Microsoft platformsoftware maakt, waarop applicaties van andere ontwikkelaars draaien. Vaak wordt naar het besturingssysteem gewezen, terwijl het aan de applicatie ligt. Dat laat onverlet dat er nog genoeg te verbeteren valt bij Microsoft. Dat geef ik in alle openheid weer, hetgeen door mijn collega's wordt gewaardeerd. Er is hier de bereidheid om van fouten te leren."
In hoeverre heeft de ontwikkeling van Software as a Service effect op het testwerk?
"Dat is nog moeilijk aan te geven. Zeker is wel dat er een effect is, maar we zijn daar nog niet helemaal uit. Microsoft heeft een studiegroep gevormd die zich over dit probleem buigt. Want de vraag is natuurlijk wie verantwoordelijk is voor de software die in de cloud zit en iemand als service gebruikt om zelf een applicatie te maken. Hoe test je dat? En hoe zorg je er eventueel voor dat de resultaten van die test worden opgevolgd, zodat een bug eruit wordt gehaald? We zijn druk doende antwoorden te formuleren."
En nu maar hopen dat de levensduur van Visual Studio 2010 langer is dan de leercurve van dat product.
Op dit moment zie ik meer en meer programmeurs die applicaties in elkaar zetten door wat code bijelkaar te googelen omdat ze met geen mogelijkheid zelf de benodigde kennis kunnen bijhouden. Daarbij speelt ook dat M$ het documenteren niet serieus neemt en het vooral overlaat aan forums en gebruikers om elkaar wat te helpen.