'Developer snakt naar de juiste tools'

Isaac-cto: Developer experience belangrijk in strijd om ontwikkelaar

Developers kijken bij de keuze voor een ict-werkgever of -opdrachtgever steeds kritischer naar het ontwikkelplatform dat daar wordt gebruikt. Ze eisen inspraak in de selectie van middelen en gaan niet zomaar akkoord met de door de directie opgelegde programmeertools. Bedrijven en opdrachtgevers die daar rekening mee houden, binden sneller ontwikkelaars aan zich.

Friso Geerlings, cto Isaac.

Dat stelt Friso Geerlings, cto van de Eindhovense dienstverlener voor software-ontwikkeling Isaac. Het bedrijf dat ruim honderd developers in dienst heeft, is specialist in technisch en strategisch advies voor software-ontwikkeling voor financiële diensten en commerciële toepassingen. Het levert onder meer ontwikkeldiensten en -advies aan Albert Heijn, Eindhoven Airport en verschillende banken en begeleidt organisaties in de keuze voor programmeertools (zie bedrijfsprofiel onderaan artikel).

Volgens Geerlings wordt de ervaring van ontwikkelaars met een platform, de developer experience, steeds belangrijker. ‘Developers zijn schaars en duur, dus als het veel tijd en moeite kost om eigen software te integreren, stijgen de kosten. Daarnaast kan een platform dat niet gebruiksvriendelijk is ertoe leiden dat ontwikkelaars aanhaken op een ander platform. Omdat ze daar liever meer werken.’

Geerlings: ‘Developers kiezen steeds vaker voor een content-managementsysteem met een fijne api, testomgeving en documentatie, zoals Contenful of Storyblok.’ Die platformen winnen aan populariteit van ‘klassiekere systemen’ die beschikken over ‘iets verouderde interfaces en klassieke documentatie in pdf’. Als voorbeelden noemt hij Sitecore en ‘zelfs’ Drupal. ‘Ze kunnen met die nieuwe tools meteen van start. De proof-of-concept staat al voor het andere pakket überhaupt doorgrond is.’

Salesforce versus Oracle CRM

Volgens Geerlings zijn platformen die de developer experience centraal stellen populair onder ontwikkelaars. ‘Deze tools uit het api-tijdperk winnen het in populariteit van de klassiekers die toch lastig die nieuwe kant op evolueren. Denk aan CommerceTools boven Intershop. Contentful boven Sitecore. Maar ook Salesforce boven Oracle CRM of een payment provider als Stripe boven spelers als Worldpay.’

Het gaat volgens hem om ‘uitstekend’ ontworpen api’s op basis van moderne technieken zoals rest (representational state transfer; software-architectuur), Webhooks en eventueel GraphQL, en de bijbehorende documentatie met voorbeelden, scenario’s en ‘code snippets’ of software development kits (sdk’s) die een developer direct kan gebruiken.

Daardoor raken bedrijven niet alleen meer in trek als werk- of opdrachtgever voor developers, maar worden projecten ook sneller en beter opgeleverd. Als voorbeeld noemt hij een financiële portal en app voor een grote bank in Engeland: ‘Ons bedrijf heeft in eerste instantie - op basis van een architectuurdocument vanuit het hoofdkantoor in Parijs - een platform moeten opzetten op basis van een klassiek groot cms zonder prettige developer experience. Hoewel het bruikbaar was, kostte de integratie maanden en nog was het lastig om maatwerk uit te voeren, terwijl dat voor een financieel product anno nu wel nodig is.’

Na enkele jaren aanrommelen met dure veranderingen en aanpassingen is besloten te gaan voor een her-implementatie op basis van een cms dat wel is opgebouwd op basis van een developer experience. Geerlings noemt rest, api first en heldere documentatie en sdk’s als vereisten. ‘De stap naar dit cms kostte uiteindelijk maar een week en de tevredenheid is nu al groter. Het ontwikkelteam wist met dit cms een beter niveau te bereiken in pakweg een tiende van de tijd. Dit leverde direct tienduizenden euro’s besparing op ‘change control’-kosten op. Zoveel kan het dus schelen.’

6 aandachtspunten voor developer experience

  • Een goed ontworpen api: pas de ‘api triad’ toe: eerst nadenken over rest, dan over Webhooks voor ‘events’, en dan over GraphQL voor ‘vrije queries’.
  • Goede api-documentatie: alle in- en output helder; deel realistische en leuke voorbeelden,
  • Schrijf niet alleen de technische documentatie maar leg ook (beknopt maar helder) je businesswaarde en functionaliteit uit in een Developer Portal
  • Langlopende versies: zorg dat je api waar mogelijk ‘backwards compatible’ kan blijven. Verdedig dit met hand en tand. Als je moet aanpassen, ondersteun de oude api dan nog zeker een jaar.
  • Testbaarheid: alles aan de api moet direct testbaar zijn, eventueel met fake-responses in een sandbox-omgeving
  • Lever ondersteunende componenten als software development kits en plugins voor veelvoorkomende client-systemen (denk aan een plugin voor een populair commerce platform als Magento), en release die onder opensource en met een soepele licentie als MIT. Stel deze gewoon open ter download.

Bron: Friso Geerlings, cto Isaac

Directie buitenspel

Een andere trend die Geerlings ziet, is dat de beslissing over de keuze voor een platform steeds minder vaak in de directiekamer wordt genomen. Ontwikkelaars hebben meer inspraak in de gekozen tools. ‘Reden te meer om ze tevreden te houden.’ Hij noemt vier knelpunten van nieuwe ontwikkelplatformen gevolgen hebben voor de developers experience:

  • Een rest-api waarvan de foutmeldingen onduidelijk zijn; dit zorgt voor een kwetsbare integratie die op rare momenten opeens niet meer werkt.
  • Lang niet alle scenario’s op een api kunnen naspelen in een testomgeving
  • Ontbrekende functionele documentatie. De developer snapt dan wel hoe de api te integreren is, maar weet niet exact wat er nu echt gebeurt wanneer die wordt aangeroepen.
  • Heel veel complexe status-informatie willen ‘exposen’ via een rest-api. Hiervoor is nu GraphQL veel aantrekkelijker geworden. Biedt dan ook een GraphQL interface aan.

Interface steeds belangrijker

Ook de interface wordt volgens de cto dus steeds belangrijker. Maar, waar moet een goede interface aan voldoen? Geerlings: ‘Heldere naamgeving van de variabele namen met zeer veel aandacht voor consistentie hierin, endpoints, error signalen. Toepassing van de api triad (de drie logische technieken) waar mogelijk: rest voor create/read/update/delete, Webhooks voor ‘push events’, GraphQL voor vrij query’en en rapportages, metrics, enzovoort.’ (Zie ook kader Development experience).

Geerlings vervolgt: ‘Indien er sdk's worden geboden, moeten deze ook goed gedocumenteerd worden en voorzien zijn van tests en scenario’s, zodat developers zo veel mogelijk gewoon een voorbeeld kunnen knippen en plakken.'.

3:30:3-regel

"In drie seconden moet de business value van een api-call duidelijk zijn"

Als tip om de developers experience te verbeteren noemt Geerlings: ‘Pas de 3:30:3-regel toe. De documentatie van een api moet zo zijn dat in drie seconden het doel van een api call qua businesswaarde duidelijk is. Dat je in dertig seconden een test call kan doen met de juiste input (bijvoorbeeld met een code snippet of goed voorbeeld), en dat je in maximaal drie minuten als ontwikkelaar in staat bent het api-resultaat ook goed te verwerken. De responses zijn dus belangrijk om goed te documenteren, evenals de error codes of situaties.’

Hij noemt puntsgewijs nog een aantal tips:

  • Lever een portal met goede zoekfunctionaliteit, zodat developers meteen aan de slag kunnen, ook eventueel alleen om te experimenten, zonder registratie. En verbindt deze publieke portal met je merk, bijvoorbeeld developer.bedrijfsnaam.com als url.
  • Zorg dat een eventuele trial-registratie om een api of platform uit te proberen ook één-op-één door kan naar productie, zodat een developer allerlei instellingen niet twee keer hoeft af te stemmen.
  • Benader developer experience net als user experience: denk na over de development scenario’s en verschillende rollen als system integrator, product owner, test engineer, et cetera.
  • Zorg ook gewoon voor een echt aantrekkelijk developer portal met documentatie op developer.bedrijf.com als url. Denk eraan dat developers hier veel tijd doorbrengen; de omgeving verdient dus zeker dezelfde aandacht als de vormgeving van de corporate site.

Aanbieders doen daarmee niet alleen de developers een plezier, ze versterken er ook hun marktpositie mee, stelt hij.

ING en ABN Amro

Banken als ING en ABN Amro zijn volgens Geerlings voorbeelden van organisaties die door de inzet van moderne ontwikkeltools die aansluiten op de eisen van developers een aantrekkelijke werkgever zijn geworden. 

‘ING is een goed voorbeeld van hoe zowel teamstructuur (Agile transformatie) als technische innovatie (gebruik van meer platformen) het werk aantrekkelijker maken. Ook de stap naar een platform als Azure, met goede developer experience, bij ABN Amro zorgt ervoor dat developers er weer volop aan de slag willen. We zien ook overal dat met name front-end developers helemaal klaar zijn met logge legacy-cms’en en kiezen voor een baan bij een bedrijf dat een modern api first-cms kiest, zoals Contentful of Storyblok.’

De cto van Isaac: ‘Hier geldt: hoe eenvoudiger de koppeling tussen systemen tot stand gebracht kan worden, hoe groter de kans op succes voor het platform.’

Geerlings vervolgt: ‘We helpen bedrijven om hun developer experience te verbeteren. Door de beleving van developers te onderzoeken, de knelpunten in systemen te analyseren, en een oplossing te ontwikkelen. Als één ding de afgelopen jaren duidelijk is geworden, dan is het dat developers snakken naar goede interfaces en documentatie.’

Isaac

Digital agency Isaac uit Einhoven heeft meer dan honderd developers in dienst. Isaac werkt in complexe financiële contexten zoals financieringen voor BNP Paribas, voor betaaldienstverleners als Ingenico en Payvision (die weer eindklanten hebben als Stream, Blizzard en Ali Baba), voor grote login-systemen als Basispoort en in de meer internet of things en ‘real world’ verbonden systemen als de integratielaag van Eindhoven Airport en de handscanners bij Albert Heijn.

Ook zijn ze betrokken bij tientallen projecten in e-commerce, zoals Winkelstraat.nl en meerdere online-badkamer- en sanitairwinkels die vaak beschikken over een complexe achterliggende logistiek.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Hé! Een leuk/goed artikel! Mag ik de 3:30:3 regel kapen voor eigen gebruik (met bronvermelding natuurlijk)?

Reactie Computable-redacteur, Pim van der Beek.

Beste Jos Visser,

Dank voor uw reactie. U kunt deze 'regel' gebruiken onder bronvermelding. Bijvoorbeeld: 'Friso Geerlings, cto software-ontwikkeling Isaac, in Computable-artikel 'Developer snakt naar de juiste tools'.

Mocht het om online content gaan, dan wordt linken gewaardeerd.

Vriendelijke groet, Pim van der Beek

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-06-23T11:22:00.000Z Pim van der Beek
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.