Creating ethical software, Part 2

Have you read the previous blog yet?: Creating ethical software, Part 1

Alex wacht geduldig terwijl het team elkaar nerveus aankijkt. Vooral de Product Owner wordt veelvuldig aangestaard. Nadat Alex het Public API-team had overtuigd om ingrijpende veranderingen door te voeren in zowel hun codebase als hun werkprocessen, bezoekt Alex nu ook de andere softwareteams binnen Etrain om hen te vragen hetzelfde te overwegen. Een hernieuwde focus op beveiliging, privacy en compliance, vanuit een bottom-up benadering, zal niet alleen de kwaliteit van de software verbeteren, maar ook bijdragen aan een professionelere en inspirerende werkomgeving. Althans, dat is wat Alex steeds opnieuw benadrukt.

Na nog een uur vol ongemakkelijke stiltes en scherpe woorden gaat het team uiteindelijk akkoord met Alex’ voorstellen. Alex vertrekt, maar voelt zich niet voldaan. In plaats daarvan overheerst een gevoel van onrust.

“Eerlijk gezegd,” bekent Alex aan Kim, de vertrouwenspersoon bij Etrain, “het werken in meerdere teams de afgelopen maanden, en nu deze nieuwe verantwoordelijkheid op me nemen, het proberen om een heel bedrijf te overtuigen om te veranderen… het is veel geweest. Misschien ben ik te ver gegaan. Misschien neem ik dit allemaal te persoonlijk en te serieus. Misschien voer ik een kruistocht, terwijl ik me gewoon op mijn werk als engineer zou moeten richten.”

Kim knikt. “Dat zou kunnen. Maar misschien doe je wel het juiste, alleen probeer je te veel tegelijk te doen. Mijn advies is om je kruistocht even uit te stellen en een week of twee verlof te nemen. Als je terugkomt, weet je vanzelf hoe je je erbij voelt.”

“Maar als ik weg ben, kunnen de teams waar ik deel van uitmaak niet goed functioneren!” werpt Alex bezorgd tegen.

Kim schudt haar hoofd. “Als dat echt zo is, is het des te belangrijker dat je verlof neemt. Neem mijn advies alsjeblieft ter harte. En als het nodig is, bespreek ik het met je verschillende managers.”

Harde en zachte ethiek

De vorige keer bespraken we wat je de harde kanten van ethische softwareontwikkeling zou kunnen noemen. Simpel gezegd, de praktische aspecten. Veilige, legale software die rekening houdt met privacy en standaarden is altijd te verkiezen boven software die dat niet doet. Als je je argumenten goed formuleert, zal zelfs de klant waarvoor je ontwikkelt erkennen dat dat betere software oplevert. Maar nu ga ik in op onderwerpen waarover minder snel overeenstemming bestaat. De zachte kanten. De onderwerpen waarbij zelfs redelijke managers het niet altijd met mij eens zullen zijn. In dit deel bespreek ik mijn persoonlijke visie op wat nodig is om softwareontwikkeling echt ethisch te maken.

Het is vrijwel onmogelijk om over ethische softwareontwikkeling te praten zonder elementen van filosofie, politiek en moraliteit erbij te betrekken. Toch zal ik proberen dat onmogelijke te doen in de komende alinea’s. Bereid je dus voor op een aantal pittige uitspraken.

We gaan een aantal ethische overwegingen verkennen die, naar mijn mening, elke softwareontwikkelaar zou moeten omarmen bij het bouwen van applicaties. Als software engineer heb je verantwoordelijkheden tegenover je gebruikers, je collega-ontwikkelaars en zelfs tegenover de mensheid als geheel. We zullen het hebben over verslavend ontwerp, inclusiviteit en vooringenomenheid, transparantie, overdraagbaarheid, culturele impact en tot slot milieu-impact. Dat zijn veel onderwerpen, dus laten we beginnen.

Je verantwoordelijkheid tegenover je gebruikers

Ik streef ernaar om applicaties te maken die gebruikers graag gebruiken. Gebruiksvriendelijkheid is het kenmerk van goed UX-design en we hebben dat onderwerp eerder besproken. Maar er is ook een keerzijde: soms slaan we daarin door en maken we apps waar mensen geobsedeerd door raken. Daar komt ethiek om de hoek kijken, vooral in de wereld van digitale platforms zoals sociale media. Ik noem dat verslavend ontwerp. Verslaving is altijd een negatief effect, zelfs als het het bedrijf geld oplevert.

Het is niet controversieel om te stellen dat er risico’s kleven aan bedrijven die profiteren van verslavend ontwerp. Apps die proberen woede, verwarring, angst of zelfs depressie bij gebruikers op te wekken om betrokkenheid te vergroten, zijn schadelijk. Als ontwikkelaars moeten we ons afvragen: maken we een product dat geliefd is, of bouwen we software die levens ondermijnt? Softwareontwikkelaars zouden zichzelf regelmatig de volgende vragen moeten stellen:

Wie profiteert van mijn software?
Hoe profiteren ze? Geef ik mensen nieuwe mogelijkheden of slechts een klein duwtje?
In welke mate profiteren ze? Verander ik levens of voeg ik slechts een beetje gemak toe?
Heb ik maatregelen ingebouwd om het welzijn van gebruikers te beschermen?
Hoe transparant zijn onze verdienmodellen en dataverzamelingspraktijken, inclusief het gebruik van AI en machine learning?

Bedrijven zoals Netflix en Nintendo proberen rekening te houden met sommige van deze overwegingen. Netflix heeft de bekende melding “Kijk je nog?” en Nintendo toont regelmatig de pop-up “Neem even een pauze”. Toch vind ik dat niet genoeg. We hebben meer nodig dan dat.

Laten we het hebben over gebruiksbeperkingen, maatregelen om verslaving te voorkomen. Aan de ene kant is er de consistente coach die gebruikers motiveert om doelen te behalen en hen helpt succes te boeken. Denk aan een persoonlijke trainer die weet wanneer het genoeg is. Aan de andere kant is er de verleidelijke verleider die een eindeloze stroom boeiende inhoud aanbiedt. Een buffet waar je niet vanaf kunt blijven.

Transparantie is cruciaal. Gebruikers moeten begrijpen wat er achter de schermen gebeurt. Daarom is hier een concreet actieplan voor wanneer je verslavend ontwerp in je app ontdekt:

Evalueer de voordelen. Onderzoek wie er baat heeft bij je app en op welke manier. Streef naar een gezonde balans tussen betrokkenheid en onafhankelijkheid.
Stel redelijke grenzen. Implementeer gebruiksbeperkingen die welzijn bevorderen. Stimuleer gezond gebruik in plaats van afhankelijkheid.
Wees transparant. Communiceer duidelijk over verdienmodellen en dataverzameling. Laat gebruikers zien wat er gebeurt.
Blijf verbeteren. Evalueer en optimaliseer voortdurend het ontwerp van je app. Streef naar een ervaring die gebruikers waarderen, zonder hun welzijn uit het oog te verliezen.

Een ander belangrijk ethisch probleem dat we bij gebruikers tegenkomen, is vooringenomenheid. Het is als een onzichtbaar virus dat zich in onze systemen kan nestelen als we niet opletten. Computers hebben zelf geen moreel kompas; ze leren enkel van de data en training die wij aanbieden. Daarom is het onze taak als ontwikkelaars en datawetenschappers om vooringenomenheid uit zowel de trainingsdata als de algoritmes te verwijderen.

Vooringenomenheid in softwaresystemen kan systemische ongelijkheid in stand houden en leiden tot nadelige gevolgen voor bepaalde groepen mensen. Het is een verlies voor iedereen: gemiste kansen, slechtere zorg of zelfs vervreemding. Een gebrek aan inclusiviteit zorgt ervoor dat gebruikers zich buitengesloten voelen en je applicatie uiteindelijk de rug toekeren. In zekere zin is dat het tegenovergestelde van verslavend ontwerp.

Neem kunstmatige intelligentie als voorbeeld. Microsoft en Google benadrukken beiden in hun richtlijnen voor Responsible AI Guidelines dat inclusiviteit en het voorkomen van bias essentiële ontwerpdoelen zijn. Vooringenomenheid is als asynchrone programmering: het verspreidt zich als een olievlek. Om dit te bestrijden, moet je bewust en kritisch te werk gaan. Stel vragen over de vastgestelde eisen, over hoe data is verzameld en welke aannames eraan ten grondslag liggen. Als je niet weet onder welke omstandigheden je software is ontwikkeld, kun je onbedoeld bestaande vooroordelen versterken.

Het bestrijden van bias en het centraal stellen van inclusiviteit in software is niet alleen een nobel streven, maar een ethische noodzaak. Een goede software engineer neemt deze verantwoordelijkheid serieus en zorgt ervoor dat zijn software eerlijk en toegankelijk is voor alle gebruikers, ongeacht hun achtergrond. Dat ben je je gebruikers verplicht.

Je verantwoordelijkheid tegenover andere programmeurs

Wat is een betere manier om je collega-programmeurs te helpen dan door hen jou te laten helpen? Open-source software is software die wordt uitgebracht met een licentie die gebruikers toestaat om de broncode vrij te bekijken, aan te passen en te verspreiden. Het wordt gekenmerkt door zijn transparantie en samenwerkingsgerichte aard, omdat de broncode open beschikbaar is voor iedereen die wil bijdragen of leren. Dit staat in contrast met propriëtaire software, waarvan de broncode gesloten blijft en enkel in handen is van de makers.

Open source moedigt samenwerking binnen de gemeenschap aan, waardoor ontwikkelaars van over de hele wereld samen kunnen werken, verbeteren en de software kunnen aanpassen aan hun specifieke behoeften. Deze gezamenlijke inspanning leidt vaak tot snelle innovatie, verbeterde beveiliging en grotere stabiliteit van software. En dat geldt niet alleen voor jouw project, maar voor de hele softwarewereld. Het is als een collectieve geest.

Toch brengt de open aard van code ook uitdagingen met zich mee waar softwareontwikkelaars zorgvuldig mee moeten omgaan. Een van die uitdagingen is het waarborgen van de veiligheid en integriteit van open-sourcecomponenten. Hoewel de open gemeenschap kan leiden tot snelle bugfixes en verbeteringen, stelt het de code ook bloot aan misbruik en beveiligingsrisico’s. Ontwikkelaars moeten daarom zorgvuldig kiezen welke componenten ze gebruiken, ze regelmatig bijwerken en zelf bijdragen aan de gemeenschap om een gezond ecosysteem te behouden.

Een tweede uitdaging is het evenwicht tussen samenwerking en concurrentie. Dat collectieve brein klinkt mooi, maar in de praktijk werkt de samenleving niet zo. Concurrentie is onderdeel van het systeem. Open-sourceprojecten kunnen concurrenten de mogelijkheid geven om je code te bestuderen en te kopiëren. Denk bijvoorbeeld aan Twitter, dat een deel van zijn code openstelde, waarna er al snel nieuwe concurrenten opdoken.

Daarnaast kan open source leiden tot licentiecomplexiteit. Ontwikkelaars moeten zich bewust zijn van de verschillende open-sourcelicenties, hun voorwaarden en hoe die invloed hebben op het gebruik en de verspreiding van hun software. Door open-source best practices te volgen, zoals correcte bronvermelding en naleving van licentievoorwaarden, kun je zowel juridische als ethische integriteit behouden.

Een andere belangrijke verantwoordelijkheid die je hebt tegenover andere ontwikkelaars is transparantie. Transparantie is een fundamenteel principe dat het werk van softwareontwikkelaars zou moeten sturen. Wanneer we praten over transparantie richting gebruikers, gaat het meestal over privacy en naleving van wetgeving. Maar tegenover andere programmeurs betekent transparantie iets anders: het gaat erom dat je software inzicht biedt in de ontwerpkeuzes en technische beslissingen die zijn genomen tijdens de ontwikkeling. Zonder die kennis wordt het voor nieuwe ontwikkelaars onmogelijk om echt eigenaarschap over de software te nemen. En verantwoordelijkheid is, zoals inmiddels duidelijk mag zijn, essentieel voor ethische softwareontwikkeling.

Een concept dat nauw verbonden is met transparantie, is overdraagbaarheid. Dit verwijst naar de mogelijkheid voor andere ontwikkelaars om jouw software te blijven onderhouden of uitbreiden als jij er niet meer bent. Als consultant kom ik dit vaak tegen, maar eigenlijk geldt het voor iedereen die ooit van baan verandert, met pensioen gaat of simpelweg niet onvervangbaar wil zijn. In de praktijk verhoog je de overdraagbaarheid door... jawel, alle eerdere aanbevelingen te volgen: schrijf testbare code, schrijf met duidelijke intentie, schrijf tests, en documenteer. Door je code begrijpelijk en onderhoudbaar te maken, stel je andere ontwikkelaars in staat het project naadloos voort te zetten.

Gebruik daarnaast gevestigde frameworks, bibliotheken en open-sourcetechnologieën. Door te werken met breed ondersteunde tools verklein je het risico op afhankelijkheid van verouderde of gesloten systemen die in de toekomst moeilijk overdraagbaar zijn. Open source draagt juist bij aan die overdraagbaarheid, omdat de gemeenschap kan bijdragen aan de levensduur van de software.

Tot slot is het belangrijk om binnen je team of organisatie een cultuur van samenwerking en kennisdeling te stimuleren. Moedig code reviews, pair programming en het delen van kennis aan. Door een cultuur van collectief eigenaarschap en gedeeld begrip te bevorderen, creëer je een omgeving waarin kennis verspreid wordt en vaardigheden overdraagbaar blijven.

Je verantwoordelijkheid tegenover de mensheid

En nu komen we aan bij het meest “Sesame Street”-achtige gedeelte van deze blog. De wereld verbeteren, iets doen voor de kinderen, een betere toekomst begint bij jezelf, al dat soort dingen. Voordat ik verder ga, wil ik je een beeld schetsen van een extreem idealistisch bedrijf en hoe dat bedrijf softwareontwikkeling zou aanpakken.

Bij veel bedrijven wordt het succes van een ontwikkelteam uitsluitend gemeten aan de hand van de snelheid waarmee nieuwe features worden uitgebracht. Ethische overwegingen raken daarbij snel ondergesneeuwd. Butterfly Inc. daarentegen beschouwt het als haar plicht om de norm te zetten voor ethische standaarden in software. Ethische prioriteiten zijn geïntegreerd in elke fase van de softwarelevenscyclus, van ontwerp tot operatie.

Het trainen van personeel in ethische besluitvorming is essentieel. Dat betekent dat ontwikkelaars, architecten, testers en andere teamleden worden onderwezen in databeheer dat voldoet aan regelgeving en aan de verwachtingen van gebruikers. Ontwikkelaars zijn zich vaak niet bewust van de nieuwste wetgeving in de regio’s waar hun software wordt gebruikt. Het is de verantwoordelijkheid van het bedrijf om te zorgen dat ze die kennis wel hebben.

Om ethische misstappen te voorkomen, is samenwerking tussen technische leiding en juridische teams cruciaal. Bedrijven moeten bijvoorbeeld prioriteit geven aan het correct beheren van persoonlijke gegevens van gebruikers. Het implementeren van toegangscontrole en logging tijdens de ontwikkelfase is essentieel. Vaak zien ontwikkelaars zulke beveiligingsmaatregelen als het domein van een ander team, maar in werkelijkheid moeten ze vanaf het begin onderdeel zijn van het ontwerp.

Een ethisch bedrijf begrijpt dat zijn software een diepgaande culturele impact heeft. Software beïnvloedt hoe mensen communiceren, informatie verkrijgen en omgaan met de wereld. Daarom moet software respect tonen voor verschillende culturen, talen en perspectieven. Overmatige automatisering kan bedrijven ontwrichten, soms onbedoeld. Een verantwoordelijk bedrijf neemt volledige verantwoordelijkheid voor alle softwarebeslissingen, zelfs als dat ten koste gaat van winst. Daarom vragen ze hun ontwikkelaars om bewust stil te staan bij de gevolgen van hun werk en elk nieuw featureverzoek te beginnen met reflectie.

Klinkt dat overdreven idealistisch? Natuurlijk. Geen enkel bedrijf zou zo denken, toch? Helaas, als zij het niet doen, denk ik dat wij het moeten doen.

Softwareontwikkelaars behoren tot de weinigen die enigszins kunnen voorspellen wat de maatschappelijke gevolgen van hun software zullen zijn. Ik zeg niet dat jij degene moet zijn die aangeklaagd wordt als er iets misgaat, maar ik zeg wel dat jij in een unieke positie bent om ethische problemen aan te kaarten voordat ze de ontwerpfase verlaten.

Tot slot moeten we nog een ander effect bespreken: de impact op het milieu. Softwareontwikkelaars hebben de verantwoordelijkheid om rekening te houden met de ecologische voetafdruk van de applicaties die ze bouwen. Van energieverbruik tot elektronisch afval, digitale producten hebben een aanzienlijke milieu-impact.

Het toepassen van LEAN-principes in softwareontwikkeling kan verspilling verminderen en de ecologische impact verkleinen. Het LEAN-concept, ontwikkeld door Toyota, richt zich op het maximaliseren van waarde en het elimineren van onnodige stappen. Door deze aanpak worden ontwikkelcycli korter, het verbruik van middelen lager en verspilling geminimaliseerd. LEAN helpt ontwikkelaars om efficiënter te werken en bij te dragen aan een duurzamere softwarewereld. Zoals Toyota het zou zeggen: LEAN is als elektrisch rijden in plaats van diesel.

Ook je codekeuzes hebben invloed op het milieu. Door code te optimaliseren voor prestaties en energie-efficiëntie kun je de milieu-impact aanzienlijk verkleinen. Dat betekent minder onnodige berekeningen, efficiënter databeheer en het toepassen van energiezuinige ontwerppatronen. Daarnaast kun je met cloudinfrastructuur de benodigde rekenkracht flexibel schalen, waardoor je middelen beter benut en energieverspilling voorkomt. Zie het als alleen de auto nemen wanneer fietsen geen optie is.

Cloud computing speelt hierbij een sleutelrol. Grote cloudproviders kunnen door schaalvoordelen energie-efficiënter werken en minder CO₂ uitstoten dan traditionele servers op locatie. Door applicaties naar de cloud te verplaatsen, profiteren ontwikkelaars van datacenters die speciaal ontworpen zijn om duurzaam te opereren. De elasticiteit van de cloud zorgt bovendien voor een beter gebruik van resources, waardoor minder verspilling ontstaat.

Daarnaast maakt de cloud virtualisatie en serverconsolidatie mogelijk, wat leidt tot efficiënter gebruik van hardware. Door cloudgebaseerde platforms te gebruiken, kunnen ontwikkelaars dynamisch resources toewijzen, energie besparen en prestaties verbeteren.

Om de vergelijking voort te zetten: cloud computing is als autodelen. Er is geen reden om een auto de hele tijd stil te laten staan als je die maar af en toe nodig hebt.

Het mooie is dat milieuvriendelijke keuzes binnen softwareontwikkeling meestal ook financieel voordeliger zijn op de lange termijn. Dus of je nu de planeet wilt redden of gewoon geld wilt besparen, een goede software engineer houdt altijd rekening met de impact op het milieu.

Strijd der wetenschappers

Ik heb eerder al gezegd dat software tot op zekere hoogte gezien kan worden als een wetenschap. Helaas vertonen sommige softwareontwikkelaars meer overeenkomsten met Dr. Frankenstein dan met Dr. Goodall. Net als Frankenstein (de wetenschapper, niet zijn creatie) kunnen ze volledig geobsedeerd raken door het verleggen van technologische grenzen. Ze stellen innovatie en technische bekwaamheid boven ethische overwegingen en verliezen daarbij uit het oog welke invloed hun creaties op de samenleving kunnen hebben. Ze verwaarlozen hun verantwoordelijkheid om ervoor te zorgen dat hun software wordt ontwikkeld met aandacht voor ethiek.

In tegenstelling tot Frankenstein zouden we juist meer moeten streven naar het voorbeeld van Dr. Jane Goodall, die voor mij het toonbeeld is van een ethische en betrokken wetenschapper. Je kent Goodall waarschijnlijk van haar werk met chimpansees in Tanzania. Haar manier van onderzoek doen en natuurbehoud tonen een diep respect voor de wereld om haar heen en een sterke toewijding aan het begrijpen en beperken van ethische en maatschappelijke impact. Als softwareontwikkelaars hebben ook wij de kracht om de digitale wereld vorm te geven en het leven van talloze mensen te beïnvloeden.

Daarom wil ik je aansporen om na te denken over je eigen houding als software engineer. Lijk jij meer op de koele, puur wetenschappelijke benadering van Dr. Frankenstein, of op het ethische, betrokken perspectief van Jane Goodall?

Terug van verlof

Na tweeënhalve week welverdiende rust loopt Alex weer het drukke kantoor van Etrain binnen, verfrist en met hernieuwde energie. De pauze heeft geholpen om te ontspannen en met een frisse blik naar de uitdagingen binnen het bedrijf te kijken. Maar er is nog iets veranderd bij Alex: tijdens het verlof zijn er nieuwe ideeën en inzichten ontstaan.

Wanneer Alex weer binnenstapt, komen collega’s en teamleden nieuwsgierig en enthousiast naar hem toe. Niet alleen hebben ze het werk probleemloos voortgezet tijdens zijn afwezigheid, sommige teams hebben zelfs de ethische initiatieven opgepakt die Alex eerder met zoveel passie had verdedigd. Alex is verrast door hun enthousiasme. Kim had dus gelijk.

Alex grijpt het moment aan om opnieuw contact te maken met de teams, vragen te beantwoorden en de nieuwe ideeën te delen die tijdens het verlof zijn ontstaan. In open gesprekken en gedeelde ervaringen herinnert Alex zichzelf eraan dat softwareontwikkeling niet alleen draait om meten, wetenschap en wiskunde, maar ook in essentie om samenwerken met mensen.

Terwijl Alex nadenkt over de invloed die elke software engineer kan hebben, besluit hij opnieuw in gesprek te gaan met Kim, de vertrouwenspersoon. Hij vertelt enthousiast hoe de teams tijdens zijn afwezigheid moeiteloos hebben doorgewerkt en hoe hun inzet en enthousiasme hem opnieuw hebben geïnspireerd. Nu de teams zo zelfstandig blijken te functioneren, heeft Alex een nieuw plan.

“Ik weet zeker dat ik met het Booking System-team wil blijven werken,” zegt Alex. “Ik heb geweldige ideeën om de kwaliteit van dat systeem verder te verbeteren. Maar ik ga me terugtrekken uit de andere teams. Het Booking System wordt mijn hoofdprioriteit. Dat heb ik nodig.”

Kim knikt begrijpend. “En wat gebeurt er met de verantwoordelijkheden waar je het de vorige keer over had? Laat je die nu varen?”

“Nee,” zegt Alex. “Niet loslaten. Maar in plaats van overal tegelijk deel te nemen aan de kruistocht, ga ik helpen die te faciliteren. Dat zal minder stressvol zijn... en waarschijnlijk ook effectiever.”

Kim glimlacht. “Faciliteren? Wat bedoel je precies?”

Alex kijkt op de klok en staat op. “Oh, ik heb daar geweldige ideeën over. Maar laten we die bewaren voor de volgende keer.”