211service.com
Programmeren tot het uiterste
Mansour Raad had een groot probleem. Zijn start-up, DiscoverCast, ontwikkelde software voor het detecteren van botsingen voor de luchtvaartindustrie - fouten in de code kunnen levens kosten. Maar het geld droogde op na een eerste financieringsronde, en het inhuren van extra programmeurs om een bug-proof versie af te werken was uitgesloten.
Daarom heeft Raad een relatief nieuwe codeerdiscipline in het leven geroepen die extreme programmering wordt genoemd. In plaats van alleen aan individuele opdrachten te werken, koppelden programmeurs zich aan elkaar, de een schreef code terwijl de ander toekeek en bekritiseerde, zowel met een kritisch oog als met een uiterst belangrijke back-up. [Mijn vrouw] had een baby, maar het project moest doorgaan, zegt Raad. Omdat ik het aan de andere mensen liet zien, kon iemand in mijn schoenen gaan staan. Door de communicatie haalde het bedrijf de deadlines zonder een toename van fouten.
De meeste programmeurs zijn evenmin tevreden over de softwarekwaliteit als hun klanten. Nu probeert een groeiend aantal manieren te vinden om solide software te maken in een markt die nieuwe producten en verbeteringen verwacht en deze snel wil hebben. Softwarebedrijven wenden zich steeds meer tot ontwikkelingsstrategieën met namen als agile ontwikkeling en extreme programmeer-adrenaline-geladen slogans die goed passen bij het zelfbeeld van programmeurs als ruige helden van het informatietijdperk. In werkelijkheid signaleert de trend - die een lange geschiedenis heeft - een afwijzing van prima donna-programmering ten gunste van teamwerk en samenwerking.
In de software-industrie is code met fouten al lang geaccepteerd als een feit van het leven, zij het een verzwarende en dure ( zie waarom software zo slecht is, KINDEREN juli / augustus 2002 ). Het probleem is dat mensen bij software te veel vertrouwen op hun eigen vindingrijkheid, zegt Michael Stiefel, een consultant die klanten traint in methoden voor softwarebetrouwbaarheid. Ik zou al deze jonge jongens van in de twintig dezelfde fouten zien maken als in de jaren 70 en 80, en ik vraag me af waarom we dit allemaal opnieuw moeten doormaken.
Om fouten te verminderen, prijzen hervormers benaderingen van software-engineering - in de branche bekend als agile ontwikkeling - die teamwerk, samenwerking met eindgebruikers en een flexibele benadering van verandering benadrukken. Om zijn software voor het vermijden van botsingen te bouwen, gebruikte het bedrijf van Raad één type agile ontwikkeling, extreme programmering genaamd, dat de nadruk legt op constant testen en samenwerking.
Als je [een samenwerkingsomgeving] op zijn volle kracht kunt toepassen, zal de kwaliteit van de producten beter zijn, zegt Michele Marchesi, een vooraanstaand pleitbezorger van extreem programmeren en hoogleraar elektrotechniek aan de Universiteit van Cagliari in Italië.
Een van de krachtigste aspecten van agile programmeren is het zogenaamde peer-programmeren, waarbij ontwikkelaars samenwerken en om de beurt code schrijven en de logica ervan aan de ander uitleggen. Paren zijn tijdelijk, worden periodiek gesplitst en verwisseld om nog meer interactie aan te moedigen. Nieuwe ogen onderzoeken elk stukje code, waardoor een proces van continue beoordeling ontstaat.
Twee mensen kunnen ideeën van elkaar afwisselen, zegt Frank Arkell, een chief software engineer bij defensieaannemer General Dynamics Decision Systems, dat al twintig jaar samenwerkingstechnieken gebruikt. Om teams fris te houden, verandert General Dynamics ze voor elk project.
Nog een voordeel van peer-programmeren? Groepsdruk. Niemand wil de persoon zijn die verslapt, dus werken ze allebei harder, zegt Scott W. Ambler, president van Ronin International en een auteur en spreker over agile ontwikkeling.
Op de proef gesteld
Samenwerkingsbenaderingen veranderen ook de manier waarop software wordt getest. Traditioneel is testen een proces in twee stappen geweest. Ten eerste schrijven programmeurs code op basis van vereisten. Vervolgens toetst een aparte groep het resultaat. Maar wanneer software miljoenen regels code bevat, is het proces in twee stappen analoog aan het ontwerpen van een auto op papier, het bouwen ervan en vervolgens controleren of het ontwerp werkte.
Die aanpak werkte gewoon niet voor ontwikkelaars zoals Nicholas Stamos, chief technical officer van Waltham, MA-gebaseerde Phase Forward. Phase Forward ontwikkelt software voor het uitvoeren van farmaceutische klinische proeven, en haar producten moeten voldoen aan de strenge eisen van de Amerikaanse Food and Drug Administration.
Stamos zegt dat Phase Forward aan die eisen voldoet, mede dankzij de nauwe en constante samenwerking tussen de programmeurs van het bedrijf en het kwaliteitsborgingspersoneel. Je kunt het niet over de spiegel gooien en hopen, zegt hij. Kwaliteit moet vanaf dag één worden ingebouwd. Wanneer programmeurs een onderdeel voltooien, controleert het kwaliteitsteam hun werk. Daarna ruilen de teams van plaats voor nog een ronde met bugfixes. Ten slotte wordt de geïntegreerde applicatie getest om problemen met de interactie tussen componenten te vinden. In plaats van de oude aanpak in twee stappen, wordt testen een interactief, doorlopend proces.
Sommige bedrijven proberen een vergelijkbare iteratieve benadering, niet alleen voor het testen, maar ook voor het ontwerpen van code. Cognizant Technology Solutions, een adviesbureau gevestigd in Teaneck, NJ, heeft ontdekt dat bestaande methoden om te beginnen met formele specificaties en vervolgens code te schrijven om hieraan te voldoen, misschien 20 of 30 jaar geleden hebben gewerkt. Maar in een wereld die op het web draait en flexibiliteit nodig heeft, kan formeel stijf zijn.
Toen we probeerden de traditionele processen te gebruiken voor deze nieuwere soorten projecten, raakten de klanten ofwel erg gefrustreerd omdat we hen dwongen het proces te bevriezen, ofwel wilden de projectteams het proces gewoon niet volgen, zegt Cognizant-CEO Kumar Mahadeva. In plaats daarvan gebruiken projecten een reeks prototypes gevolgd door een industrialisatiecyclus, waardoor het bedrijf plotselinge veranderingen van klanten kan verwerken op een manier die minder invloed heeft op de betrouwbaarheid dan het aanpassen van een programma nadat het is voltooid. Toekomstige gebruikers geven een gestage stroom van feedback naarmate de applicatie vorm krijgt.
Maar de ultieme grenzen aan de kwaliteit van software liggen misschien niet in de vaardigheden van de programmeurs of de kracht van het ontwikkelingsproces. Dit is het raadsel waarmee wij en veel fabrikanten tegenwoordig worden geconfronteerd: wat is een acceptabel kwaliteitsniveau? zegt James Hymel, directeur software engineering bij Motorola. Als je concurrenten hebt die leuke, goedkope, maar buggy [producten] blijken te zijn en de klanten zeggen dat dat acceptabel is - dat wil zeggen, ze besteden hun geld aan hen - zou je uitgedaagd worden.
Met methoden als agile ontwikkeling, partnering van ontwikkeling en testen, en de betrokkenheid van eindgebruikers, ondernemen softwareontwikkelaars stappen om hun product te verbeteren. Maar aan het eind van de dag is de grootste beperking voor kwaliteit misschien wel dezelfde die er het hardst om vraagt: de consumenten.