3 november 2020
Over de ethiek van programmeren
Computers zijn niet meer weg te denken uit ons professionele en private leven. Zonder er bij stil te staan klikken, scrollen en swipen we maar door. Als er al eens softwarematige problemen optreden, halen de meesten hun schouders op, schrijven we misschien een gefrustreerde recensie of denken we 'dat is weer typisch IT' ... Over dat laatste wil ik het hier hebben. We staan te weinig stil bij wat softwareontwikkeling betekent, en wat de consequenties zijn indien alles niet verloopt zoals het hoort. En die consequenties zijn er wel degelijk: inefficiënties, vastgeroeste processen, frustraties, fraude, verkeerd gebruik tot het verlies van vertrouwen in de software-industrie en het verwachtingspatroon dat zich daarbij ontwikkelt.
_Softwareontwikkeling is geen doel op zich, het is een middel
De software-industrie is nog vrij jong, minder dan honderd jaar oud. De naam Alan Turing klinkt bij velen allicht bekend in de oren. Zijn essay uit 1935 'Computable numbers with an application to the Entscheidungsproblem (decision problem)' was de eerste publicatie die leidde tot de studie van onder andere software engineering (een term die ik overigens liever niet hoor, omdat programmeurs over het algemeen geen ingenieurs zijn). Ergens begin de jaren 1950 ontwikkelde software zich buiten het louter academische. Een mooi voorbeeld van een stap in professionalisering was wanneer Margaret Hamilton zich midden jaren 1960 boog over de ontwikkeling van de software die de Apollo-missie stuurde. Haar manier van denken over software, het doelpubliek ervan, en onze interacties ermee kan ons ook vandaag nog veel leren over hoe we software moeten ontwikkelen.
Hamiltons mechanismes en denkprocessen leidden ertoe dat de missies veilig verliepen, net omdat ze verder nagedacht had over hoe de eindgebruikers, astronauten en ingenieurs op de grond, zouden interageren met hun besturingssysteem (wat toen letterlijk een paneel was met knoppen en cijfertjes). Kort door de bocht bedacht ze een systeem dat zelf kon denken, en dus waarschuwen, wanneer het meer moest doen dan het aankon. Ze dacht verder na dan enkel de programmeertaal, hoe het zou verlopen in ideale omstandigheden, maar voorzag eventuele nieuwe gevaren die konden opdoemen. Ze dacht na over de volwaardige missie, het einddoel waar de software voor zou dienen. Ze kreeg voor haar werk de NASA Space Act Award, voor de innovaties in de fundamenten van betrouwbare softwareontwikkeling. Wat mij betreft had ze ook een prijs mogen ontvangen om zo hard te vechten en na te denken over de gebruikerservaring, de interacties en het leggen van de fundamenten tot hoe en waarom software geschreven wordt.
_Softwareontwikkeling gaat niet over machines, maar over mensen
Softwareontwikkeling en automatisatie wordt vandaag bijna gezien als het standaardantwoord op een probleemstelling binnen een organisatie of bedrijfsproces. Zonder verpinken denken we al snel in Excel-werkbladen, Dropbox-accounts, Access-databanken en tal van andere software om deeltjes van ons professioneel en privéleven te automatiseren. De vragen die Margaret Hamilton destijds impliciet stelde, zijn verloren geraakt: moet ik hier automatiseren, voor welk publiek schrijf ik de software en welke problemen brengen mijn software met zich mee. Die vragen zijn niettemin essentieel ook om tot goed werkbare software te komen. Later zijn ze opgenomen in het Agile manifest, samen met enkele andere belangrijke concepten die u zelf kunt nalezen.
In essentie draait het er altijd om dat een geautomatiseerde oplossing niet tot meer werk mag leiden voor de eindgebruiker dan het originele bedrijfsproces. Om die doelstelling te kunnen bereiken is het belangrijk om eerst en vooral de mensen te leren kennen die het bedrijfsproces uitvoeren. Je moet hen begrijpen, met hen in dialoog gaan en de praktische problemen waar men tegen aanloopt goed in kaart brengen. Zo ga je mee in hun denkwereld; zo stap je mee in hun taken en al snel blijkt dat het empathische, het inlevingsvermogen, groot moet zijn voor een programmeur. Hij of zij moet het publiek leren kennen dat de oplossing gaat gebruiken. Het antwoord is dan ook niet altijd software alleen, maar vaak een combinatie tot een nieuw inzicht hoe men kan werken, samen met de experten die het werk al jaren uitvoeren. De taak van softwareontwikkeling ligt dus ook niet enkel bij de programmeurs, maar bij eenieder die betrokken is in dat bedrijfsproces.
Een belangrijk punt binnen deze jonge industrie is terugkeren naar dit verleden en het erkennen van de missie die een bedrijfsproces heeft, of zelfs breder het bedrijf en haar plaats in de maatschappij. Wanneer we als programmeurs software schrijven, is het belangrijk beide partijen niet te isoleren tijdens de softwareontwikkeling. Geen enkele organisatie is dezelfde, en geen persoon heeft hetzelfde denkproces. We moeten met elkaar praten, in dialoog gaan, en elkaar begrijpen om een softwareoplossing te ontwikkeling die op maat is, die gedragen is door de gebruikers. Ze bouwen dus zelf mee aan die oplossing door hun manier van werken, cultuur en andere factoren te delen. Dit vertaalt zich in een hertekening van het proces, de schermen, de samenwerkingen, en meer ...
_Software schrijven is als een verhaal vertellen
Als we strict kijken naar de achterliggende code zelf, is dat ook een interessante en vaak vergeten vraag. Softwarecode is vaak onderhevig aan verandering van processen. Dit impliceert dat code via bepaalde patronen geschreven wordt. We moeten hierbij ook denken aan hoe we deze code schrijven. Een stuk softwarecode moet een verhaal vertellen, zodat wanneer het gelezen wordt door iemand, die een aanpassing of correctie moet brengen in het verhaal, het eerst en vooral makkelijk kan begrijpen.
Hoe leesbaarder de code is (naamgeving, structuren, geautomatiseerde tests die als documentatie dienen en logische opbouw in deelproblemen) hoe leesbaarder het verhaal is. Eén van de kenmerken van goed onderhoudbare software is de leesbaarheid, de snelheid waarmee iemand anders kan afleiden hoe het bedrijfsproces eruit ziet. We schrijven de code dus niet voor de volgende keer dat de computer die zal uitvoeren, maar voor de volgende keer dat iemand ze moet lezen.
_Waar loopt het dan mis?
De corona-app (Coronalert) in België werd uiteindelijk geïntroduceerd, maar we zien al snel dat het uitrollen ervan niet perfect verloopt. Op iPhone draait de app slechts op iOS 13.6 of hoger. Het marktsegment van lagere versies is evenwel nog steeds relevant (niet iedereen doet een update, of koopt een nieuwe toestel). Ook op Android zien we dat de verschillen in versieondersteuning niet het volledige marktsegment bedienen. Verder is om meerdere redenen geopteerd om voor bluetooth te kiezen, maar dit maakt de app erg gebruiksonvriendelijk. Bluetooth slorpt je batterij leeg waardoor mensen de functie zullen afzetten en de app dus geen meerwaarde biedt ... Beide lijken op het eerste gezicht perfect verdedigbaar, maar als we kijken naar de missie van de applicatie (de contacttraceringwaarde) hebben ze onvoldoende rekening gehouden met bepaalde factoren, waaronder in eerste instantie de gebruikers kennen en hoe ze omgaan met de technologie.
Een ander stuk software dat gebouwd is in coronatijden is de contacttraceringsoftware, gebruikt in de callcenters. Met botste op de privacywetgeving, maar ook de snelheid van de implementatie bleek problematisch. Eén van de kinderziektes was dat men niet meer dan x-aantal personen kon ingeven waarmee de besmette persoon contact had. Dat getal x was gebaseerd op de richtlijn van de federale overheid, want 'meer mocht niet' ... Zulke essentiële fouten zijn snel gemaakt, maar zorgen ervoor dat een heel proces in het water valt. Er is duidelijk niet verder gedacht door het team van mensen; de visie van Margaret Hamilton om ruimer te denken en te kijken in welke context we leven en mensen dit zullen gebruiken, werd niet gehanteerd. Er was nog meer mis met de contacttraceringapp, maar het lijkt me dat dit voorbeeld voldoende aantoont dat er geen grondige analyse gebeurd is vooraf.
Dit zijn slechts enkele recente en heel publieke voorbeelden. De gemaakte fouten lijken banaal, maar tonen aan dat met de lessen van Hamilton en de principes van het Agile manifest geen rekening gehouden werd. Dit heeft tot gevolg dat de software an sich geen verbetering was in ons leven of in de maatschappij, maar frustraties bracht en louter verspilling was van tijd, geld en een potentiële tweede kans tot slagen: we weten allemaal hoe belangrijk een eerste indruk is.
_Professionalisering
Ik kan nog tal van voorbeelden geven, ik vermoed dat u in uw eigen context zelf ook zulke zaken tegenkomt. Software is niet louter de job van een programmeur, we moeten met zijn allen kritisch kijken naar het proces en meedenken over hoe software kan dienen, en met welke kwaliteitsnormen ze onderhouden moet worden.
Momenteel zien we dat software vaak faalt wegens beperkte tijd, budget, slechte communicatie, geen reviews en geen testing, zie bijvoorbeeld hier.
Het relaas hierboven toont aan dat er reeds voldoende kennis is opgebouwd door de jaren heen hoe je software moet bouwen; al sinds de conceptie van de industrie zelf. Daaruit blijkt dat kritisch en ruim denken gecombineerd met een sterk empathisch vermogen essentieel zijn in de ontwikkeling van software. Tot slot mogen programmeurs, eindgebruikers en het bedrijf waarin ze ingebed worden, niet als eiland naast elkaar drijven, maar moeten ze in harmonie samenwerken en in dialoog blijven: voor, tijdens en na het schrijven van de code.
_Enkele referenties
- https://www.vrt.be/vrtnws/nl/2020/09/30/corona-app-doet-veel-vragen-rijzen/
- https://www.hln.be/ihln/coronalert-doet-het-niet-op-smartphone-ouder-dan-5-jaar~ad627c0c/
- https://gs.statcounter.com/ios-version-market-share/mobile-tablet/belgium
- https://www.nieuwsblad.be/cnt/dmf20200714_97502602
- https://www.bruzz.be/samenleving/contact-tracing-brussel-weinig-patienten-weinig-telefoons-2020-06-01